เป็นเรื่องปกติหรือไม่ที่โปรแกรมเมอร์จะไม่มีความคมชัด 100% เหนือรหัสของตัวเองในบางครั้ง? [ปิด]

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

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

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

ไม่มีก็ไม่ปกติ1 อย่างน้อยมันก็ไม่ปกติสำหรับโปรแกรมเมอร์ที่ดี อาจเป็นเรื่องปกติสำหรับคนที่เรียนรู้ที่จะเขียนโปรแกรม

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

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

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

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

สิ่งนี้มีอยู่สองชนิด: 1. ) ความสับสน 2. ) ความเขลาที่แสนสุขสันต์

คนแรกไม่ดีและอาจหายไปกับเวลาและประสบการณ์

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

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

ดังนั้น "ไม่รู้" เป็นจริงคงที่ในการพัฒนาซอฟต์แวร์ - เป็นอย่างไรหรือว่าคุณจัดการ

ฉันว่ามันเป็นเรื่องธรรมดามากกว่าที่คนเราจะยอมรับ แม้แต่ไบรอัน Kernighan พูดพาดพิงถึงมัน:

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

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

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

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

ฉันคิดว่านี่เป็นสิ่งที่จะไปด้วยประสบการณ์

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

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

แหล่งที่มา: ไม่เคยใช้อาร์เรย์ 5 มิติ :)

"ปกติ" เป็นอัตวิสัยมากดังนั้นฉันพูดว่า: มันเป็นเรื่องธรรมดามาก แต่ควรหลีกเลี่ยง

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

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

ที่เกี่ยวข้อง:

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

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

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

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

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

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

มีคำตอบที่ดีมากมายที่นี่

ฉันมีสิ่งที่ต้องทำสองอย่างสำหรับเรื่องนี้

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

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

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

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

ปัญหาส่วนใหญ่ที่เราจัดการกับซอฟต์แวร์นั้นซับซ้อนโดยธรรมชาติ การออกแบบซอฟต์แวร์เป็นแบบฝึกหัดในการจัดการความซับซ้อน

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

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

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