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

ฉันยังไม่มีประสบการณ์ในการเขียนรหัสคุณภาพสูงดังนั้นฉันจึงอ่านหนังสือเกี่ยวกับปัญหาเช่นClean Codeของ Robert C. Martin และตรวจสอบรหัสของห้องสมุดที่มีชื่อเสียงเพื่อพัฒนาทักษะของฉัน

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

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

ฉันขอขอบคุณที่ชี้แจงสั้น ๆ ฉันขอโทษถ้าคำถามดูเหมือนว่าโง่จากมือใหม่

แก้ไข

ตรวจสอบตัวอย่างนี้ในห้องสมุดButterknife - หนึ่งในห้องสมุดที่มีชื่อเสียงที่สุดในชุมชน Android

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

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

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

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

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

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

ภาษาก็เป็นอีกปัจจัยหนึ่ง: Clean Code ถือว่า Java หรือภาษาที่คล้ายกัน - หากคุณใช้ C หรือ Lisp คำแนะนำจำนวนมากไม่สามารถใช้ได้

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

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

สรุป

อย่างที่ JacquesB เขียนทุกคนไม่เห็นด้วยกับ "Clean Code" ของ Robert C. Martin

โครงการโอเพนซอร์สที่คุณพบว่า "ละเมิด" หลักการที่คุณคาดว่าน่าจะมีหลักการอื่น ๆ

มุมมองของฉัน

ฉันบังเอิญตรวจสอบรหัสฐานหลายฉบับที่ยึดถือหลักการของ Robert C. Martin เป็นอย่างมาก อย่างไรก็ตามฉันไม่ได้อ้างว่าพวกเขาถูกต้องฉันสามารถพูดได้ว่าพวกเขาทำงานได้ดีสำหรับเรา - และที่จริงแล้ว "เรา" เป็นส่วนผสมของอย่างน้อย

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

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

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

ตัวอย่าง

พิจารณาการฝึกฝนของ "การแยกรหัสจากวิธีที่ยาวเป็นวิธีส่วนตัวหลายวิธี"

โรเบิร์ตซีมาร์ตินกล่าวว่ารูปแบบนี้จะช่วยให้สำหรับการ จำกัด เนื้อหาของแต่ละวิธีการหนึ่งระดับของนามธรรม - เป็นตัวอย่างที่ง่ายวิธีการที่ประชาชนอาจจะเพียงประกอบด้วยการโทรไปยังวิธีเอกชนเช่นverifyInput(...), loadDataFromHardDisk(...), transformDataToJson(...)และในที่สุดsendJsonToClient(...)และวิธีการเหล่านี้จะมี รายละเอียดการใช้งาน

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

บทเรียนคือ: พวกเขาทั้งหมดถูกต้องเพราะพวกเขามีสิทธิ์ที่จะมีความคิดเห็น

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

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

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

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

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

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

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

เจ้าของไม่มีเวลาทำความสะอาดและไม่มีใครสนใจ

และรหัสก็ใหญ่ขึ้นเรื่อย ๆ และน่าเกลียด

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

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

ฉันมีคนอธิบายรหัสฐานว่า "การลงโทษที่โหดร้ายและผิดปกติ"

ประสบการณ์ส่วนตัวของฉันไม่ได้แย่ขนาดนั้น แต่ฉันได้เห็นบางสิ่งที่แปลกมาก

ดูเหมือนว่าคุณกำลังถามว่าสิ่งนี้จะทำงานได้อย่างไรถ้าไม่มีใครทำในสิ่งที่ควรจะทำ และถ้ามันไม่ทำงานแล้วทำไมเราควรจะทำสิ่งเหล่านี้ ?

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

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

วิธีการแก้ปัญหาคือการคิดค้นระบบใหม่ทั้งหมดเรียกว่าLibreSSLซึ่งจะใช้รหัสสะอาด ishและแน่นอนเกือบจะ ไม่มีใคร ใช้มัน

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

เหตุใดคุณจึงต้องกังวลที่จะทำสิ่งที่ ' ถูกต้อง ' ถ้าไม่มีใครทำ?

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

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

• เมื่อฉันนำเข้าห้องสมุดหรือจากห้องสมุดฉันอาจไม่พอผู้เชี่ยวชาญในโครงสร้างภายในของมันที่จะรู้ว่าส่วนเล็ก ๆ ของชุดเครื่องมือที่ฉันต้องการสำหรับสิ่งที่ฉันกำลังทำงานอยู่เว้นแต่ฉันจะคัดลอกสิ่งที่ คำตอบสแต็คแลกเปลี่ยนบอกให้ฉันทำ ดังนั้นฉันจึงเริ่มพิมพ์from A import(ถ้าอยู่ใน Python ให้พูด) และดูว่ามีอะไรเกิดขึ้นบ้าง แต่นั่นหมายถึงสิ่งที่ฉันเห็นในรายการต้องสะท้อนถึงงานลอจิคัลที่ฉันต้องยืมและนั่นคือสิ่งที่ต้องอยู่ในรหัสเบส วิธีการของผู้ช่วยนับไม่ถ้วนที่ทำให้มันสั้นลงจะทำให้ฉันสับสน
• ห้องสมุดมีไว้สำหรับโปรแกรมเมอร์ที่ไม่มีประสบการณ์มากที่สุดที่พยายามใช้อัลกอริทึมบางอย่างที่คนส่วนใหญ่เคยได้ยินมาอย่างคลุมเครือ พวกเขาต้องการเอกสารภายนอกและจำเป็นต้องสะท้อนรหัสอย่างแม่นยำซึ่งไม่สามารถทำได้หากเราทำการปรับโครงสร้างทุกอย่างเพื่อให้วิธีการแบบสั้นและสมัครพรรคพวกมีความสุข
• วิธีการห้องสมุดทุกคนที่ยืมสามารถทำลายรหัสทั่วโลกด้วยผลที่ตามมาหายนะถ้ามันถูกทำลายหรือเปลี่ยนชื่อ แน่นอนว่าฉันต้องการ sklearn จะแก้ไขพิมพ์ผิดใน Calinski-Harabaszแต่ที่อาจก่อให้เกิดอีกเหตุการณ์ที่เกิดขึ้นซ้ายแผ่น ในความเป็นจริงจากประสบการณ์ของฉันปัญหาที่ใหญ่ที่สุดเกี่ยวกับวิวัฒนาการของห้องสมุดคือเมื่อพวกเขาพยายามอย่างหนักที่จะใช้ "การปรับปรุง" ที่มีโค้ดใหม่ ๆ
• ในบ้านความเห็นส่วนใหญ่เป็นสิ่งชั่วร้ายที่จำเป็นที่สุดด้วยเหตุผลหลายประการที่ฉันไม่ต้องการสำรอก ความคิดเห็นที่ดีบอกว่าทำไมโค้ดถึงทำงานได้ไม่ดี แต่ห้องสมุดรู้ว่าผู้อ่านของพวกเขาเป็นโปรแกรมเมอร์ที่มีความสามารถซึ่งไม่สามารถพูดเขียนพีชคณิตเชิงเส้นออกจากถุงกระดาษได้ ในคำอื่น ๆทุกอย่างต้องแสดงความคิดเห็นอีกครั้ง: ทำไมมันทำงาน! (ตกลงนั่นคือการพูดเกินจริงอีก) ดังนั้นนั่นคือเหตุผลที่คุณเห็นบรรทัดลายเซ็น, บล็อกความคิดเห็น 100 บรรทัด, โค้ด 1 บรรทัดที่สามารถไปที่บรรทัดลายเซ็น (แน่นอนว่าอนุญาตให้ใช้ภาษา)
• สมมติว่าคุณอัปเดตบางอย่างใน Github และรอเพื่อดูว่ารหัสของคุณจะได้รับการยอมรับหรือไม่ จะต้องมีความชัดเจนว่าทำไมการเปลี่ยนรหัสของคุณทำงาน ฉันรู้จากประสบการณ์ว่าการปรับโครงสร้างใหม่เพื่อทำให้การทำความสะอาดที่ตั้งแคมป์เป็นส่วนหนึ่งของภาระหน้าที่มักหมายถึงการประหยัดสายการจัดเรียงและการเปลี่ยนชื่อจำนวนมากซึ่งทำให้งานของผู้ตรวจสอบไร้เงินเดือนของคุณยากขึ้น

ฉันแน่ใจว่าคนที่มีประสบการณ์มากกว่าที่ฉันสามารถพูดถึงประเด็นอื่น ๆ

มีคำตอบที่ดีอยู่แล้วจำนวนมาก - ฉันต้องการให้มุมมองของผู้ดูแลระบบโอเพนซอร์ซ

มุมมองของฉัน

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

มันทำให้ยากขึ้น - ในฐานะสมาชิกหลักของ Node.js มีบางส่วนของรหัสที่ฉันกลัวที่จะสัมผัส แต่มีงานจำนวนมากที่ต้องทำ สิ่งที่สำคัญที่สุดคือมันใช้งานได้

รหัสที่อ่านได้

เมื่อคุณพูดว่า:

ฉันพบรหัสในหลายคนที่ไม่ได้อยู่ในหลักการที่เขียนโค้ดสะอาด - เช่นวิธีการที่บรรจุโค้ดหลายร้อยบรรทัด

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

โครงการโอเพ่นซอร์สบางโครงการไม่ให้การต้อนรับด้วย

Linus "โด่งดัง"กล่าวว่า linux ไม่ควรมี debugger ในตัวเพราะผู้ที่ใช้ debuggers นั้นไม่ดีพอที่จะทำงานกับ linux และเขาไม่ต้องการดึงดูดพวกเขามากขึ้น

โดยส่วนตัวแล้วฉันไม่เห็นด้วยกับท่าทางของเขาที่นั่น - แต่มันก็เป็นสิ่งที่ผู้คนทำ

ซอฟต์แวร์โอเพ่นซอร์สไม่ได้แปลว่าผู้เขียนหลายคนมีส่วนเกี่ยวข้อง เมื่อซอฟต์แวร์ (หรือหน่วยของซอฟต์แวร์) เขียนโดยผู้เขียนคนเดียวฟังก์ชั่นที่ยาวปรากฏขึ้นบ่อยครั้ง

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

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

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

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