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

นี่เป็นเรื่องปกติสำหรับโปรแกรมเมอร์ ..... หรือฉันแค่ไม่คิดในแง่ที่ถูกต้อง

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

โค้ดที่แย่ที่สุดที่ฉันเคยเห็นคือวิธีการที่มีโค้ดมากกว่า 2,000 บรรทัด ไม่ต้องสงสัยเลยว่ารหัสนี้ซับซ้อน แต่ก็แย่มาก

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

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

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

ฉันเห็นโค้ดจำนวนมากที่ซับซ้อนกว่าที่จำเป็นและเกือบทุกครั้งด้วยเหตุผลสามประการนี้:

1) over-engineered เนื่องจากลักษณะทั่วไปก่อนกำหนดหรือพยายามคาดการณ์ความต้องการในอนาคตที่ไม่เคยเกิดขึ้น

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

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

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

ดังที่ Martin Fowler กล่าวผู้ที่เรียนรู้เทคโนโลยีใหม่มีปัญหาระยะสั้นซึ่งเป็นแนวทางขับเคลื่อน "เทคโนโลยี"

ฉันไม่คิดว่ามันเป็นเรื่องปกติสำหรับโปรแกรมเมอร์ทุกคน แต่ฉันได้เห็นอย่างแน่นอนว่าโปรแกรมเมอร์ทำสิ่งนี้

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

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

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

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

กล่าวอีกนัยหนึ่งง่ายๆคือในสายตาของคนดูในหลายกรณี

ปัญหาคือถ้าคุณไม่เห็นวิธีแก้ปัญหาอย่างง่าย ๆ (นี่คือที่ที่การพูดคุยกับเพื่อนร่วมงานเข้ามาเล่น) หรือถ้าคุณพูดคุยกันเร็วเกินไป

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

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

ในบางกรณีอาจเป็นความซับซ้อนของการหาวิธีแก้ปัญหาที่เรียบง่าย

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

การขาดความชัดเจนจะเป็นอุปสรรคต่อความสามารถในการกำจัดส่วนเกินทั้งหมด

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

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

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

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

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

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

อาจเป็นปัญหาของความผิดพลาดแบบคลาสสิก?

30. นักพัฒนาทองคำชุบ

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

• Steve McConnell การพัฒนาอย่างรวดเร็ว

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

ใช่ ... และฉันจ่ายเงินหลายครั้งเกินไป

ไวท์บอร์ดของฉันตอนนี้มีข้อความเป็นเครื่องหมายดอกจันที่อยู่ด้านบนสุดซึ่งอ่านได้

"ถ้ามันไม่ง่ายมันไม่ถูก"

... และทุกครั้งที่ฉันทำต้นแบบบนกระดานไวท์บอร์ดมันจะดึงดูดความสนใจของฉันเสมอ

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