การเขียนซอฟต์แวร์ง่ายกว่าการอ่านและทำความเข้าใจตั้งแต่เริ่มต้นหรือไม่? [ปิด]

ฉันและเพื่อนของฉันกำลังคุยกันเรื่องวานนี้เกี่ยวกับความแตกต่างระหว่างการเขียนซอฟต์แวร์ C ++ ขนาดใหญ่และเข้าใจว่าเป็นการรับสมัครใหม่

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

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

จากประสบการณ์ของฉันฉันจะจัดลำดับกิจกรรมต่อไปนี้ตามลำดับจากง่ายที่สุดไปหายากที่สุด

1. อ่านรหัสที่ดี
2. เขียนรหัสไม่ดี
3. เขียนรหัสได้ดี
4. อ่านรหัสไม่ดี

การจัดอันดับดังกล่าวนำไปสู่ข้อสรุปที่ 2

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

แน่นอนว่ารหัสที่ดีและรหัสที่ไม่ดีนั้นเป็นการสรุปทั่วไป ฉันขอแนะนำCode CompleteและClean Codeสำหรับรายละเอียดเพิ่มเติมเกี่ยวกับรหัสที่ดี

คำถามนี้ดึงดูดให้มีการลงมติเป็นเอกฉันท์ http://en.wikipedia.org/wiki/False-consensus_effect

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

ความแตกต่างระหว่างการเขียนซอฟต์แวร์ C ++ ขนาดใหญ่และเข้าใจว่าเป็นการรับสมัครใหม่

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

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

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

มันเป็นคำถามที่น่าสนใจ แต่ฉันมักจะเอนไปทางด้านข้างของการอ่านและทำความเข้าใจได้ง่ายกว่าการสร้างมันขึ้นมา

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

หากคุณเป็นโปรแกรมเมอร์รุ่นใหม่ดังนั้น "คุณไม่รู้ว่าคุณไม่รู้อะไร" ดังนั้นคุณจะต้องประดิษฐ์ / เรียนรู้สิ่งเล็กน้อยทั้งหมดและมีโอกาสมากที่คุณจะมีความไร้ประสิทธิภาพใน รหัส. คุณมีแนวโน้มที่จะพัฒนาความเข้าใจภาษามากขึ้น

แต่ในทั้งสองกรณีมันจะง่ายต่อการอ่านโค้ดและไปจากที่นั่นมากกว่าที่จะเขียนมันตั้งแต่ต้น

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

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

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

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

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

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

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

สิ่งนี้นำไปสู่คำถาม: ไม่สำคัญหรือไม่

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

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

ฉันเป็นคำตอบของ StMotorSpark เพียงแค่เพิ่ม:
มันขึ้นอยู่กับปัจจัยหลายอย่างเช่นคำถามใช่หรือไม่ใช่ตัวอย่าง:

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