รหัสไม่มีจุดหมายในที่มาของคุณ

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

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

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

คำถามของฉันคือ มีคนอื่นเห็นรหัสเช่นนี้หรือไม่ ข้อสรุปของคุณคืออะไรทำไมรหัสนั้นอยู่ที่นั่น

หากใครมีรหัสที่เขียนเช่นนี้คุณสามารถแบ่งปันทำไม

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

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

ฉันไม่เห็นรหัสเช่นนี้ แต่ฉันเห็นรหัสที่ไม่มีจุดหมายหรือไม่มีเหตุผลด้วยเหตุผลอื่น:

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

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

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

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

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

คำถามของฉันคือ มีคนอื่นเห็นรหัสเช่นนี้หรือไม่ ข้อสรุปของคุณคืออะไรทำไมรหัสนั้นอยู่ที่นั่น

1) ใช่

2) ในกรณีที่ฉันเคยเห็นฉันจะใส่มันลงไปใน:

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

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

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

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

IMO นี่ไม่ได้ผลและไม่เอื้อต่อความสัมพันธ์ที่ดีในการทำงานกับเพื่อนร่วมงานของคุณ

ทั้งหมดเหล่านี้มักจะมีอาการของอายุโครงการ

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

ฉันดูเหมือนจะจำได้จากทุกวัน wtf:

@deprecated // he might have been crazy enough to use reflection...
boolean getTrue() {
    return false; 
}

 2. การตรวจสอบซ้ำซ้อนทำในไฟล์คลาสวัตถุหรือวิธีการแยกต่างหาก เลเยอร์ของการสื่อสารยังไม่สมบูรณ์ (เคยอ่าน Mythical Man Month หรือไม่ถ้าไม่คุณกำลังทำอะไรอยู่บนคอมพิวเตอร์!? Go! READ!) บ่อยครั้งที่คนคนหนึ่งจะทำงานกับบางสิ่งบางอย่างแล้วออกจากโครงการและจากนั้นคนต่อไปพบข้อผิดพลาดที่แปลกประหลาดโยนตรวจสอบพิเศษที่นี่และมีการพยายามที่จะกำจัดมัน เมื่อข้อผิดพลาดจะถูกลบออกการตรวจสอบไม่ได้เพราะดีถ้ามันไม่พังไม่ได้แก้ไข

 3. ถ้าข้อความที่ประเมินเป็นจริงเสมอ โอ้ฉันทำไปแล้ว ฉันได้รับโปรเจ็กต์หนึ่งครั้งมีประมาณ 10-15 บล็อก/ชุด หากต้องการเปลี่ยนพฤติกรรมฉันเพียงวางtrue||บล็อกแรก มันไม่ได้จนกว่าเดือน (ปี?) หลังจากนั้นฉันกลับมาและพูดว่า "โอ้ว้าวรหัสนี้ควรจะถูกทำลาย แต่ไม่เคยเป็น"

 4. เธรดที่หมุนและไม่ทำอะไรเลย ฉันนึกภาพความคิดออกมาเป็นแบบนี้:

1. ฉันรู้ว่า! ฉันสามารถจัดการกับปัญหาทั้งสองนี้ได้แบบไม่ต่อเนื่อง! ฉันจะสร้างหัวข้อ foo and bar
2. (สองเดือนต่อมา) อืมคุณรู้ไหมว่าฟังก์ชั่นจากบาร์นั้นดีขึ้นเล็กน้อยใน foo ฉันจะย้ายบางส่วน
3. (หนึ่งปีต่อมา) คุณรู้ไหมว่าเอาของอื่น ๆ จากบาร์ไปที่ฟูทำให้มันสมเหตุสมผล
4. (หลายหลายปีต่อมา) "เฮ้, barเธรดนี้ดูไม่เหมือนว่ามันกำลังทำอะไรเราจะเอามันออกได้ไหม" "ไม่ดีกว่ามันมีมาหลายปีแล้ว ... "

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

เพื่อนเก่าบอกฉันถึงเวลาที่ที่ปรึกษาจ่ายเงินตามจำนวนบรรทัดที่ผลิต ดังนั้นพวกเขาจึงเพิ่มผลกำไรโดยใช้โครงสร้างที่ยืดยาวอย่างน่าอัศจรรย์

ทุกวันนี้ฉันมักจะคิดว่าคนที่แต่งตัวประหลาดยังคงเรียนรู้ภาษาในขณะที่ทำงาน และเขากำลังรีบ

คำตอบส่วนใหญ่ต้มลงไปกับข้อเท็จจริงง่ายๆสองข้อนี้:
[1] รหัสสะท้อนถึงประวัติของรหัสและ
[2] รหัสนี้สะท้อนถึงอนาคตที่คาดหวังของรหัส

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

ฉันได้เขียนคำสั่ง if ที่ AT ปัจจุบันประเมินเสมอว่าเป็นจริง แต่บางทีในอดีตอาจเป็นเท็จ

ในการตรวจสอบซ้ำซ้อนเฮ้ฉันไม่เชื่อถือรหัสอื่นฉันไม่เชื่อถือรหัสของตัวเอง หากโมดูลขึ้นอยู่กับ N เป็น 1 หรือ 2 หรือ 3 มันจะดีกว่าถ้าแน่ใจแล้วทำอย่างนั้นอย่างไม่เป็นทางการ เป็นเรื่องไม่ถูกต้องที่ Module B จะระเบิดเพราะ Module A เกิดความผิดพลาด มันค่อนข้างถูกต้องตามกฎหมายสำหรับโมดูล B ที่จะบ่นว่าโมดูล A มีปัญหา และโปรดจำไว้ว่าในเดือนหน้าพารามิเตอร์นั้นอาจมาจากโมดูล C ที่ยังไม่ได้เขียน

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

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

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

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

• การเรียกใช้เมธอดหรือฟังก์ชันที่ไม่ทำสิ่งใดมีค่า

ไม่จำเป็นต้องเลวร้าย เมธอดในคลาสพื้นฐานมักเรียกเมธอดว่างที่มีความหมายว่าเป็นจุดแทนที่สำหรับคลาสย่อย ตัวอย่าง: UIView ของ Cocoa Touch มี-didAddSubview:วิธีที่บันทึกไว้ว่าไม่ทำอะไรเลยในเวอร์ชันเริ่มต้น -addSubview:วิธีการของ UIView ต้องเรียกใช้-didAddSubview:แม้ว่ามันจะไม่ทำอะไรเลยเพราะคลาสย่อยอาจใช้มันเพื่อทำบางสิ่งบางอย่าง แน่นอนว่าวิธีการที่ไม่ทำอะไรและมีเหตุผลสำหรับพวกเขา

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

• การตรวจสอบซ้ำซ้อนทำในไฟล์คลาสวัตถุหรือวิธีการแยกต่างหาก

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

• ถ้าข้อความที่ประเมินเป็นจริงเสมอ

มีความแตกต่างใหญ่ระหว่าง:

if (1) {
    // ...
}

และ:

if (foo() == true) {
    // ...
}

ที่เกิดขึ้นเสมอกลับfoo()true

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

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

• เธรดที่หมุนและไม่ทำอะไรเลย

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

มันเกิดขึ้น. บ่อยครั้งทีเดียว

บางครั้งการเขียนโค้ด dead-end เหล่านี้ก็เหมือนกับร่องรอยแพะเก่าที่ตกอยู่ในสภาพทรุดโทรมเมื่อมีการติดตั้งทางด่วนที่มีประสิทธิภาพมากขึ้น / ทันสมัย ​​/ รวดเร็วขึ้น

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

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

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

ฉันคัดค้านif trueคำแถลงที่จะจำแนกอย่างไม่มีหลักเกณฑ์ว่าเป็น "รหัสไม่มีจุดหมาย"

มีกรณีที่ถูกต้องตามกฎหมายสำหรับการใช้if (1) { ... }บล็อกในรหัส C ที่ต้องการเข้ากันได้กับมาตรฐาน C ที่ยืนยันในคำจำกัดความของตัวแปรที่จะเริ่มต้นของฟังก์ชั่นหรือเพียงแค่ต้องการตัวแปรท้องถิ่นที่จะกำหนดเป็นท้องถิ่นที่สุด

switch (i) {
    case 23:
        if (1) {
            /* I can declare a local var here! */
        }
        break;
}

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

ในฐานะที่เป็น @Andy กล่าวถึงองค์ประกอบใหญ่ที่ผมเคยเห็นคือทำลายYAGNI

บางคนเริ่มต้นด้วยการสันนิษฐานว่าองค์ประกอบทั้งหมดจะเป็นอะไรแทนองค์ประกอบหลายอย่างที่ต้องการซึ่งเป็นความสับสนของ"เป็น"และ"มี"ความสัมพันธ์

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

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