รหัสทางวิทยาศาสตร์เป็นขอบเขตที่แตกต่างกันมากพอที่จะเพิกเฉยต่อมาตรฐานการเข้ารหัสทั่วไปหรือไม่?

เมื่อไม่นานมานี้ฉันพยายามจะปิดปากเรื่องดังต่อไปนี้

ในอีกด้านหนึ่งมีโฮสต์ของแนวทางการเข้ารหัสและมาตรฐานสำหรับสิ่งที่ถือว่าเป็น "สุขภาพ", "สะอาด", "ดีเขียน" และอื่น ๆ รหัส ดู "รหัสสะอาด" ที่ดูเหมือนจะพูดถึงกันอย่างกว้างขวางที่นี่เช่นกัน กฎตัวอย่าง: วิธียาว 7 บรรทัดและ 1 หรือ 2 ระดับของการเยื้อง รหัสที่ไม่ได้ปฏิบัติตามคาดว่าจะตายจากการบำรุงรักษาที่ไม่ดี

ในทางกลับกันฉันได้ทำงานกับ OpenCV, OpenCascade, VTK และอื่น ๆ มันเป็นรหัสทางวิทยาศาสตร์ พวกเขามีวิธีการยาว 2 หน้า (sen ตัวเอง), OpenCascade มีวิธีการหรือคลาสแบ่งออกเป็น 10 ไฟล์ (ไม่มีเรื่องตลกที่นี่) VTK เป็นระเบียบในบางครั้งเช่นกัน แต่โครงการเหล่านี้ประสบความสำเร็จได้รับการดูแลและใช้อย่างกว้างขวาง!

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

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

รหัสทางวิทยาศาสตร์เป็นขอบเขตที่แตกต่างกันมากพอที่จะเพิกเฉยต่อมาตรฐานการเข้ารหัสทั่วไปหรือไม่?

ไม่มันไม่ใช่.

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

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

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

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

แต่โครงการเหล่านี้ประสบความสำเร็จได้รับการดูแลและใช้อย่างกว้างขวาง!

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

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

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

หากการดำเนินงานนี้ได้รับการแยกออกไปและออกแบบมาอย่างดีโปร่งใสนี้จะได้รับการสูญเสียให้กับโปรแกรมเมอร์ไม่ใช่

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

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

ความจริงก็คือหลายโครงการเริ่มต้นและตาย เปอร์เซ็นต์เล็ก ๆ น้อย ๆ อย่างน่าขันของโครงการ "ทำให้" ถึงระดับของ OpenCV หรือ VTK เป็นต้น

OpenCV เริ่มต้นเป็นโครงการวิจัยจาก Intel Wikipedia อธิบายว่ามันเป็นส่วนหนึ่งของ "ชุดโครงการ" รุ่นแรกที่ไม่ใช่รุ่นเบต้าคือปี 2549 หรือเจ็ดปีหลังจากเริ่มใช้งานครั้งแรก ฉันสงสัยว่าเป้าหมายในตอนแรกนั้นเป็นรุ่นเบต้าที่มีความหมายไม่ใช่โค้ดที่สมบูรณ์แบบ

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

ฉันควรจะชี้ให้เห็นว่า OpenCV เป็นเวลาหลายปีก่อนประกาศ Agile ที่ Clean Code ได้รับแรงบันดาลใจจากการตีพิมพ์ (และ VTK เกือบ 10) VTK เริ่มต้นเมื่อ 17 ปีก่อนการเผยแพร่ Clean Code (OpenCV คือ "เท่านั้น" 9 ปีก่อน)

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

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

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

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

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

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

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

คำตอบที่มีอยู่ทั้งหมดได้ครอบคลุมคำถามนี้อย่างครอบคลุม อย่างไรก็ตามฉันต้องการจะชี้ให้เห็นว่าอะไรคือantipode ที่แท้จริงระหว่างไลค์ของ OpenCV และอื่น ๆ เมื่อเทียบกับโค้ดที่พัฒนาขึ้นตามแนวทางการดำเนินธุรกิจที่ดี (Code Complete, Clean Code, SOLID ฯลฯ )

โดยทั่วไปมีประโยชน์ทางธุรกิจมากมายสำหรับซอร์สโค้ดที่จะเป็น KISS - "ทำให้มันง่ายโง่" นอกจากนี้ยังมี YAGNI ที่เกี่ยวข้อง - "คุณไม่ต้องการมัน"

แต่น่าเสียดายที่เข้มข้นสำหรับซอฟต์แวร์คอมพิวเตอร์ในโดเมนทางวิทยาศาสตร์รหัสที่มาไม่ค่อยง่ายหรือไม่ติดมัน

ตามเนื้อผ้า OpenCV ได้รับความเดือดร้อนจากการขาดการสรุป (การทำสำเนารหัสจำนวนมากเพื่อสนับสนุนตัวเลือกที่แตกต่างกัน) ในขณะที่ VTK ได้รับความเดือดร้อนจากการสรุปทั่วไปมากเกินไป (แม่แบบ)

ในวันแรกบางส่วนของ OpenCV ได้รับการพัฒนาในซีต่อมา OpenCV นำ C ++ API ที่เราคุ้นเคยมาจนถึงทุกวันนี้ อัลกอริทึมบางอย่างถูกเขียนขึ้นใหม่เพื่อใช้ประโยชน์จากอินเทอร์เฟซ C ++ (คลาสฐานนามธรรม) และเทมเพลต C ++ อัลกอริธึมอื่น ๆ เป็นเพียงการห่อหุ้มสำหรับรหัส C ดั้งเดิม เศษของรหัสเหล่านี้สามารถพบได้ในโมดูล "imgproc"

OpenCV มีการเขียนโปรแกรม SIMD จำนวนมาก (vectorization) จนถึงวันนี้การเขียนโปรแกรม SIMD ใน C ++ ยังคงต้องใช้intrinsics (intel.com) , (arm.com)

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

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

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

ปัจจัยสนับสนุนหลักคือ:

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

ปัจจัยที่สนับสนุนหลายประการข้างต้นคือการต่อต้านการพัฒนาซอฟต์แวร์ธุรกิจ:

• โดยทั่วไปซอฟต์แวร์ธุรกิจไม่จำเป็นต้องจัดการกับปริมาณข้อมูลสูงเช่นเดียวกับที่เห็นในซอฟต์แวร์คอมพิวเตอร์
• ซอฟต์แวร์ธุรกิจสามารถเชื่อมโยงกับระบบปฏิบัติการเดียวและสถาปัตยกรรมคอมพิวเตอร์
• ซอฟต์แวร์ธุรกิจสามารถประหยัดในการตัดสินใจว่าจะรวมฟังก์ชั่นใด ในความเป็นจริงการพัฒนาซอฟต์แวร์ธุรกิจสนับสนุนให้ผู้จัดการบอกว่าไม่ต้องใช้คุณสมบัติใหม่เว้นแต่จะมีกรณีธุรกิจที่ดี
  • ผู้ใช้ซอฟต์แวร์ธุรกิจภายในสามารถได้รับการฝึกฝนให้ทำสิ่งต่าง ๆ โดยหลีกเลี่ยงความต้องการในการเปลี่ยนแปลงรหัส
  • หากซอฟต์แวร์ธุรกิจเชิงพาณิชย์สูญเสียลูกค้าหนึ่งรายเนื่องจากขาดคุณสมบัติหนึ่ง แต่ได้ลูกค้าใหม่สองรายเนื่องจากการปรับปรุงความเรียบง่ายและใช้งานง่ายขึ้น (ดู"The Paradox of Choice" ) โดยรวมแล้วเป็นกำไรสุทธิ - เป็นสิ่งที่ดี สิ่งที่คุณสมบัตินี้หายไป
• ซอฟต์แวร์ธุรกิจได้รับการสนับสนุนจากกระแสรายได้อย่างต่อเนื่องเพื่อให้สามารถใช้เป็นส่วนหนึ่งกับการปรับปรุงฐานรหัสอย่างต่อเนื่อง

รหัสทางวิทยาศาสตร์เป็นขอบเขตที่แตกต่างกันมากพอที่จะเพิกเฉยต่อมาตรฐานการเข้ารหัสทั่วไปหรือไม่?

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

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

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

ให้เราดูตัวอย่างโค้ดที่ฉันคิดว่าเป็น "โค้ดสะอาด" ในแง่ของการมองเห็นคอมพิวเตอร์และการเข้าใจภาพ:

https://github.com/opencv/opencv/blob/05b15943d6a42c99e5f921b7dbaa8323f3c042c6/modules/photo/src/seamless_cloning_impl.cpp

สำหรับผู้ที่คุ้นเคยกับ MATLAB และการคำนวณทางวิทยาศาสตร์รหัสใน C ++ นั้นเกือบจะรัดกุมเทียบเท่ากับรหัส MATLAB ที่เป็นไปได้ที่สะอาดที่สุด

ตอนนี้เราต้องถามว่าทำไมรหัสฐานไลบรารีทั้งหมด (OpenCV ในตัวอย่างนี้) จึงไม่เขียนเป็นมาตรฐานเดียวกันกับตัวอย่างโค้ดนี้

เราต้องแบ่งเป็นชั้นฐานรหัสห้องสมุดวิทยาศาสตร์ขนาดใหญ่เข้าสู่ระดับที่เป็นนามธรรม

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

https://github.com/opencv/opencv/blob/master/modules/core/src/hal_replacement.hpp

ระดับกลางเป็นที่ที่เราพบว่ารหัส "สกปรก" ภายในซึ่งอาจจะ 80% - 90% ของเวลา CPU ดำเนินการคือการใช้จ่าย (ในทำนองเดียวกันอาจใช้ความพยายามในการพัฒนา 80% - 90% ในระดับกลางหากเรานับความพยายามในการพัฒนาซอฟต์แวร์แยกต่างหากจากการวิจัยทางวิทยาศาสตร์)

ในระดับสูงเรามีโค้ดที่สะอาดที่สุดเขียนโดยนักวิจัย

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

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