คำกล่าวของ Torvalds เกี่ยวกับโปรแกรมเมอร์ที่ดี [ปิด]

บังเอิญฉันสะดุดกับคำพูดต่อไปนี้โดย Linus Torvalds:

"โปรแกรมเมอร์ไม่ดีต้องกังวลเกี่ยวกับโค้ดโปรแกรมเมอร์ที่ดีต้องกังวลเกี่ยวกับโครงสร้างข้อมูลและความสัมพันธ์ของพวกเขา"

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

• การตีความในสิ่งนี้เป็นไปได้ / เหมาะสม?
• สิ่งที่สามารถนำไปใช้ / เรียนรู้จากมัน?

มันอาจช่วยพิจารณาสิ่งที่ Torvalds พูดไว้ก่อนหน้านี้:

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

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

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

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

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

อัลกอริทึม + โครงสร้างข้อมูล = โปรแกรม

โค้ดเป็นเพียงวิธีแสดงอัลกอริธึมและโครงสร้างข้อมูล

คำพูดนี้คุ้นเคยกับกฎข้อใดข้อหนึ่งใน "The Art of Unix Programming" ซึ่งเป็นหน้าที่หลักของ Torvalds ในการเป็นผู้สร้าง Linux หนังสือตั้งอยู่ออนไลน์ที่นี่

จากหนังสือเล่มนี้เป็นคำกล่าวต่อไปนี้ที่อธิบายถึงสิ่งที่ Torvalds กำลังพูด

Rule of Representation: พับความรู้ลงในข้อมูลเพื่อให้ตรรกะของโปรแกรมสามารถโง่และแข็งแกร่ง

แม้แต่ตรรกะขั้นตอนที่ง่ายที่สุดก็ยากสำหรับมนุษย์ที่จะตรวจสอบ แต่โครงสร้างข้อมูลที่ค่อนข้างซับซ้อนนั้นค่อนข้างง่ายในการสร้างแบบจำลองและเหตุผลเกี่ยวกับ หากต้องการดูสิ่งนี้ให้เปรียบเทียบความหมายและพลังในการอธิบายของไดอะแกรมของต้นไม้ชี้ห้าสิบโหนดกับแผนผังลำดับงานของโปรแกรมห้าสิบบรรทัด หรือเปรียบเทียบอาร์เรย์ initializer ที่แสดงตารางการแปลงด้วยคำสั่ง switch ที่เทียบเท่า ความแตกต่างในความโปร่งใสและความชัดเจนเป็นอย่างมาก ดูกฎของ Rob Pike 5

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

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

รหัสเป็นเรื่องง่ายมันเป็นตรรกะที่อยู่เบื้องหลังรหัสที่ซับซ้อน

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

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

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

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

Linus แปลว่าสิ่งนี้:

แสดงผังงานของคุณ [รหัส] และปกปิดตารางของคุณ [schema] และฉันจะต้องประหลาดใจต่อไป; แสดงตารางของคุณ [schema] และปกติฉันไม่ต้องการผังงานของคุณ [รหัส]: พวกเขาจะเห็นได้ชัด

- Fred Brooks, "The Mythical Man Month", ch 9

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

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

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

อย่างไรก็ตามสิ่งที่สูงกว่ามีความสำคัญมากกว่า

หากฉันมีข้อบกพร่องในสองสามบรรทัดของปัญหาที่ทำให้เกิดพฤติกรรมที่ไม่ถูกต้องอาจไม่ยากเกินไปที่จะแก้ไข ถ้ามันทำให้มันไม่ทำงานมันอาจไม่สำคัญ

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

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

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

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

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

การรู้ว่าข้อมูลจะไหลไปอย่างไรมีความสำคัญทั้งหมด การรู้โฟลว์ต้องการให้คุณออกแบบโครงสร้างข้อมูลที่ดี

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

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

สิ่งที่สามารถนำไปใช้ / เรียนรู้จากมัน?

ถ้าฉันอาจประสบการณ์ของฉันในไม่กี่สัปดาห์ที่ผ่านมา การสนทนาก่อนหน้านี้ได้อธิบายคำตอบสำหรับคำถามของฉัน: "ฉันเรียนรู้อะไรบ้าง"

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

• เมื่อทดสอบการส่งมอบดั้งเดิมของฉันนักวิเคราะห์ธุรกิจบอกฉันว่ามันไม่ทำงาน เราพูดว่า "เพิ่ม 30 วัน" แต่สิ่งที่เราหมายถึงคือ "เพิ่มเดือน" ( วันในวันที่เกิดไม่เปลี่ยนแปลง) เพิ่มปี, เดือน, วัน; ไม่ใช่ 540 วันเป็นเวลา 18 เดือนเช่น

• การแก้ไข: ในโครงสร้างข้อมูลแทนที่เลขจำนวนเต็มเดียวด้วยคลาสที่มีจำนวนเต็มหลายค่าการเปลี่ยนเป็นการสร้างนั้น จำกัด เพียงวิธีเดียว เปลี่ยนคำสั่งทางคณิตศาสตร์วันที่จริง - ทั้ง 2 ข้อ

ผลตอบแทน

• การนำไปใช้ใหม่มีฟังก์ชันการทำงานมากขึ้น แต่รหัสอัลกอริทึมสั้นและง่ายขึ้นชัดเจน

ในการแก้ไขพฤติกรรมรหัส / ผลลัพธ์:

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

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

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

ฉันเคยเห็นนี่เป็นพื้นที่มากมาย

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

พิจารณาทำหน้าเว็บ เป็นการดีกว่าที่จะคิดเกี่ยวกับสิ่งที่คุณต้องการแสดง (HTML) ก่อนและกังวลเกี่ยวกับสไตล์ (CSS) และการสร้างสคริปต์ (เลือกเครื่องมือของคุณ) หลังจากนั้น

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

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

คุณภาพของตัวบ่งชี้รหัส = [การเปลี่ยนแปลงรหัส] / [การเปลี่ยนแปลงสคีมาฐานข้อมูล]

"แสดงผังงานของคุณและซ่อนตารางของคุณและฉันจะยังคงประหลาดใจแสดงตารางของคุณให้ฉันและฉันไม่ต้องการผังงานของคุณ; พวกเขาจะชัดเจน" (Fred Brooks)

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

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