มีความคิดเห็นเพิ่มเติมดีกว่าในสภาพแวดล้อมที่มีการหมุนเวียนสูงหรือไม่

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

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

ความคิดเห็นไม่เกะกะรหัส

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

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

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

ความคิดเห็นที่อุดมสมบูรณ์ในสภาพแวดล้อมนั้นครอบคลุมถึงปัญหาที่ควรได้รับการแก้ไขอีกทางหนึ่ง

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

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

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

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

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

"มีความคิดเห็นเพิ่มเติมที่ดีขึ้นในสภาพแวดล้อมที่มีการหมุนเวียนสูงหรือไม่"

ฉันคิดว่าพวกเขาอาจจะแย่ลง:

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

• ความคิดเห็นของ "สิ่งที่ต้องการความคิดเห็น" การเปลี่ยนแปลงจากคนสู่คน

• พวกเขายังคงฝึกการเขียนโค้ดที่ยากต่อการอ่านด้วยความคิดเห็นเพื่ออธิบายมันซึ่งตรงข้ามกับโค้ดที่อ่านง่ายที่มีชื่ออธิบาย

• การรักษารูปแบบและความสอดคล้องของพวกเขากลายเป็นงานในตัวเอง

• ผู้ใช้ใหม่ต้องเรียนรู้มาตรฐาน 'รูปแบบ' ก่อนจึงจะสามารถเปลี่ยนแปลงได้อย่างรวดเร็ว

จุดที่ 1: ความชัดเจนเป็นสิ่งสำคัญในสภาพแวดล้อมที่มีการหมุนเวียนสูง

จุดที่ 2: การใช้คำฟุ่มเฟื่อยไม่ชัดเจน

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

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

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

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

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

คำตอบที่ธรรมดาเกินไป: "ยิ่งรหัสของคุณน่าจะถูกอ่านซ้ำยิ่งเป็นภาระในการอธิบายสิ่งที่คุณกำลังทำ" นี่อาจเป็นเพราะการทำให้โค้ดอ่านง่ายขึ้นโดยการแสดงความคิดเห็นโดยการสร้างเอกสารอย่างเป็นทางการโดยทำตามมาตรฐานสไตล์ ... โปรดทราบว่าอาจเป็นเพราะคุณกำลังทำการอ่านซ้ำในภายหลัง สภาพแวดล้อมการหมุนเวียนสูง

มีอีกเธรดที่ยอดเยี่ยมซึ่งครอบคลุมว่าข้อคิดเห็นเป็นเอกสารประกอบหรือไม่

ความคิดเห็นมีประโยชน์มากกว่าในบางสถานการณ์ นี่เป็นพื้นฐานที่ฉันกังวลเกี่ยวกับวิธีอธิบายในท่ามกลางคำตอบมากมายที่ฉันเห็นว่าเป็น "ต่อต้านความคิดเห็น"

หากรหัสของคุณอาจไม่ได้อ่านเป็นเวลาหลายปีความคิดเห็นมีความสำคัญมากกว่าถ้าคุณมีการเปลี่ยนรหัสบ่อยๆการเป็นเจ้าของรหัสที่รัดกุมและการตรวจสอบรหัสจำนวนมาก หากแอปพลิเคชันของคุณมีความซับซ้อนและใช้เทคนิคที่ผู้สังเกตการณ์มีความเชี่ยวชาญในภาษานั้นไม่ชัดเจนในทันทีความคิดเห็นมีความสำคัญมากกว่าถ้าระบบนั้นยกย่องว่าเป็น "Hello World" หากฐานของรหัสนั้นไม่เข้มงวดกับมาตรฐานเท่าที่ควรความคิดเห็นนั้นสำคัญกว่าถ้าคุณทำงานกับ QA หกชั้น หากคุณกำลังทำงานกับทีมด้วยแปดคนเพียงแค่เรียนรู้ภาษาความคิดเห็นมีความสำคัญมากกว่าถ้าทีมของคุณมีโปรแกรม Pulitzers แปดรายการ หากคุณมีแอปพลิเคชั่นที่เหยียดยาวตกลงบนตักความคิดเห็นมีความสำคัญมากกว่าถ้าคุณสามารถสร้างมันให้สะอาดตั้งแต่เริ่มต้น

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

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