วิธีหลีกเลี่ยงการเขียนใหม่บางส่วนของแอปพลิเคชัน

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

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

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

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

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

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

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

อย่ากลัวที่จะถามหลาย ๆ ครั้งตามที่คุณต้องการ บางครั้งต้นไม้ (รายละเอียด) อย่าให้เราเห็นป่า (ภาพรวม) และมันเป็นป่าที่เราต้องเห็นก่อน

เมื่อความต้องการชัดเจนขึ้นการตัดสินใจได้ง่ายขึ้นระหว่างขั้นตอนการออกแบบ

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

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

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

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

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

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

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

คำตอบง่ายๆคือไม่มีสิ่งใดที่ไม่มีการเขียนใหม่เลย

การพัฒนาซ้ำ (ซึ่งเป็นสิ่งที่คุณทำโดยทั่วไปแม้ว่าการทำซ้ำหนึ่งวัน) มักจะเป็นเช่นนี้ ความพยายามครั้งแรกในการแก้ปัญหามักจะไม่ได้ทำเครื่องหมายและโดยการรวบรวมคำติชมระบบจะรวมเข้ากับโซลูชัน ฉันจะยืมรูปที่ 2.2 จากวัสดุผู้สอนของ Craig Larman สำหรับหนังสือ Apply UML และ Design Patterns ของเขา

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

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

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

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

นี่อาจฟังดูเป็นเรื่องเกี่ยวกับศาสนาพุทธ แต่คุณโชคดีที่ได้เขียนบทความเหล่านี้อีกครั้ง! ผู้คนจำนวนมากเรียนรู้เกี่ยวกับรูปแบบ MVC หรือรูปแบบการออกแบบอื่น ๆ โดยไม่ต้อง "ได้รับความเดือดร้อน" ผู้เขียนฝันร้ายอีกครั้งถึงรูปแบบที่ควรหลีกเลี่ยง

ฉันไม่ได้รับคำตอบมากเท่าการออกกำลังกาย - อย่างที่คุณอาจต้องทำในเวลาของคุณเองถึงแม้ว่าคุณจะได้รับอนุญาตให้ทำในช่วงเวลาทำงาน

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

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

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

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

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

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