การปรับเปลี่ยนรหัสและการปรับให้เหมาะสมนั้นควรอยู่ที่ไหนภายในระยะเวลากระบวนการที่คล่องตัวและน้ำตก

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

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

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

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

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

ในขณะที่การพัฒนาคุณรู้ว่าคุณมีความต้องการที่ระบบสามารถประมวลผลข้อมูลดิบ 10KB ต่อวินาที คุณทำการทดสอบโหลดและค้นหาอัลกอริทึมแบบร่างเริ่มต้นของคุณจัดการกับ 8KB / s นั่นจะไม่ผ่าน AATs คุณลองดูและเห็นว่ามีโครงสร้างลูป O (my god) บางส่วนในอัลกอริทึมของคุณ คุณปรับปรุงมันและรับ 12KB / s "ค่อนข้างดี" คุณคิดว่า "แต่ถ้าฉันมีวงวนที่แย่ในรหัสฉันจะกำจัดอะไรได้อีก?" buzzคุณเพิ่งละเมิดกฎ "การเพิ่มประสิทธิภาพก่อนกำหนด" รหัสของคุณใช้งานได้และผ่านข้อกำหนดทั้งหมด คุณ "เสร็จสิ้น" จนกว่าจะถึงเวลาตามข้อกำหนดที่ได้รับการอัปเดตเพื่อให้ใช้ 15KB / s หากเกิดขึ้นเมื่อใดคุณจะดึงรหัสสำรองและค้นหาสิ่งที่ต้องปรับปรุง

ทำตามขั้นตอนง่าย ๆ นี้ในขณะที่กำลังพัฒนาไม่ว่าจะใน Agile หรือใน SDLC แบบดั้งเดิม: "ในการผ่านครั้งแรกทำให้มันทำงานได้ในการผ่านครั้งที่สองทำให้ค่อนข้างสวยในรอบที่สามทำให้เป็นของแข็ง" สิ่งนี้หมายความว่าเมื่อคุณสร้างบรรทัดของรหัสในครั้งแรกทำให้โค้ดนั้นทำงานได้อย่างถูกต้องและปราศจากข้อผิดพลาด แต่อย่าใส่ใจกับกฎการออกแบบภายในโค้ดนี้มากเกินไปสำหรับสิ่งที่คุณรู้ในตอนนี้ จะไม่สัมผัสพื้นที่นี้อีกเลย ครั้งต่อไปที่คุณเยี่ยมชมบรรทัดของรหัสนั้นคุณแค่พิสูจน์ว่าคุณผิด มันไม่ได้เป็นส่วนหนึ่งของระบบอีกต่อไป Refactor เพื่อความสะดวกในการอ่านความรัดกุมของรหัสและ / หรือหลักการ DRY (คุณอาจวางโค้ดบางส่วนเพื่อทำสิ่งที่ห้าครั้ง; refactor ที่เป็นลูปและ / หรือการเรียกเมธอด) ครั้งที่สามที่คุณทำงานในหรือรอบ ๆ บรรทัดของรหัสนั้น

หากใช้งานได้และผ่านการทดสอบแล้วทำไมต้องแก้ไข

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

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

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

เวลา "ฉันทำได้ดีกว่านี้" ควรพอดีกับที่ใดที่หนึ่งในไทม์ไลน์หรือไม่

ใช่.

ก่อนที่คุณจะเริ่มเขียนโค้ดรุ่นถัดไป

อย่าปรับโครงสร้างตาม "สัญชาตญาณ"

Refactor ขึ้นอยู่กับเรื่องราวจริงของการวิ่งครั้งต่อไป

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

ฉันใช้วิธีเปลี่ยนสีเขียวสีแดงของ TDD ดังนั้นการปรับโครงสร้างของฉันจึงถูกสร้างขึ้นเพื่อการพัฒนาของฉัน สำหรับ refactorings ขนาดใหญ่เช่นการเปลี่ยนรูปแบบพื้นฐานหรือสิ่งที่คล้ายกันฉันจะได้รับการจัดการซื้อเพื่อใช้เวลาก่อน

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

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

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

หากฉันลองใช้วิธีอื่นในการทำให้ฟังก์ชั่นการทำงานนั้นไม่ได้แปลว่าฉันได้พบโซลูชันที่ดีที่สุดแล้ว

... ในกรณีนี้คุณยังไม่ได้ทำ 100% ...

หรือไม่ต้องมีการทำใหม่หลังจากตรวจสอบกับผู้พัฒนารายอื่นแล้ว

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

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

มันขึ้นอยู่กับ. หากหมายถึงการปรับโครงสร้างใหม่ควรเป็นส่วนหนึ่งของภารกิจการพัฒนาดั้งเดิม ถ้ามันหมายถึงการทดลองด้วยอัลกอริธึมที่ดีกว่ามันอาจเป็นงานแยกต่างหาก

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

โดยย่อเนื่องจากรหัสสามารถแตกได้หลายระดับ

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

สำหรับคำตอบโดยละเอียดเพิ่มเติมดูหัวข้อนี้

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

คำตอบที่ดีที่สุดที่กล่าวถึงหนี้ทางเทคนิค น่าเสียดายที่นี่เป็นความจริงที่น่าเศร้าของซอฟต์แวร์ในองค์กรหลายแห่งที่ความเร่งรีบในการรับสิ่งต่าง ๆ ออกมาไม่ว่าจะเป็นวิธีการที่คล่องตัวหรือไม่คล่องตัวนั้นเป็นเรื่องธรรมดา หาเหตุผลเข้าข้างตนเองว่าเป็นสิ่งที่ดี: "ตรงตามข้อกำหนดทางธุรกิจขั้นต่ำ" และ "YAGNI" (เกี่ยวกับการรักษาความสะอาดของรหัส)

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

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