การเขียนโค้ดโฆษณามีอะไรเลวร้าย [ปิด]

ฉันกำลังดูBob Rossวาดคืน "ต้นไม้แห่งความสุข" คืนนี้และฉันก็พบว่ามีอะไรที่ทำให้ฉันเครียดเกี่ยวกับรหัสของฉันเมื่อเร็ว ๆ นี้

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

ให้ฉันอธิบายสิ่งที่ฉันหมายถึงโดย "การเข้ารหัสอย่างสร้างสรรค์":

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

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

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

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

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

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

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

ไม่มีอะไรผิดปกติกับ code-test-refactor-repeat เพียงแค่บอกคนที่คุณกำลังต้นแบบ

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

PS: เทคนิคการสร้างแผนภาพช่วยให้คุณเรียนรู้ทักษะการคิดภาพซึ่งมีค่าแม้ว่าจะไม่มีใคร แต่คุณเคยเห็นไดอะแกรมของคุณ

ฉันชอบโค้ดที่ชัดเจนอ่านง่ายและเรียบง่ายสำหรับโค้ดที่มีการออกแบบ UMLed ที่มีรูปแบบการมองเห็นซึ่งคลาส / ส่วนต่อประสานมีชื่อรูปแบบเช่น "ItemVisitor" (?!) รูปแบบการออกแบบเทคนิค OO และทุกอย่างอื่นคือการทำให้เป็นระเบียบกฎ กฎนั้นมาจากสามัญสำนึก

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

อย่าลังเลที่จะเขียนโค้ดของคุณอีกครั้ง ฉันจะได้รับ downvotes X (X> = 10) นี้ แต่ฉันจะทำให้มันหนา: สามารถนำมาใช้รหัสไม่ได้เป็นสิ่งที่สำคัญที่สุด

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

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

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

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

1. ลองใช้สิ่งต่างๆเพื่อหาวิธีที่ดีที่สุด (การทดลองการออกแบบที่เพิ่มขึ้น)
2. การเขียนโค้ดซ้ำเพื่อทำให้มันสะอาดขึ้น
3. การทดสอบการเขียนอย่างต่อเนื่อง (การทดสอบขับเคลื่อนการพัฒนา)

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

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

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

แบรดคุณไม่ได้อยู่คนเดียว ฉันรู้โปรแกรมเมอร์ดีมากที่ทำงานในลักษณะเดียวกับที่คุณอธิบาย :)

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

นอกจากนี้ไม่สามารถวางแผนล่วงหน้าได้อย่างเต็มที่และเส้นทางที่สั้นที่สุดในการค้นหารายละเอียดย่อยมักจะเรียกใช้รหัสและเข้าใจรายละเอียดที่ถูกมองข้าม

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

ฉันคิดว่ามันคุ้มค่าที่จะตอบคำถามข้างต้นโดยอ้างจาก Alan J. Perlis จากคำนำของ MIT หนังสือที่รู้จักกันดี "โครงสร้างและการตีความของโปรแกรมคอมพิวเตอร์" ที่เรียกกันทั่วไปว่า "SICP":

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

มีเคลฟเวอร์ที่ดีและไม่ฉลาด

Good Clever - อัตราส่วนสูงระหว่างบรรทัดที่ฉลาดของโค้ดเทียบกับบรรทัดของทางเลือกที่ไม่ฉลาด 20 บรรทัดของรหัสที่ช่วยให้คุณประหยัดจากการเขียน 20,000 เป็นอย่างยิ่งที่ฉลาด Good Clever เกี่ยวกับการช่วยตัวเองให้ทำงาน

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

ข้อควรทราบ: Bad Clever แทบไม่เคยถูกเรียกว่า "Bad Clever" มันมักจะเดินทางภายใต้นามแฝงว่า "สวยงาม", "สง่างาม", "รัดกุม" หรือ "รวบรัด"

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

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

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

ดังนั้นสิ่งต่าง ๆ เช่นการวางแผนตามแผนที่ตกลงไว้ล่วงหน้า ฯลฯ ... สิ่งเหล่านี้เกี่ยวกับการมีทีมงานบนกระดานและซิงค์กัน หากคุณเป็นทีมคุณจะต้องซิงค์กับตัวเองและไม่จำเป็นจริงๆ

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

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

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

สองมุมมอง:

1. ไม่มีใครต้องรักษาภาพวาด

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

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

แต่ฉันอยากรู้เกี่ยวกับเรื่องนี้:

ชุมชนของคนที่นี่และใน Stack Overflow ดูเหมือนจะปฏิเสธความไม่สมบูรณ์ใด ๆ [.. ] กระบวนการของฉันดูเหมือนจะขัดกับสิ่งที่ยอมรับได้ในชุมชนนักพัฒนามืออาชีพและฉันต้องการที่จะเข้าใจว่าทำไม

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

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

ฉันยังใช้วิธีการของคุณ มันทำงานได้ดีขึ้นสำหรับฉันเพราะมันช่วยลดความเสี่ยงของการ overengineering

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

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

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

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

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

เมื่อฉันได้ยินการพูดคุยของ Edsger Dijkstra พูดถึงความคิดสร้างสรรค์ในการเขียนโปรแกรม เขากล่าวถึงวิธีที่นักเรียนพบวิธีที่จะหมุน n-bit ของคำว่า n + m-bit มันทำด้วย 3 bitswaps ขั้นแรกคุณสลับ n บิตจากนั้นคุณสลับบิต m จากนั้นคุณสลับบิต n + m ทั้งหมด มีประโยชน์หรือไม่ เลขที่ฉลาด? ใช่.

รู้สึกดีที่ได้ลองทำในสิ่งที่ไม่มีใครคิดถูก

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

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

คุณอาจสนใจอ่านDreaming in Codeเพื่อดูว่าจะเกิดอะไรขึ้นเมื่อโครงการขนาดใหญ่มีรูปแบบการพัฒนาคล้ายกับของคุณ

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

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

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

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

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

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

และอย่างที่คนอื่นพูด: นี่คือ วิธีของฉันไมล์สะสมของคุณอาจแตกต่างกันไป