มารยาทที่มาเปิด

ฉันเริ่มทำงานในโครงการโอเพนซอร์สแห่งแรกของฉันบน Codeplex และเจอรหัสที่แย่มาก (ฉันเรียนรู้ว่า C # ยังคงมีคำสั่ง "goto") ฉันเริ่มเพิ่มคุณสมบัติที่ "เจ้าของ" ต้องการและหลังจากสำรวจรหัสฐานและเห็นว่ามันยุ่งเหยิง (เช่นใช้ "goto") ฉันต้องการทำความสะอาด นิดหน่อย. แต่ฉันเป็นกังวลเล็กน้อยและนั่นคือเหตุผลที่ฉันหันไปหาคุณทุกคน: มันเป็นมารยาทที่เหมาะสมสำหรับฉันที่จะ "แก้ไข" "รหัสไม่ดี" หรือฉันควรปล่อยให้มันเป็นและทำงานกับคุณสมบัติใหม่หรือไม่? อย่างที่ฉันพูดไว้ก่อนหน้านี้ฉันยังใหม่กับฉาก OSS ทั้งหมดและทำงานเป็นทีมโดยทั่วไปดังนั้นฉันจึงไม่ต้องการทำให้ยุ่งเหยิง

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

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

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

โปรดจำไว้ว่าในแหล่งที่มาเปิดชุมชนสำคัญกว่ารหัส หากไม่มีชุมชน (ทั้งผู้ใช้และนักพัฒนา) แสดงว่าไม่มีโครงการ

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

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

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

หากปรากฎว่ามีเหตุผลที่ดีที่จะทิ้งไว้ฉันจะผลักดันอย่างน้อยสำหรับความคิดเห็นที่อธิบายถึงเหตุผลเหล่านั้น

พูดจากประสบการณ์ ...

โครงการโอเพ่นซอร์สครั้งแรกที่ฉันมีส่วนฉันเต็มไปด้วยปัสสาวะและน้ำส้มเมื่อฉันเริ่มด้วย

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

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

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

การสร้างรหัสใหม่และการเพิ่มฟังก์ชันการทำงาน (หรือลบ cruft ที่เลิกใช้แล้ว) มักจะมีความสำคัญมากกว่ารหัส 'การทำความสะอาด'

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

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

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

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

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

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

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

ในโลกโอเพ่นซอร์สสไตล์นั้นไม่สำคัญ ฟังก์ชั่นคือ

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

คุณภาพ> มารยาท

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

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

การสื่อสารกับผู้แต่งดั้งเดิมเป็นความคิดที่ดี

gotoไม่มีอะไรผิดปกติกับ implictly คือ ดูรหัสแอสเซมบลี - gotos มากมาย (กระโดดและสาขา) ทั่วทุกที่

เหตุผลที่gotoมีชื่อไม่ดีในวันนี้เป็นเพราะคำสั่ง Go Toกระดาษถือว่าเป็นอันตรายซึ่งระบุคำสั่ง goto เป็นสิ่งที่เลวร้ายมาก

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

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

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