ฉันเป็นโปรแกรมเมอร์ที่มีประสบการณ์ 1 ปีเมื่อเร็ว ๆ นี้ฉันรู้ว่าฉันแทบจะไม่เริ่มโครงการอย่างถูกต้อง

1. เริ่มต้นด้วยการใช้งานสองสามกรณี
2. เริ่มการเข้ารหัส
3. ตระหนักถึงบางสิ่งที่ฉันไม่ได้จัดการได้ดีและไม่เหมาะกับ codebase ปัจจุบัน
4. เขียนซ้ำส่วนใหญ่ของรหัส

และสิ่งนี้อาจไปสองสามครั้ง

ดังนั้นคำถามของฉันคือ

1. การปฏิบัติเช่นนี้เป็นเรื่องปกติหรือไม่หรือฉันบอกว่าฉันไม่มีความสามารถ
2. ฉันจะปรับปรุงตัวเองในด้านนี้ได้อย่างไร?

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

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

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

1. เริ่มต้นด้วยการใช้งานสองสามกรณี
2. เริ่มการเข้ารหัส
3. ตระหนักถึงบางสิ่งที่ฉันไม่ได้จัดการได้ดีและไม่เหมาะกับ codebase ปัจจุบัน
4. เขียนซ้ำส่วนใหญ่ของรหัส

นั่นเป็นจุดเริ่มต้นที่ดีจริงๆ นี่คือวิธีที่ฉันเข้าหา:

1. เริ่มต้นด้วยการใช้งานสองสามกรณี

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

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

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

2. เริ่มการเข้ารหัส

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

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

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

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

3. พบปัญหาหรือข้อบกพร่องในการออกแบบ

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

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

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

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

4. เขียนซ้ำส่วนของรหัส

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

5. ทดสอบ

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

6. เรียนรู้

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

ตัวอย่างบางส่วน:

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

มีความคล่องตัว

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

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

นี่เป็นปกติ.

คุณสามารถใช้หนึ่งในสองวิธี:

1. ยินดีต้อนรับการเปลี่ยนแปลง

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

2. หลีกเลี่ยงการเปลี่ยนแปลง

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

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

การพัฒนาซอฟแวร์ได้รับการอธิบายเป็นชุดของปัญหาโดยเนื้อแท้ "ชั่วร้าย" แล้ว

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

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

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

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

ในหลายกรณีมีและคุณสามารถรวมเข้ากับกระบวนการออกแบบของคุณในครั้งต่อไป ในบางกรณีไม่มี (หรือค่าใช้จ่ายจะสูงหรือสูงกว่าค่าใช้จ่ายของวิธีการอื่นของคุณ) และคุณสามารถปล่อยความกังวลของคุณไป

1. ใช่มันเป็นเรื่องปกติยกเว้นในส่วน "เขียนรหัสส่วนใหญ่ใหม่" คุณจะไม่ได้รับข้อกำหนดทั้งหมดตั้งแต่ต้นดังนั้นสิ่งสำคัญคือการจัดการกับการเปลี่ยนแปลงที่ดี นั่นคือสิ่งที่แนวคิดของ "การบำรุงรักษารหัส" เป็นเรื่องเกี่ยวกับ แน่นอนว่ามันยังช่วยให้คุณใช้เวลามากขึ้นในการรับข้อกำหนดและการออกแบบที่ถูกต้อง
2. ก่อนอื่นให้คิดว่าการเปลี่ยนแปลงใดบ้างที่จำเป็นในโครงการที่ผ่านมาและวิธีที่คุณสามารถคาดการณ์สิ่งเหล่านั้นหรือเตรียมไว้ให้ดีขึ้น ที่จุดเริ่มต้นของโครงการให้คิดถึงรายละเอียดเพิ่มเติมของกรณีการใช้งาน ทำการออกแบบที่เป็นนามธรรม (ส่วนประกอบหลักของรหัสคืออะไรและพวกเขาสื่อสารกันอย่างไรว่ามี API อะไรบ้าง) ก่อนที่คุณจะเริ่มนำไปใช้ ที่สำคัญที่สุดคือพยายามรักษารหัสให้ง่ายและเปลี่ยนแปลงได้ง่ายที่สุดเท่าที่จะเป็นไปได้อ่านแนวคิดต่างๆเช่น SOLID, DRY, KISS และ YAGNI

การปฏิบัติเช่นนี้เป็นเรื่องปกติหรือไม่หรือฉันบอกว่าฉันไม่มีความสามารถ

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

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

ฉันจะปรับปรุงตัวเองในด้านนี้ได้อย่างไร?

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

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

• สิ่งหนึ่งที่มีประโยชน์
• ทำอย่างถูกต้อง
• มีประสิทธิภาพเพียงพอหรือไม่

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

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

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

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

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

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

คุณมีคำตอบที่ดีอยู่แล้ว แต่คำถามของคุณทำให้ฉันนึกถึงบางสิ่งที่ฉันคิดว่าฉันจะลองทำ

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

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

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

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

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

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

ฉันต้องการเพิ่มตัวชี้บางอย่าง

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

2) ค้นหาคู่ซ้อม - คว้ากาแฟและฟลิปชาร์ต / แผนภาพ ฯลฯ จากด้านบนและไปที่เมือง IMHO จะดียิ่งขึ้นถ้าคุณไม่มีทักษะด้านเทคโนโลยีที่ตรงกัน คุณตีกลับไปมาความคิดสำหรับการใช้ usecase คุณเจอทางตันหรือสอง - คุณหาทางแก้ไข ด้วยใจที่ว่องไวมักจะใช้เวลาน้อยลงในขั้นตอนนี้มากกว่าถ้าคุณเขียนโค้ดมันไม่ทำงานและคุณต้องฆ่าชิ้นงานหรือทำซ้ำ

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

4) กระบวนการเรียนรู้แบบเพิ่มหน่วยนี้ไม่เคยหยุดนิ่ง (และไม่ควร)! คุณจะมองย้อนกลับไปใน 10 ปีและยิ้ม

หวังว่านี่จะช่วยให้โชคดีเล็กน้อย!