ความคิดเห็นที่ล้าสมัยเป็นตำนานของเมืองหรือไม่?

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

ฉันเพิ่งโชคดีในสิ่งที่ฉันทำงานด้วยหรือไม่? อุตสาหกรรมบางประเภทมีแนวโน้มที่จะเกิดปัญหานี้มากกว่าอุตสาหกรรมอื่น ๆ หรือไม่? คุณมีตัวอย่างเฉพาะของความคิดเห็นที่ล้าสมัยล่าสุดที่คุณเห็นหรือไม่ หรือแสดงความคิดเห็นที่ล้าสมัยมากกว่าปัญหาทางทฤษฎีมากกว่าปัญหาจริงหรือ?

นิจศีล

ฉันไม่อยากจะเชื่อเลยว่าฉันเป็นคนเดียวที่ว่ายน้ำในความคิดเห็นที่ล้าสมัยและทำให้เข้าใจผิด ในโอกาสนี้ช่วยด้วยความเข้าใจ:

มันอาจขึ้นอยู่กับอายุของรหัสที่สำคัญที่สุด ปัจจัยต่อไปคือผลประกอบการของพนักงาน

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

รหัสการบำรุงรักษา ... ฉันเป็นผู้ดูแลระบบที่มีอายุมากกว่า 10 ปีและอีกปีที่มากกว่า 5 รหัสและความคิดเห็นอายุ 10 ปีมีความเลวร้ายอย่างที่คุณคาดหวัง กว่า 10 ปีที่คุณได้รับจำนวนมากใน codebase และไม่มีใครมีความคิดใด ๆ ว่าสิ่งทั้งหมดทำงานได้อีกต่อไป รหัสและความคิดเห็นอายุ 5 ปีนั้นค่อนข้างดีเพราะยอดขายของทีมค่อนข้างต่ำ

ฉันทำงานบริการเกือบทั้งหมดแม้แต่ผลิตภัณฑ์ของเราก็ปรับแต่งตามความต้องการของลูกค้า

ตัวอย่างเฉพาะ:

• ความคิดเห็นที่อธิบายการปรับปรุงประสิทธิภาพสำหรับวิธีการเฉพาะเช่นหลีกเลี่ยงการคัดลอกในหน่วยความจำ เรื่องใหญ่เมื่อเครื่องระดับท็อปใน Pentium 2 ที่มี RAM จำนวนเมกะไบต์ แต่แทบจะไม่มีปัญหา

• TODOs

• บล็อกของรหัสที่คัดลอกวางรวมถึงความคิดเห็น ความคิดเห็นอาจสมเหตุสมผลในตำแหน่งเดิม แต่แทบจะไม่มีเหตุผลที่นี่

• บล็อกความคิดเห็นที่อยู่ด้านบนของโค้ดที่ใส่ความเห็น (ใครจะรู้ว่ามีกี่ปีที่ผ่านมา)

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

"ความคิดเห็นมีแนวโน้มที่จะล้าสมัย"

ฉันเคยเห็นสิ่งนี้เกิดขึ้นบ่อยครั้งพอที่จะรู้ว่านี่อาจเป็นปัญหา

ฉันคิดว่าฉันเห็นความคิดเห็นที่ล้าสมัยสองหรือสามครั้งในอาชีพการงานของฉัน

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

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

การศึกษาล่าสุดโดยRoehm และคณะ 2012สังเกตต่อไปนี้:

ผู้เข้าร่วม 21 คนจาก [28] รายงานว่าพวกเขาได้รับข้อมูลหลักจากซอร์สโค้ดและความคิดเห็นแบบอินไลน์ในขณะที่มีเพียงสี่คนเท่านั้นที่ระบุว่าเอกสารเป็นแหล่งข้อมูลหลัก

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

_{Roehm, T. , Tiarks, R. , Koschke, R. , & Maalej, W. (2012, มิถุนายน) นักพัฒนามืออาชีพเข้าใจซอฟต์แวร์อย่างไร ในรายงานการประชุมทางวิศวกรรมซอฟต์แวร์แห่งชาติประจำปี 2555 (หน้า 255-265) กด IEEE}

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

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

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

หากคุณไม่เคยเห็นความคิดเห็นที่ล้าสมัยใด ๆ แสดงว่าคุณโชคดีมาก

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

ความคิดเห็นที่ล้าสมัยมักจะปรากฏใน JavaDoc:

• รายการอาร์กิวเมนต์ที่ไม่มีอยู่อีกต่อไป
• ไม่อธิบายการขัดแย้งทั้งหมด (อาจหายไปในภายหลัง)
• สิ่งที่คล้ายกันสำหรับข้อยกเว้น ฯลฯ

นอกจากนี้บางครั้งแสดงความคิดเห็นสิ่งต่าง ๆ เช่น "ทำสิ่งนี้เพื่อประสิทธิภาพ" เมื่อการพิจารณาประสิทธิภาพส่วนใหญ่มีแนวโน้มที่จะเก่ากว่าเร็วกว่าโค้ดเอง

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

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

featureList = GetFeatures();

// Sorting features and deleting empty ones from the list...
ProcessFeatures(featureList);

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

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

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

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

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

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

//TODO: In 15 years AND NO SOONER... actually implement this method.

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

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

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

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

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