ลูกค้าของฉันต้องการ 25% ของความคิดเห็นในโครงการปัจจุบันของฉันวิธีการตอบสนอง? [ปิด]

นักพัฒนาจูเนียร์ที่นี่

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

ฉันตรวจสอบรหัสของแอปพลิเคชันก่อนหน้าและนี่คือข้อสังเกตของฉัน:

• แต่ละไฟล์เริ่มต้นด้วยบล็อกความคิดเห็น (แพ็คเกจ, วันที่อัพเดทล่าสุด, ชื่อ บริษัท & ลิขสิทธิ์ของฉัน)

• ตัวแปรทั้งหมดจะถูกใส่ความคิดเห็นพร้อมชื่อ // nameOfCustomer public String nameOfCustomer

• getters และ setters ทั้งหมดถูกคอมเม้นต์

• ความเห็นที่เป็นประโยชน์น้อยมาก

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

ฉันไม่ได้พูดกับลูกค้าโดยตรงเกี่ยวกับเรื่องนี้ นี่คือข้อโต้แย้งของฉัน:

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

คุณมีคำแนะนำเกี่ยวกับเรื่องนี้อย่างไร? ฉันจะจัดการกับสถานการณ์ได้อย่างไร

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

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

สำหรับฉันเมื่อฉันได้ยินลูกค้าพูดว่า "ฉันต้องการความคิดเห็น 25%" นั่นคือจุดเริ่มต้นของการโต้ตอบ สำหรับฉันเป็นที่ชัดเจนว่าความหมายที่นี่คือ "ฉันต้องการข้อความอธิบายจำนวนมากเพื่อให้ผู้มาใหม่ใน codebase นี้สามารถเริ่มต้นและทำงานได้อย่างรวดเร็ว" ไม่ใช่ "ฉันต้องการให้คุณเพิ่มการสุ่มในหมวดหมู่ประโยค" เป็นคำตอบอื่น ๆ ดูเหมือนจะเอามัน และฉันจะขออย่างจริงจังและตั้งใจที่จะเขียนความคิดเห็นเชิงพรรณนาและเป็นประโยชน์มากมายชี้แนะผู้มาใหม่ถึงโครงสร้างของรหัสชี้ไปที่การตัดสินใจทางวิศวกรรมที่น่าประหลาดใจและสรุปเหตุผลที่เข้ามาและให้ความรู้ภาษาอังกฤษระดับสูง คำอธิบายของส่วนรหัสที่ซับซ้อน (แม้ว่าจะไม่มีความประหลาดใจก็ตาม) ความตั้งใจและความเข้าใจนี้เป็นจุดเริ่มต้นของการสนทนา - นั่นคือก่อนที่เราจะเริ่มพูดคุย สำหรับฉันความหมายของการร้องขอนั้นชัดเจนมากจนไม่จำเป็นต้องมีความกระจ่าง แต่ถ้าคุณไม่แน่ใจคุณควรเช็คอินกับพวกเขาแน่นอน!

โอเคกล่องโต้ตอบจะไปที่ไหนถ้านั่นเป็นจุดเริ่มต้น ส่วนต่อไปของกล่องโต้ตอบจะเป็นดังนี้:

1. ฉันคาดหวังว่านี่จะเป็นความพยายามอย่างจริงจังเพิ่มเติมอาจเป็นในระยะที่สองของโครงการนั่นคือเหนือกว่าการผลิตเครื่องมือที่พวกเขาสนใจเกี่ยวกับการทำงาน อาจใช้เวลาหลายนาทีในการพูดคุยเพื่อหารือเกี่ยวกับกระบวนการนี้และทำไมมันถึงเป็นงานเพิ่มเติม แต่ฉันจะไม่สนใจที่นี่เพราะในฐานะโปรแกรมเมอร์มืออาชีพฉันคาดหวังว่าคุณจะรู้ว่ามันยากแค่ไหน
2. "ความพยายามอย่างจริงจังเพิ่มเติม" หมายความว่าเราอาจต้องใช้งบประมาณที่นานขึ้นและใช้งบประมาณมากขึ้น หรือเราอาจต้องลดงบประมาณคุณสมบัติ; หรือเราอาจต้องประนีประนอมกับคุณภาพและปริมาณความคิดเห็น ส่วนนี้จะเป็นการเจรจาเล็กน้อย แต่ในความคิดของฉันคุณควรรู้ล่วงหน้าเกี่ยวกับค่าใช้จ่ายในการทำงานพิเศษนี้และตรวจสอบให้แน่ใจว่ามันเป็นคุณสมบัติที่สำคัญสำหรับลูกค้าที่พวกเขายินดีรับค่าใช้จ่ายเหล่านี้ และถ้าพวกเขาเป็น - ยอดเยี่ยม! คุณได้รับเวลาและเงินพิเศษและพวกเขาได้รับความคิดเห็นคุณภาพสูง ทุกคนชนะ และหากปรากฎว่าคุณลักษณะการแสดงความคิดเห็นไม่สำคัญสำหรับพวกเขาว่าพวกเขาเต็มใจที่จะสูญเสียความสามารถในการทำให้เสียความสามารถในการทำให้วิดเจ็ตหลุดพ้นหรือเต็มใจที่จะให้กำหนดเวลาส่งมอบให้กับ Gran Gran ล่าช้า 20x6 ต้องการและคุณไม่ต้องใช้ความพยายามพิเศษในการสร้างความคิดเห็นคุณภาพสูง

นี่คือที่ฉันคิดว่ากล่องโต้ตอบไม่ควรไป:

3. อย่าคุกคามลูกค้าด้วยความคิดเห็นคุณภาพต่ำ ให้พวกเขาช่วยคุณเลือกระดับความพยายามที่พวกเขาต้องการใช้จ่ายและพวกเขายินดีจ่าย อย่าสัญญากับพวกเขา 25% ความคิดเห็นแล้วแจ้งพวกเขาว่าคุณตั้งใจที่จะส่งมอบสัญญานี้โดยการสุ่มอัตโนมัติหลังจากสร้างโครงการแล้ว
4. อย่าซ่อนแผนของคุณ อย่าสัญญากับพวกเขา 25% ความคิดเห็นแล้วสุ่มสร้างอัตโนมัติโดยไม่บอกพวกเขาว่าสิ่งที่คุณกำลังจะทำ เมื่อพวกเขาสังเกตเห็น (ไม่ใช่ถ้า) คุณทั้งคู่เสียเวลามาก: พวกเขาไม่พอใจกับผลิตภัณฑ์ที่พวกเขาได้รับและคุณได้รับคำพูดติดปาก
5. อย่าพยายามโน้มน้าวพวกเขาพวกเขาไม่ต้องการความคิดเห็น พวกเขาต้องการความคิดเห็นอย่างชัดเจน หารือเกี่ยวกับการแลกเปลี่ยนวิธีการต่างๆ: ใช่! พูดคุยถึงวิธีการอื่นในการทำให้ codebase เป็นมิตรกับผู้ใช้: ใช่! บอกพวกเขาว่าไม่รู้ว่าต้องการอะไร: เอ๊ะไม่ คุณต้องการทำงานกับพวกเขาเพื่อให้ได้สิ่งที่ต้องการ เพื่อให้เข้าใจว่าเป็นอะไรและคิดหาวิธีที่ดีที่สุดในการส่งมอบสิ่งเหล่านั้นในงบประมาณที่พวกเขาอนุมัติโดยให้ความสำคัญกับคุณลักษณะที่พวกเขาสนใจมากที่สุดหากทรัพยากรที่พวกเขามีไม่เพียงพอ
6. อย่าแก้ตัวว่าการเขียนคอมเม้นท์นั้นยากแค่ไหน การเขียนรหัสนั้นยาก การแก้จุดบกพร่องรหัสเป็นเรื่องยาก; การเขียนความคิดเห็นเป็นเรื่องยาก ถ้ามันง่ายพวกเขาจะไม่จ้างคุณ เพียงข้ามคำร้องเรียนและไปยังจุดที่พวกเขาสนใจนั่นคือความพยายามพิเศษที่จำเป็นมีผลต่อพวกเขาอย่างไร

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

สิ่งนี้ถูกกล่าวถึงมันมีความสำคัญอย่างมากต่อการกำหนดมาตรฐานคุณภาพ (ที่นี่แย่):

• มาตรฐานคุณภาพตามสัญญา: รหัสที่ส่งมอบจะต้องปฏิบัติตามหรือไม่เช่นนั้นจะเป็นการละเมิดสัญญา ไม่มีทางเลือก.

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

• เกณฑ์ Ad-hoc ที่กำหนดโดยคู่ของบุคคลที่ลูกค้า ที่นี่คุณสามารถมีส่วนร่วมสนทนา มีความหวัง :-)

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

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

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

• ทำความสะอาดรหัส (แนะนำหนังสือให้กับลูกค้าของคุณ: มีส่วนที่น่าเชื่อถือสำหรับความคิดเห็นและรหัสการจัดทำเอกสารด้วยตนเอง)
• การฝึกปฏิบัติเอกสาร: สิ่งที่ยากที่สุดที่จะเข้าใจและด้วยเหตุนี้ข้อมูลที่มีค่าที่สุดเช่นความสัมพันธ์และปฏิสัมพันธ์ระหว่างชั้นเรียนจะได้รับการจัดทำเป็นเอกสารที่ดีกว่าในเอกสารแยกต่างหาก (ตัวอย่างเช่นในรูปภาพ UML มากกว่า 1,000 คำแสดงความคิดเห็น?)

หากลูกค้ายังคงไม่เชื่อว่าคุณสามารถนำเสนอทางเลือกการทดลองใช้เครื่องมือสร้างโดยอัตโนมัติเอกสารที่มีความคิดเห็นเช่นหรือjavadoc doxygenเสนอด้วยการเปลี่ยนโฟกัสจากปริมาณ (25% ของรหัส) เป็นคุณภาพ (สร้าง javadoc ที่เข้าใจได้)

ลูกค้าต้องการความเห็นอย่างน้อย 25% ในแต่ละโครงการซอฟต์แวร์

ลูกค้าต้องการความเห็น 25% หรือลูกค้าต้องการให้รหัสของคุณมีความหมายที่สุดเท่าที่จะเป็นไปได้?

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

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

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

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

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

สิ่งนี้ทำให้ฉันนึกถึงคำตอบ Stack Overflow ที่โง่ ๆ ที่คุณเห็นว่าประกอบด้วยหนึ่งบรรทัดตามด้วยตัวอักษร "ข้อความบางส่วนที่นี่เพื่อ จำกัด จำนวนอักขระสูงสุด"

เมื่อสิ่งนี้เกิดขึ้นการโต้เถียงอาจทำให้คนสองกลุ่มเป็นฝ่ายผิด:

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

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

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

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

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

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

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

เพียงแค่ทำตามขั้นพื้นฐานของรหัสของคุณคุณอาจจะอยู่ที่ 10% หรือมากกว่านั้น และให้ความเห็นอีก 5% ของความคิดเห็นที่คุณเขียนด้วยตัวคุณเอง (บางคนเขียนเพิ่มเติม แต่ 5% ดูเหมือนว่าจะเป็นการประเมินแบบอนุรักษ์นิยมหากคุณยังไม่ได้ทำตามคำปฏิญาณ) ณ จุดนี้มันประมาณ 15% (ใช่ใช่ฉันรู้ว่า 5% ของ 90% น้อยกว่า 5% อย่า nitpick) หากออกซิเจนของคุณน้อยกว่า 10% บางทีวิธีการของคุณอาจยาวมาก เป็นความคิดที่ดีที่จะแบ่งย่อยเป็นส่วนย่อย ๆ (ส่วนใหญ่เป็นแบบส่วนตัว / มีการป้องกัน) หรือใช้คลาสตัวช่วยทั่วไปเพิ่มเติมเป็นต้น

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

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

PS - ดูรหัสมาตรฐานของตู้คอนเทนเนอร์ Java เพื่อดูว่าคุณจะไปถึงได้อย่างไร 70% หรือมากกว่านั้น ...

การมีความคิดเห็น 25% ในรหัสของคุณเป็นเป้าหมายที่ยอดเยี่ยมและทำให้ลูกค้ามีความสุข ตอนนี้การเขียนความคิดเห็นเส็งเคร็ง 25% เช่น "i + = 1; // เพิ่มฉันทีละ 1" ควรอยู่ข้างใต้คุณดังนั้นใช้เวลาเขียนความคิดเห็นที่เป็นประโยชน์และสนุกไปกับความรู้สึกที่คุณจ่ายจริง ๆ เพื่อทำสิ่งที่คุณควรทำ อย่างไรก็ตาม.

เราทุกคนรู้ว่านี่เป็นความต้องการอึ คำถามที่น่าสนใจที่นี่คือ

วิธีการตอบสนอง

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

ขอให้ฉันทำสิ่งนี้และฉันจะบอกว่าจะเพิ่ม 1% ให้กับการเสนอราคาของฉัน โอ้ แต่มันจะเพิ่ม 20% สำหรับการเสนอราคาการบำรุงรักษาในอนาคต

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

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

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

x = x + 1; // add 1 to x

และฉันพูดกับตัวเองนั่นคือเครื่องหมายบวกหมายความว่า !! ว้าวขอบคุณที่บอกฉันฉันไม่รู้

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

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

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

โปรดจำไว้ว่าคนที่ บริษัท ของคุณกำลังเจรจาอาจจะใช่หรือไม่ใช่คนที่คิดค้นกฎ 25% นี้ มันอาจเป็นกฎที่กำหนดให้พวกเขาจากที่สูงขึ้น

ฉันเห็นคำตอบห้าข้อที่เป็นไปได้:

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

สอง. ปฏิเสธที่จะทำมัน สิ่งนี้อาจทำให้คุณถูกไล่ออกหรือถ้า บริษัท เห็นด้วยกับคุณทำให้คุณเสียสัญญา ดูเหมือนว่าจะไม่ก่อผล

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

/*
GetFoo function
Parameters:
  name: String, contains name
  num: int, the number
  add_date: date, the date added
Returns:
  foo code: int
*/
int GetFoo(String name, int num, Date add_date)

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

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

ย้อนกลับไปเมื่อฉันเริ่มธุรกิจนี้ครั้งแรก บริษัท ที่ฉันทำงานเพื่อใช้โปรแกรมที่โฆษณาว่า "เขียนเอกสารของคุณให้คุณ! ทำเอกสารให้ครบทุกโปรแกรม!" ระบบต้องการให้เราให้ตัวแปรทั้งหมดเป็นชื่อที่ไม่มีความหมายเป็นหลักแล้วมีตารางที่ให้ชื่อที่มีความหมายสำหรับแต่ละตัวแปรดังนั้นโดยพื้นฐานแล้วสิ่งที่ "เอกสารอัตโนมัติ" ได้แทนที่ชื่อที่ไม่มีความหมายที่บังคับให้เราใช้ชื่อที่มีความหมาย ตัวอย่างเช่น - สิ่งนี้ใช้ได้กับ COBOL - คุณมีบรรทัดในโปรแกรมของคุณที่กล่าวไว้

MOVE IA010 TO WS124

และพวกเขาต้องการสร้าง "เอกสาร" ที่กล่าวถึง

COPY CUSTOMER NAME IN INPUT RECORD TO CUSTOMER-NAME IN WORKING STORAGE

อย่างไรก็ตามเราสามารถเขียนโปรแกรมเพื่อสร้างเอกสารที่ไม่มีค่าพอ ๆ กันได้อย่างง่ายดาย อ่านบรรทัดเช่น

a=b+c

และสร้างความคิดเห็น

// add b to c and save result in a

เป็นต้น

ห้า. ทำให้ดีที่สุดในกฎโง่ ๆ พยายามเขียนความเห็นที่เป็นประโยชน์และมีความหมาย เฮ้มันอาจเป็นการออกกำลังกายที่ดี

โอ้โดยวิธีการฉันขอเพิ่มที่คุณสามารถเล่นเกมตัวชี้วัด

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

x=x+4;

ฉันจะเขียนแทน:

x=x+1;
x=x+1;
x=x+1;
x=x+1;

ลูป? ลืมฉันจะคัดลอกและวางรหัสสิบครั้ง เป็นต้น

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

ตัวชี้วัดตามอำเภอใจดูเหมือนจะเป็นความจริงของชีวิตในโครงการมากเกินไป ...

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

ความคิดเห็นควรเพิ่มรหัสและอธิบายสิ่งที่เกิดขึ้น (และไม่เพียงแค่ทำซ้ำรหัส!)

ที่กล่าวว่าหากนี่คือสิ่งที่ลูกค้าของคุณต้องการและ บริษัท ของคุณได้ตกลงที่จะให้เว้นแต่ผู้จัดการ QA ของคุณจะพัฒนาความรู้สึกสามัญ

ในระยะสั้นคุณไม่สามารถทำอะไรได้จริงๆ ไปพร้อมกับมัน

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

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

ไม่ว่าในสถานการณ์ใดก็ตามที่คุณควรทำโดยไม่ได้รับอนุญาตจากลูกค้า

ฉันรู้สึกผิดหวังกับการขาดจินตนาการที่แสดงโดยโปรแกรมเมอร์ของฉันที่นี่

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

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

หากคุณจริงจังเกี่ยวกับการจัดทำรหัสของคุณและเกี่ยวกับการจัดเตรียมบริบทสำหรับแก๊งการบำรุงรักษาข้อกำหนดนี้จะถูกเติมเต็มโดยอัตโนมัติ ดังนั้นอย่าเป็นหีเกี่ยวกับมัน!

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

ฉันได้พบโปรแกรมเมอร์หลายคนที่ไม่เข้าใจว่าผู้คนมีตัวตนอย่างไรที่ไม่ทำงานในโครงการนี้

สำหรับพวกเขาทุกสิ่งที่พวกเขารู้ว่าทุกคนรู้

หากใครบางคนไม่ทราบทุกสิ่งที่พวกเขารู้ในปัจจุบันแล้วคนเหล่านั้นเป็น "คนโง่" กับพวกเขา

ด้วยมาตรฐานนี้คุณสามารถบังคับให้ผู้คนเขียนความคิดเห็นได้

พวกเขาอาจเขียนความคิดเห็นที่ไร้ประโยชน์ 99% ของเวลา แต่บางครั้งพวกเขาอาจเขียนสิ่งหนึ่งที่ "ทุกคนรู้" และคนใหม่ในทีมอาจไม่ได้ใช้เวลา 16 ชั่วโมงในการหาจุดบกพร่อง (ซึ่งบางคนแก้ไขไปแล้ว แต่แล้วก็ถูกยกเลิกด้วยเหตุผลอื่น) ซึ่งจะเห็นได้อย่างชัดเจนพร้อมกับความคิดเห็นที่จุดนั้นในรหัส

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