เมื่อไรที่จะไม่แก้ไข windows ที่เสียหาย

ในการอ้างอิงถึงหน้าต่างที่ใช้งานไม่ได้มีบางครั้งที่การปรับโครงสร้างสิ่งที่ดีที่สุดสำหรับกิจกรรมในอนาคตใช่หรือไม่

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

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

"ทำให้มันทำงานแล้วทำให้มันทำงานได้ดีขึ้น"

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

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

คุณได้รับรหัสการทำงานจากนั้นคุณ refactor รหัสของคุณเพื่อให้แน่ใจว่าคุณมีการใช้งานที่ดีที่สุดที่คุณสามารถใช้ หากคุณกำลังทำสิ่งที่คุ้นเคยอาจเป็นไปได้ว่าคุณใช้รหัสที่ดีที่สุดในครั้งแรก แต่อาจต้องใช้เวลาสักครู่เพื่อตรวจสอบงานของคุณอีกครั้ง หากดูเหมือนว่าคุณสามารถปรับปรุงรหัสของคุณได้คุณควรลองปรับโครงสร้างใหม่เพื่อให้แน่ใจว่ารหัสของคุณนั้นน้อยและสะอาดเท่าที่คุณสามารถทำได้ ซึ่งหมายความว่าคุณกำลังลดจำนวนหนี้ด้านเทคนิคที่คุณทิ้งไว้และทำให้คุณสามารถอ่านและปรับโครงสร้างได้ง่ายขึ้นในครั้งต่อไปที่ต้องจัดการกับรหัส นี่คือค่าหลักที่อยู่เบื้องหลังมนต์ TDD "Red-Green-Refactor" ยกเว้นว่าใน TDD ที่คุณ refactor เป็นหลักในการลบการทำซ้ำมันจ่ายเพื่อตรวจสอบรายการอื่น ๆ ที่สามารถ refactored เช่นชั้นเรียนขนาดใหญ่วิธีการยาว

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

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

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

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

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

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

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

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

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

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

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

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

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

สถานการณ์ที่สิ่งนี้อาจเกิดขึ้น:

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

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

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

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

และถ้าไม่มีทางเลือกที่ดีอยู่เสมอ แต่เมื่อไหร่เราจะแก้ไข

เพราะมันควรเกือบเกือบเกือบเสมอเมื่อไม่ถ้า

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

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

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

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

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

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

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

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

ไม่ว่าจะคุ้มค่าหรือไม่นั้นขึ้นอยู่กับผู้จัดการของคุณเป็นส่วนใหญ่

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

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

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

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

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

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

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

• หากการกู้แฟคตอริ่งใหม่จะมีผลกระทบทางลบต่อความสามารถในการทำกำไรของธุรกิจก็ควรมีการกำหนดตารางเวลาใหม่

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

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

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

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

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

ถ้ามันแตกจริงควรแก้ไข

แต่มันพังจริงๆเหรอ? คุณแน่ใจหรือว่าไม่เพียงแค่เทียบ "ไม่สวย" กับความเสียหาย

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

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

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

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

รหัส Re-Factoring ที่มีการใช้งานมาระยะหนึ่งแล้วผ่านการเผยแพร่และการแก้ไขข้อบกพร่องหลายครั้ง หากคุณไม่ทราบว่าซอฟต์แวร์กำลังจะหยุดทำงานไม่ต้องไปที่นั่น!

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

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