รหัสที่ดีเป็นไปไม่ได้ในการพัฒนาซอฟต์แวร์ที่ทันสมัย? [ปิด]

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

คำถามของฉันคือ: พิจารณาว่าเรามีภาษาและเครื่องมือที่ทรงพลังกว่า

• ทำไมการเขียนรหัสที่ดีจึงยากกว่า
• ปัจจัยเวลาและความซับซ้อนมีส่วนในสิ่งนี้หรือไม่?
• วิธีการไม่ได้รับการฝึกฝนอย่างถูกต้องหรือไม่?

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

ตามที่ได้ระบุไว้โดย DeMarco และ Lister ในPeoplewareหลายปี 20ish ที่ผ่านมาส่วนใหญ่ของโครงการซอฟต์แวร์ล้มเหลวล้มเหลวไม่ได้เกิดจากความท้าทายทางเทคนิค แต่ปัญหาทางสังคมวิทยา สิ่งนี้ไม่ได้เปลี่ยนแปลงในทศวรรษที่ผ่านมาไม่ว่าเครื่องมือของเราจะได้รับการปรับปรุง

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

ทำไมการเขียนรหัสที่ดีนั้นยากกว่า

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

มันเป็นเพียงเพราะปัจจัยที่กล่าวถึงเวลาและความซับซ้อน?

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

OTOH เนื่องจากสนามเติบโตอย่างมหาศาลมีปัญหา "เล็ก" หรือ "รู้จัก" มากขึ้นกว่าเมื่อ 30 ปีที่แล้ว ปัญหาเหล่านี้ในทางเทคนิค (ควร) ไม่ใช่สิ่งที่ท้าทายอีกต่อไป แต่ ... ที่นี่เข้าสู่ maxim ด้านบน :-(

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

มันเป็นวิธีการที่ไม่ได้ปฏิบัติอย่างถูกต้อง?

IMHO ไม่แน่นอน DeMarco และ Lister มีคำพูดรุนแรงเกี่ยวกับระเบียบวิธีการใหญ่ พวกเขาบอกว่าไม่มีระเบียบวิธีใดที่จะทำให้โครงการประสบความสำเร็จ - มีเพียงคนในทีมเท่านั้นที่สามารถทำได้ OTOH วิธีการเล็ก ๆ ที่พวกเขาชื่นชมนั้นค่อนข้างใกล้เคียงกับสิ่งที่เรารู้ว่าเป็น "เปรียว" ซึ่งกำลังแพร่หลายอย่างกว้างขวาง (IMHO ด้วยเหตุผลที่ดี) ไม่ต้องพูดถึงแนวปฏิบัติที่ดีเช่นการทดสอบหน่วยและการปรับโครงสร้างซึ่งเมื่อ 10 ปีที่แล้วยังไม่เป็นที่รู้จักอย่างกว้างขวางและทุกวันนี้ผู้สำเร็จการศึกษาจำนวนมากก็รู้สิ่งเหล่านี้

ปัญหาที่เกี่ยวข้องกับการเข้ารหัสภายใต้กำหนดเวลาที่ไม่สมจริงและการจัดการกับหนี้ทางเทคนิคนั้นเป็นที่ทราบกันตั้งแต่ Weinberg '71 และ Brooks '72 วรรณคดีกลายเป็นเรื่องยากที่จะขุดออนไลน์ก่อนหน้านี้ แต่ฉันค่อนข้างแน่ใจว่ามีรายงาน CDC, IBM และ NASA รุ่นเก่าที่พูดในสิ่งเดียวกัน

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

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

ในที่สุดฉันคิดว่ามันเป็นการดีที่สุดที่จะไล่ตามดีกว่าคือไล่ตาม "ดี" หรือ "ดีที่สุด" หากเราเห็นโค้ดที่ดีที่สุดออกไปเราจะจำมันได้หรือไม่

ทำไมการเขียนรหัสที่ดีนั้นยากกว่า

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

รหัสที่ดีเป็นไปไม่ได้ในการพัฒนาซอฟต์แวร์ที่ทันสมัย?

แน่นอนมันเป็นไปไม่ได้ แต่ไม่ใช่ด้วยเหตุผลใดก็ตามที่คุณเคยได้ยินมาแล้ว

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

เราได้ทำไปแล้วเราได้แก้ปัญหาความซับซ้อน แต่นั่นก็ไม่ได้ขจัดปัญหาที่ใหญ่กว่าที่เราเคยทำมาก่อน

มันยังซับซ้อนเกินกว่าที่เราจะจัดการได้

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

เราจะไม่สามารถทำเช่นนั้นได้

และถ้าเราทำไม่ได้เราจะไม่ผลิตรหัสคุณภาพ

ผู้จัดการจะเห็นโมดูลที่กระจัดกระจาย แต่ไม่ทราบปัญหาภายในและข้อ จำกัด ต่อโมดูล

โปรแกรมเมอร์โมดูลจะรู้ข้อ จำกัด ในท้องถิ่น แต่จะไม่สามารถปรับให้เหมาะสมในบริบทของภาพที่ใหญ่ขึ้น

ไม่มีทางที่จะสื่อสารความเข้าใจระหว่างผู้จัดการและโปรแกรมเมอร์ (และระหว่างโปรแกรมเมอร์) และแม้ว่าจะมีความสามารถของสมองมนุษย์ก็ไม่สามารถจัดการได้

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

ฉันปฏิเสธหลักฐานของคำถามของคุณ มันง่ายกว่าที่เคยเขียนโค้ดที่ดีและด้วยเหตุนี้เราจึงแก้ปัญหาได้ยากกว่าที่เคยมีมาก่อน

ฉันไม่ต้องการเลือกผู้จำหน่ายรายใด แต่เปรียบเทียบ Windows 1.0 กับ Windows 7 หลังมีรหัสมากกว่าพันเท่า แต่เวลาเฉลี่ยระหว่างการขัดข้องเพิ่มขึ้นเป็นร้อยเท่า เราควรจะสามารถฝังสเปรดชีต Excel ในเอกสาร Word ได้ตั้งแต่ Windows 3.1 แต่วันนี้มันใช้งานได้จริง

โดยไม่ต้องการตกอยู่ในความรู้สึกแบบ "คุณเด็กวันนี้ด้วยการพิมพ์เป็ดและ VM" ฉันขอแนะนำให้คุณไม่รู้ว่าการเขียนโค้ดที่ดีในยุค 80: TINY, SMALL และ HUGE หน่วยความจำขนาดใหญ่ซ้อนทับกันอย่างไร การเรียกระบบปฏิบัติการที่ไม่ใช่แบบเช่าพื้นที่ (ตัวสั่น) ดีกับทุกสิ่ง

แอปพลิเคชั่นที่ทันสมัยมีความซับซ้อนกว่าเมื่อ 20-30 ปีที่แล้วเนื่องจากสภาพแวดล้อมของพวกเขามีความหลากหลายและหลากหลาย

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

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

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

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

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

ฉันคิดว่ามีกฎโบราณของวิทยาศาสตร์ที่ควรค่าแก่การจดจำ:

ธรรมชาติเกลียดชังสูญญากาศ

Francois Rabelas (พระภิกษุและผู้เย้ยหยัน ค.ศ. 1494-1553)

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

แล้วทำไมเราไม่ทำล่ะ

IMO เหตุผลหลักคือเรามองหาวิธีและข้อแก้ตัวในการใช้งานในทางที่ผิด แทนที่จะเป็นวิธีที่ล้าสมัยง่ายและน่าเบื่อเช่นการสร้างไฟล์ปฏิบัติการ Windows เราจะผลักดันขอบเขตของความเป็นไปได้และมองหาวิธีการเช่นสร้างสิ่งต่างๆเช่น PhotoShop เป็นเว็บแอปพลิเคชัน ทำไม? เพราะเราสามารถ. หรืออย่างน้อยเราก็คิดเช่นนั้น

ครั้งสุดท้ายที่ทุกคนไม่ได้เขียนหาประโยชน์หรือเรียนรู้ที่จะทำเช่นนั้นด้วยการชุมนุม (ไม่นับแฮกเกอร์เคอร์เนลและพวก ASIC)? มีข้อบกพร่องกี่ข้อที่ค้นพบใน C core library? แทบจะไม่มีเลยสักนิด ทั้งหมดที่ฉันพูดคือผู้คนมีความสามารถในรหัสที่ยอดเยี่ยม เครื่องมือและภาษาที่ดีขึ้นเพียงทำให้ 'จำเป็น' น้อยลงและ 'ไม่จำเป็น' มากขึ้น ไม่ใช่ว่าฉันคิดว่าเราทุกคนควรเขียนโค้ดที่น่ากลัวจริงๆ แต่เมื่อฉันคิดถึงโครงสร้างเชิงตรรกะที่ซับซ้อน ... คงไม่มีใครใฝ่ฝันที่จะเขียนบางสิ่งด้วยแฮชอาร์เรย์ในชุดประกอบ ต้องมีวิธีที่ 'ดีกว่า' ในการจัดการกับตรรกะแทนที่จะใช้โครงสร้างที่ซับซ้อน แม้ว่ารหัสจะสวยงาม แต่บางครั้งวิธีการก็ไม่ได้สวยงาม ฉันคิดว่ามันเป็นปัญหาที่คุณพูดถึง รหัสที่ดีไม่ได้ถูกจัดระเบียบเสมอ

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

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

ทั้งหมดนี้เกิดจากความคาดหวังทั้งภายใน (ความคาดหวังของเราเอง) และขององค์กรของเรา เราพยายามทำมากที่สุดในเวลาสั้นที่สุด และเกิดข้อผิดพลาดอย่างหลีกเลี่ยงไม่ได้

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

ผู้คนเริ่มแย่ลงในการสร้างรหัสที่ดีได้อย่างไร

หากคุณใช้. NET และภาษาอย่าง C # (และฉันรู้ว่าไม่ใช่แพลตฟอร์ม / ภาษาเดียว) ฉันขอยืนยันว่าการเข้ารหัสที่ดีกลายเป็นเรื่องที่ไกลได้ง่ายขึ้นเนื่องจากระบบอัตโนมัติของสิ่งต่าง ๆ ภายใน Visual Studio สิ่งแวดล้อม

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

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

สองเซ็นต์ของฉัน

ใช่เราในฐานะอุตสาหกรรมไม่ได้ฝึกวิธีการที่เป็นที่รู้จักกันดี อ้างอิง: สตีฟ McConnell ของ Construx ซอฟแวร์การพัฒนาซอฟท์แวแขวนต่ำผลไม้

คุณภาพของโค้ดยังไม่ดีขึ้น

โปรดอย่าติดขัดในการตีความ“ รหัสที่ดี”

ตรรกะซ้ำซากที่ดี

รหัสไม่ได้ดีขึ้นเพราะคนย้ายคำจำกัดความของ "ดี"

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