กฎที่ไม่ได้เขียนของการเขียนรหัสของสมาชิกทีมคนอื่น [ปิด]

เรากำลังฝึกการเป็นเจ้าของรหัสโดยรวม เพื่อความเข้าใจของฉันนี่หมายความว่านักพัฒนาซอฟต์แวร์สามารถเปลี่ยนบรรทัดของรหัสใด ๆ เพื่อเพิ่มฟังก์ชันการทำงานเพื่อ refactor แก้ไขข้อบกพร่องหรือปรับปรุงการออกแบบ

แต่สิ่งที่เกี่ยวกับการเขียนใหม่ของรหัสจากนักพัฒนาที่ยังอยู่ในทีม? ฉันควรถามเขาก่อน การปฏิบัติที่ดีที่สุดคืออะไร?

ฉันคิดว่าการสื่อสารที่ดีเป็นแนวปฏิบัติที่ดีที่สุดเสมอ พูดคุยกับนักพัฒนาซอฟต์แวร์และดูว่ามีสาเหตุว่าทำไมมันถูกเข้ารหัสตามที่เป็นอยู่หรือไม่ อาจเป็นได้ว่าพวกเขามีความหมายที่จะได้รับกลับมาและ refactor มันสำหรับทุกเพศทุกวัยอาจเป็นได้ว่าพวกเขาทำมันด้วยเหตุผลที่ดีมากหรืออาจเป็นได้ว่าคุณทั้งสองสามารถเรียนรู้อะไรบางอย่างจากการสนทนา

การเข้าและเขียนใหม่โดยไม่ต้องสื่อสารล่วงหน้าเป็นสูตรสำหรับความประสงค์ที่ไม่ดี

สถานที่ตั้งของคำถามนี้ทำให้เกิดความกังวลจำนวนมากสำหรับฉันที่ฉันไม่คิดว่าคำตอบใด ๆ ที่มีอยู่พยายามที่จะตอบสนองอย่างเพียงพอ ให้ฉันถามคำถามติดตามที่นี่:

1. คุณแน่ใจหรือไม่ว่าคุณกำลังพูดถึงการเขียนใหม่และไม่ทำการปรับโครงสร้างใหม่? ตามคำนิยามการเปลี่ยนแปลงรูปแบบโค้ดหรือโครงสร้างที่ส่งผลให้การใช้งานที่ดีขึ้น (หรือแตกต่างกันเพียง) โดยไม่มีการเปลี่ยนแปลงพฤติกรรมภายนอกเป็น refactor ไม่ใช่การเขียนซ้ำ การแบ่งรูทีนย่อย 500 บรรทัดเป็นชุดรูทีนย่อย 50 ชุดอาจเกี่ยวข้องกับการเขียนโค้ดใหม่สักหน่อย แต่ไม่ใช่การเขียนซ้ำ คำที่เขียนซ้ำหมายถึงการทิ้งผลิตภัณฑ์ทั้งหมดหรือคุณสมบัติและเริ่มต้นใหม่จากศูนย์ มันไม่ใช่สิ่งที่จะต้องดำเนินการเบา ๆ

2. หากพฤติกรรมของรหัสดั้งเดิมผิดไปหรือการใช้งานนั้นมีความจำเป็นอย่างยิ่งที่จะต้องมีการเขียนใหม่อย่างเต็มรูปแบบเหตุใดจึงไม่เกิดกระบวนการของทีมของคุณและแก้ไขในบริบทที่เหมาะสม (เช่นในทางเทคนิคมากกว่าสังคม) รหัสที่ไม่ถูกต้องหรือน่าสงสัยควรจะถูกเปิดเผยอย่างรวดเร็วในทีมที่มีสุขภาพดีผ่านการทดสอบรีวิวจากโค้ดรีวิวการออกแบบ ฯลฯ คุณมีสิ่งเหล่านี้หรือไม่

3. ผู้จัดการ / ผู้นำทางด้านเทคโนโลยีทราบถึงปัญหาหรือไม่และถ้าไม่เช่นนั้นจะเกิดอะไรขึ้น ไม่ว่าคุณจะมีกระบวนการประเภทใดคุณภาพของรหัสจะเป็นความรับผิดชอบของผู้จัดการฝ่ายพัฒนา เขาหรือเธอเป็นคนแรกที่คุณควรถาม - ไม่ชัดเจนในบริบทของ"ดังนั้นและเขียนรหัสอึ"แต่เพียงแค่"ฉันคิดว่าฉันเห็นปัญหาสำคัญที่นี่เราสามารถพูดคุยเกี่ยวกับการเขียนใหม่ได้หรือไม่" ถ้ามันไม่รับประกันการสนทนาประเภทนี้บางทีมันอาจจะไม่รับประกันการเขียนใหม่หรือไม่?

4. หากขนาดและขอบเขตของรหัสที่ละเมิดมีขนาดใหญ่พอที่จะรับประกันการสนทนาอย่างจริงจังของการเขียนใหม่เหตุใดจึงเป็นของนักพัฒนาซอฟต์แวร์รายเดียว ส่วนใหญ่ถ้าไม่ใช่ทุกครั้งที่ฉันเห็นโค้ดและคิดว่า "เขียนใหม่" มันถูกเหยียบย่ำโดยคนหลายโหลและความเลวร้ายเป็นผลโดยตรงจากการสะสมของความไม่สอดคล้องกันของสไตล์การเข้าใจผิดหรือการเปลี่ยนแปลงสมมติฐานและความเก่าแก่ แฮ็กแฟชั่น รหัสเติบโตหนามตลอดเวลาอย่างแม่นยำเพราะเป็นเจ้าของร่วมกัน

   จุดของฉันที่นี่คือมันแปลกที่คนคนหนึ่งจะเป็นเจ้าของรหัสขนาดใหญ่เช่นนี้ในสภาพแวดล้อมที่คาดคะเนความเป็นเจ้าของร่วมกัน คนอื่นกลัวที่จะสัมผัสรหัสของนักพัฒนาหรือไม่? พวกเขากลัวที่จะพูดเรื่องนี้หรือไม่? อาจมีปัญหาพื้นฐานกับไดนามิกของกลุ่มของคุณหรือกับผู้พัฒนานี้โดยเฉพาะ ถ้ามีอย่าเพิกเฉย หรืออีกทางหนึ่งอาจเป็นครั้งแรกที่คุณทำงานในโครงการนี้และถ้าเป็นเช่นนั้นคุณคิดอย่างไรเกี่ยวกับการเขียนใหม่ในช่วงต้นเกม บางอย่างเกี่ยวกับสถานการณ์ดูเหมือนจะไม่เพิ่มขึ้นสำหรับฉัน

5. any developer can change any line of code to add functionality, to refactor, fix bugs or improve designsคำถามที่ระบุในวรรคแรก ผู้เขียนจะไม่ทำสิ่งเหล่านี้หรือไม่ หรือมันจะทำอะไรพิเศษ - และถ้าเป็นเช่นนั้นอะไร โดยพื้นฐานแล้วคุณมีเหตุผลอะไรที่ต้องการเขียนใหม่และคุณมั่นใจได้อย่างไรว่าพวกเขาจะได้รับประโยชน์จากผลิตภัณฑ์หรือทีม คุณไม่จำเป็นต้องตอบคำถามให้กับฉัน แต่คุณควรมีจุดประสงค์ในการทำเช่นนั้นถ้าคุณเลือกที่จะพูดคุยกับทีม

ฉันรู้สึกอย่างแท้จริงว่าคำถามนี้ก่อให้เกิดบริบทจำนวนมากและไม่ควรตอบหากไม่มีความเข้าใจที่ชัดเจนเกี่ยวกับบริบทนั้น คำตอบ "ถูกต้อง" ขึ้นอยู่กับทีมของคุณผลิตภัณฑ์องค์กรของคุณบุคลิกภาพกระบวนการของคุณขอบเขตของรหัสต้นฉบับขอบเขตของการเปลี่ยนแปลงและอื่น ๆ เป็นต้น นี่คือ IMO ปัญหาที่คุณจำเป็นต้องทำกับทีมของคุณไม่ใช่ในเว็บไซต์ถามตอบออนไลน์

ทำไมคุณถึงแก้ไขรหัส?

มีข้อบกพร่องหรือมันเป็นข้อบกพร่องการออกแบบขั้นพื้นฐานมากขึ้น?

ในกรณีก่อนหน้านี้ฉันกังวลเกี่ยวกับการเขียนซ้ำเพื่อแก้ไขสิ่งที่อาจเป็นข้อบกพร่องเล็กน้อยในรหัส

ในกรณีหลังในขณะที่ฉันคาดหวังว่าหัว "รหัส" ของฉันอาจถูกเขียนใหม่ฉันมีความสุขอย่างสมบูรณ์แบบที่จะเกิดขึ้น

นั่นคือจุดของความเป็นเจ้าของรหัสแบบรวม - รหัสที่คุณเขียนจะต้องมีการแก้ไขหรือแทนที่หากมีสิ่งที่ดีกว่าเข้ามา

โดยทั่วไปหากคุณทุกคนยอมรับว่าคุณเป็นผู้รับผิดชอบต่อรหัสทั้งหมดคุณสามารถเขียนรหัสใด ๆ ได้หากเป็นการปรับปรุง พูดคุยกับนักพัฒนาคนอื่นก่อนเป็นมารยาท อาจมีเหตุผลที่ถูกต้องที่เขียนในวิธีที่แน่นอน ในระดับบุคคลนักพัฒนาจำนวนมากได้รับการลงทุนทางอารมณ์ในสิ่งที่พวกเขาผลิตและตามที่คนอื่นได้กล่าวคุณไม่ต้องการจะไม่ดี

โดยเฉพาะมันขึ้นอยู่กับการเปลี่ยนแปลงของทีม นักพัฒนาอาวุโสกำลังจะเขียนรหัสของนักพัฒนารุ่นเยาว์อีกครั้งควรทำการตรวจสอบรหัส (ไซต์ของฉัน) กับพวกเขาก่อนที่จะเขียนใหม่ ด้วยวิธีนี้ผู้พัฒนารุ่นเยาว์สามารถเรียนรู้จากสถานการณ์นี้ได้

ไม่สำคัญว่านักพัฒนาดั้งเดิมจะอยู่ในทีมหรือไม่หรือแม้ว่าคุณจะเป็นนักพัฒนาดั้งเดิม เขียนใหม่ที่สมบูรณ์ของการใด ๆรหัสที่ใช้ร่วมกันควรจะดำเนินการโดยทีมงานของคุณด้วยเหตุผลต่อไปนี้:

• ใช้เวลานานพอสมควร หากคนอื่นทำงานเกี่ยวกับการเปลี่ยนแปลงที่เกี่ยวข้องคุณไม่ต้องการเสียเวลา
• คนอื่นมีมุมมองที่แตกต่าง แม้ว่าคุณจะเขียนโปรแกรมมา 20 ปีแล้วบางคนอาจรู้เรื่องการโต้ตอบกับโค้ดที่คุณไม่ค่อยได้สัมผัส
• นักพัฒนารายอื่นคือ "ลูกค้า" ของซอร์สโค้ด มีการเขียนซอร์สโค้ดให้ผู้พัฒนารายอื่นอ่าน พวกเขาอาจมีข้อกำหนดด้านสถาปัตยกรรมการป้อนข้อมูลตามสไตล์หรือคำขอคุณสมบัติที่ต้องการในรหัสนั้น แต่ไม่มีเวลา คุณไม่ต้องการสร้าง refactor ให้เสร็จสมบูรณ์เพื่อค้นหาผู้พัฒนารายอื่นที่ต้องการ refactor ในวิธีที่ต่างออกไป

ดังที่ Matthew Flynn กล่าวว่าจำเป็นต้องพูดคุยกับผู้พัฒนาก่อน ผู้พัฒนาเริ่มต้นอาจบอกสิ่งสำคัญเกี่ยวกับฟังก์ชันการทำงานและอธิบายว่าทำไมจึงได้รับโซลูชันนี้

แต่ก่อนที่จะทำการเปลี่ยนรูปใหม่หรือการเขียนรหัสใหม่ให้ทำการสำรองข้อมูลหรือสาขาที่มีรหัสนั้น หากรหัสเดิมทำงานได้ดีจะมีโอกาสที่รหัสดังกล่าวอาจถูกกู้คืนได้

หากคุณมีระบบควบคุมแหล่งที่มา (ซึ่งฉันคิดว่าคุณมี) จากนั้นถ้าเป็นไปได้ให้ปรับรหัสทั้งหมดอีกครั้งหลังจากนั้นเมื่อคุณแน่ใจว่าใช้งานได้ดีให้ตรวจสอบสิ่งต่อไปนี้

อย่าลบรหัสเก่าอย่างน้อยก่อนที่คุณจะแน่ใจว่ารหัสใหม่ทำงานได้ดี แต่การทิ้งรหัสเก่าไว้ที่นั่นตลอดไปก็ไม่ใช่เรื่องดีเช่นกัน ฉันแนะนำให้คุณลบรหัสในภายหลังเช่นในอีกหนึ่งเดือนหลังจากที่ผ่านการทดสอบ

ขอบเขตของมันคืออะไร?

• หากคุณทำงานซ้ำสองสามบรรทัดเพื่อให้มีประสิทธิภาพมากขึ้นให้ทำเช่นนั้น อาจถามว่ามีอันตรายจากการลบพฤติกรรมที่ละเอียดอ่อนของคุณหรือไม่ รายงานการเปลี่ยนแปลงในระหว่างการต่อสู้หรือทางอีเมลเมื่อเสร็จสิ้นเว้นแต่จะไม่สำคัญ (แก้ไขการพิมพ์ผิด)

• หากคุณกำลังทำชั้นเรียนที่มีขนาดเหมาะสมคุณอาจต้องขอให้แน่ใจว่าคุณเข้าใจการออกแบบ / พฤติกรรม แจ้งให้ผู้อื่นทราบล่วงหน้าเพื่อให้ทุกคนที่อาจทำงานในพื้นที่เดียวกันสามารถรับรู้และประสานงานกับคุณ

• หากคุณกำลังทำงานกับระบบที่ใหญ่กว่าเดิมคุณควรทำงานกับทีมของคุณเพื่อให้พวกเขาตระหนักถึงการเปลี่ยนแปลงและวางแผนการออกแบบ

หากนักเขียนดั้งเดิมของคุณอยู่ที่นั่นสื่อสารกับพวกเขา ไม่ใช่แค่มารยาท แต่สำหรับข้อมูลเพิ่มเติมในกรณีที่มีกรณีหรือสถานการณ์ที่คุณไม่ได้ตระหนักถึง บางครั้งพวกเขาจะบอกสิ่งที่มีค่ากับคุณ

เรามีการควบคุมรหัสสุดซึ้ง ขณะนี้ฉันมีสิ่งต่างๆมากมายที่ต้องการการตรวจสอบและการบำรุงรักษาและยังไม่มีใครที่จะทำการตรวจสอบโค้ดด้วย นักเขียนก่อนหน้านี้ (นอกเหนือจาก moi) ไม่ได้สนใจที่จะแสดงความคิดเห็นรหัสใด ๆ และพวกเขาหายไปจาก บริษัท ไม่มีใครถามเกี่ยวกับรหัส

เมื่อฉันเขียนใหม่ฉันแสดงความคิดเห็นด้วยความคิดเห็นที่ฉันแสดงความคิดเห็นรวมถึงวันที่และชื่อ / ชื่อย่อและทำไมมันถึงถูกแสดงความคิดเห็น ฉันแสดงความคิดเห็นรหัสใหม่โดยมีชื่อหรือชื่อย่อวันที่เหตุผลถูกเพิ่มเข้ามา ฯลฯ

ความคิดเห็นเพิ่มเติมถูกสร้างขึ้นที่ส่วนหัวของแพคเกจ (เอ้อมักจะ) ระบุว่าฟังก์ชั่น / procs / SQL / ฯลฯ ถูกเปลี่ยนพร้อมกับวันที่ มันทำให้ง่ายต่อการค้นหาส่วนที่มีการเปลี่ยนแปลงและส่วนเหล่านั้นมีเอกสารฉบับเต็ม

ความเห็นราคาถูก วันที่จะเป็นตัวบ่งชี้ว่ามีการเปลี่ยนแปลงอะไรและหลังจาก x-number ของ (วัน / การแก้ไข / การจ้างใหม่ / การเกษียณ) จากนั้นรหัสสามารถล้างความคิดเห็นเก่า ๆ และส่วนที่เหลือคือพื้นฐานใหม่

จากการสังเกตของฉันการปฏิบัติทั่วไปคือ: อย่าลบรหัส เพียงแสดงความคิดเห็นและเก็บไว้

การปฏิบัติของฉันคือการแสดงความคิดเห็นออกมาในขณะที่แทนที่ (ส่วนใหญ่ใช้สำหรับการอ้างอิง) จากนั้นให้ลบออกในขั้นตอนสุดท้ายของการเปลี่ยนแปลงการทำงาน (สิ่งนี้ต้องการการควบคุมเวอร์ชันและความเข้าใจในวิธีการคืนค่าการเปลี่ยนแปลง)

เมื่อฉันพบรหัสความคิดเห็นเก่าฉันพยายามที่จะลบมันในการกระทำที่แยกต่างหากกับความคิดเห็นที่เหมาะสม สิ่งนี้ทำให้ง่ายต่อการย้อนกลับหรือตรวจสอบการเปลี่ยนแปลงในกรณีที่จำเป็น

สำหรับการเปลี่ยนแปลงทั้งหมดคุณควรจะสามารถใช้ประวัติการแก้ไขเพื่อพิจารณาผู้พัฒนาที่สร้างรหัส (ประวัติการแก้ไขที่มีคำอธิบายประกอบช่วยไว้ที่นี่) ติดต่อพวกเขาหากเป็นไปได้เพื่อดูสาเหตุที่รหัสเป็น ในหลายโครงการเวลาการทำความสะอาดจะไม่เกิดขึ้นและสิ่งต่างๆจะถูกทิ้งไว้เบื้องหลัง ตรวจสอบตัวติดตามบั๊กเพื่อดูว่ามีการบันทึกข้อมูลการล้างข้อมูลที่จำเป็นหรือไม่ การเปลี่ยนแปลงบางครั้งจะต้องมีการทำความสะอาดปล่อยหรือสองในภายหลัง

หากคุณกำลังเปลี่ยนรหัสควรมีเหตุผลที่คุณทำงานกับรหัสนั้น ตรวจสอบกับผู้พัฒนาดั้งเดิมเพื่อดูว่าทำไมรหัสจึงเป็นเช่นนั้น หากมีเหตุผลที่ถูกต้องที่จะไม่แก้ไขให้เพิ่มความคิดเห็นเพื่ออธิบายว่าทำไมมันถึงไม่ได้รับการแก้ไขหรือทำไมไม่ควรเปลี่ยน วิธีนี้จะช่วยให้นักพัฒนาซอฟต์แวร์รายต่อไปได้ซักครั้ง

แท็กเช่น FixMe, ToDo, Bug และ Hack สามารถใช้เพื่อระบุรหัสซึ่งสามารถเปลี่ยนแปลงได้ในภายหลัง (เป็นที่ยอมรับในการติดแท็กข้อ จำกัด เป็น Bug และไม่แก้ไขหากไม่ได้รับการกระตุ้นภายใต้เงื่อนไขที่กำหนด) อาจเป็นข้อผิดพลาดหากโปรแกรมบัญชีที่บ้านล้นที่ 20 ล้านดอลลาร์ แต่ฉันจะไม่เสียเวลาแก้ไขมากนัก มัน.

นักพัฒนาดั้งเดิมควรทำการเปลี่ยนแปลงการตรวจสอบรหัสหากเหมาะสมที่จะแก้ไขรหัส

อาจขึ้นอยู่กับสาเหตุที่จำเป็นต้องเขียนซ้ำ หากเป็นเพราะมีปัญหากับสิ่งที่เขียนและมีปัญหากับมันอยู่เสมอการพูดถึงมันจะถูกเรียกใช้ถ้าเพียงเพื่อลดความถี่ที่ต้องแก้ไขรหัสในอนาคต

ข้อเสนอแนะของฉันในกรณีนี้คือการจับคู่เมื่อแก้ไขรหัส ด้วยวิธีนี้มันเป็นตัวอย่างที่ดีของรัฐตัวกลางและ (หวังว่า) บริบทบางอย่างเกี่ยวกับสาเหตุที่รหัสที่เขียนใหม่นั้นดีกว่า นอกจากนี้ (หากเป็นการออกกำลังกายส่วนตัวเท่านั้น) ให้ลองปรับรหัสให้ดีขึ้นโดยไม่ต้องเขียนซ้ำทั้งหมด มันจะยากขึ้น แต่ก็ดีสำหรับคุณ

ในทางกลับกันมีบางครั้งที่มีการเขียนซ้ำสำหรับ:

• ทีมได้เรียนรู้มากมายตั้งแต่รหัสถูกเขียนขึ้นและผู้พัฒนาที่เขียนมันจะเขียนต่างออกไปแม้ว่าคุณจะไม่ป้อนข้อมูลของคุณก็ตาม

• ความต้องการคุณสมบัติใหม่จะเปลี่ยนสถานการณ์เช่นนี้ว่าการเขียนมินิเป้าหมายเป็นสิ่งที่เหมาะสม

ในกรณีเหล่านี้ฉันอาจไม่สนใจกับการสนทนา

ลองคิดดูสิฉันคิดว่ายิ่งมีรหัสนานเท่าไหร่ก็ยิ่งมีความจำเป็นในการสนทนาน้อยเท่านั้น

ฉันคิดว่า @aaronaught ทำคะแนนได้ดีซึ่งนำไปสู่คำตอบที่ฉันต้องการให้ซึ่งจริงๆแล้วมันขึ้นอยู่กับว่าใครเป็นผู้เปลี่ยนแปลง (และทำไม) และใครเป็นคนเขียนรหัส

ในรหัสประสบการณ์ส่วนตัวของฉันมีการเปลี่ยนแปลงตามปกติเพราะอาจไม่ทำงานตามที่ตั้งใจไว้หรือคุณเพียงแค่ต้องขยายสิ่งที่มันทำจริง

ในสภาพแวดล้อมทีม dev คุณไม่ควรต้องพูดคุยกับรหัสต้นฉบับ (และอาจไม่สามารถ) ทุกอย่างควรชัดเจนจากโค้ด

จากนั้นจะนำไปสู่คำถามที่ใช้เวลาส่วนใหญ่ของฉันซึ่งเป็นสิ่งที่โปรแกรมเมอร์ดั้งเดิมตั้งใจและเป็นคำถามที่มักจะนำไปสู่การถูกลบรหัสและเป็นเหตุผลที่เราควรแสดงความคิดเห็นทุกอย่างและที่โปรแกรมเมอร์ไม่มีประสบการณ์มากที่สุด มักจะเหม็น

โปรแกรมเมอร์ที่เปลี่ยนรหัสของผู้อื่น (ควรทำการเปลี่ยนใหม่) ควรได้รับความอนุเคราะห์และฝึกฝนการคัดลอกรูปแบบการเข้ารหัสเดียวกันของรหัสที่มีอยู่แล้วและทำตามขั้นตอนแรกเพื่อหาวิธีการทำงานของรหัสต้นฉบับและสิ่งที่พยายาม เพื่อและจะไปสู่ความสำเร็จ บ่อยครั้งที่สิ่งนี้อยู่ในตัวของมันเองระบุข้อผิดพลาด แต่แน่นอนว่ามันบังคับให้ผู้คนทนต่อความเจ็บปวดที่คนต่อไปจะมองดูรหัสของคุณ

ในทีมของฉันทุกคนสามารถลบสร้างใหม่หรือเขียนซ้ำสิ่งใดก็ได้และฉันคิดว่า 'ความเป็นเจ้าของ' เป็นการฝึกฝนที่ทำให้เกิดความขี้เกียจเช่นถ้าคนคนหนึ่งได้รับแจ้งถึงการเปลี่ยนแปลงใด ๆ ทำไมพวกเขาถึงต้องอ่านรหัส

ดังนั้นโดยสังเขปไม่คุณไม่ควรถามผู้แต่งดั้งเดิมของรหัสและถ้ามองไปที่รหัสที่คุณทำมันเป็นสัญญาณว่ารหัสของเขาไม่สามารถอ่านได้หรือคุณต้องปรับปรุง ทักษะของคุณ. อย่างไรก็ตามฉันคิดว่ามันเป็นรูปแบบที่ดีที่จะปล่อยให้รหัสเดิมอยู่ในความคิดเห็นจนกว่าคุณจะมั่นใจอย่างแน่นอนว่าในการเขียนใหม่คุณไม่ได้ลบฟังก์ชั่นที่ต้องการโดยไม่ตั้งใจ ไม่มีใครสมบูรณ์แบบ.

บ่อยครั้งที่รหัสถูกเขียนด้วยวิธีการที่เหมาะสมด้วยเหตุผล การสื่อสารการเปลี่ยนแปลงให้กับผู้แต่งจะได้ผลดีที่สุดเสมอ