ฉันควรปรับเปลี่ยนรหัสที่ทำเครื่องหมายว่า“ ไม่เปลี่ยนแปลง” หรือไม่

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

ในระหว่างการเปลี่ยนโครงสร้างเป็นครั้งคราวฉันพบชั้นเรียนวิธีการหรือบรรทัดของรหัสที่มีความคิดเห็นเช่น

หมดเวลาตั้งค่าให้โมดูล A เวลาในการทำสิ่งต่างๆ หากไม่ได้ตั้งเวลาเช่นนี้มันจะหยุด

หรือ

อย่าเปลี่ยนสิ่งนี้ เชื่อฉันสิคุณจะทำลายสิ่งต่างๆ

หรือ

ฉันรู้ว่าการใช้ setTimeout ไม่ใช่วิธีปฏิบัติที่ดี แต่ในกรณีนี้ฉันต้องใช้

คำถามของฉันคือ: ฉันควร refactor รหัสเมื่อฉันพบคำเตือนดังกล่าวจากผู้เขียน (ไม่ฉันไม่สามารถติดต่อกับผู้เขียน)?

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

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

นี่คือกลยุทธ์ที่ดีกว่า: ใช้เวลาของคุณเพื่อ

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

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

• สอนเพื่อนร่วมงานของคุณเกี่ยวกับ "หลักการลูกเสือ" (AKA "การปรับโครงสร้างแบบฉวยโอกาส" ) ดังนั้นเมื่อทีมเริ่มเพิ่มคุณสมบัติใหม่ (หรือแก้ไขข้อบกพร่อง) พวกเขาควรปรับปรุงและปรับโครงสร้างส่วนของรหัสฐานที่พวกเขาต้องการ ไม่น้อยไม่มาก

• รับสำเนาของหนังสือ Feather "การทำงานอย่างมีประสิทธิภาพด้วยรหัสดั้งเดิม" สำหรับทีม

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

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

ใช่คุณควร refactor รหัสก่อนที่คุณจะเพิ่มคุณสมบัติอื่น ๆ

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

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

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

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

คำถามของฉันคือฉันควร refactor รหัสเมื่อฉันพบคำเตือนดังกล่าวจากผู้เขียน

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

สำหรับตอนนี้เราไม่สามารถเพิ่มฟีเจอร์ใด ๆ ได้อีกต่อไปโดยไม่ทำลายอย่างอื่น

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

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

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

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

เมื่อคุณเพิ่มคุณสมบัติใหม่ให้เพิ่มการทดสอบพื้นฐานอย่างน้อยที่สุดว่าคุณสมบัติใหม่นั้นทำงานได้ตามที่ต้องการ

อาจได้รับสำเนาของ "การทำงานอย่างมีประสิทธิภาพด้วยรหัสมรดก" หรือไม่?

ฉันได้รับสองสามเดือนเพื่อ refactor รหัสที่มีอยู่

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

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

จำรั้วของ GK Chesterton : อย่ารื้อรั้วที่กั้นถนนจนกว่าคุณจะเข้าใจว่าทำไมมันถึงถูกสร้างขึ้น

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

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

ก่อนหน้านั้นฉันจะไม่แตะต้องรหัสที่มีเครื่องหมาย "ห้ามแตะ"

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

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

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

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

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

อาจไม่ใช่ความคิดที่ดีที่จะสร้างโค้ดใหม่ด้วยคำเตือนดังกล่าวหากสิ่งต่าง ๆ ทำงานได้ตามปกติ

แต่ถ้าคุณต้อง refactor ...

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

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

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

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

ปัญหากลางที่นี่เป็นที่ (ตามที่ระบุไว้ในคำตอบบางส่วน) ความคิดเห็นที่คุณพูดยิ่งแสดงให้เห็นว่ารหัสมีสภาพการแข่งขันหรือปัญหาที่เห็นพ้อง / ประสานอื่น ๆ เช่นการกล่าวถึงที่นี่ ปัญหาเหล่านี้เป็นปัญหาที่ยากเป็นพิเศษด้วยเหตุผลหลายประการ ประการแรกตามที่คุณพบการเปลี่ยนแปลงที่ไม่เกี่ยวข้องดูเหมือนจะทำให้เกิดปัญหา (ข้อผิดพลาดอื่น ๆ สามารถมีผลกระทบนี้ แต่ข้อผิดพลาดเกิดขึ้นพร้อมกันเกือบทุกครั้ง) ประการที่สองพวกเขายากที่จะวินิจฉัย: ข้อผิดพลาดมักจะปรากฏตัวในสถานที่ ห่างจากเวลาหรือรหัสจากสาเหตุและสิ่งที่คุณทำเพื่อวินิจฉัยอาจทำให้หายไป ( Heisenbugs) ประการที่สามบั๊กที่เกิดขึ้นพร้อมกันนั้นหาได้ยากมากในการทดสอบ ส่วนหนึ่งเป็นเพราะการระเบิดแบบ combinatorial: มันไม่ดีพอสำหรับซีเควนเชียลโค้ด แต่การเพิ่ม interleavings ที่เป็นไปได้ของการประมวลผลที่เกิดขึ้นพร้อมกันนั้นทำให้มันถึงจุดที่ปัญหาลำดับนั้นไม่มีนัยสำคัญในการเปรียบเทียบ นอกจากนี้แม้กระทั่งกรณีทดสอบที่ดีอาจทำให้เกิดปัญหาได้ในบางครั้งเท่านั้น - Nancy Leveson คำนวณว่าหนึ่งในแมลงร้ายในTherac 25เกิดขึ้นในการวิ่ง 1 ครั้งประมาณ 350 ครั้ง แต่ถ้าคุณไม่รู้ว่าข้อผิดพลาดคืออะไรหรือแม้กระทั่งว่ามีข้อผิดพลาดเกิดขึ้นคุณไม่ทราบว่าการทำซ้ำหลายครั้งทำให้การทดสอบมีประสิทธิภาพ นอกจากนี้การทดสอบแบบอัตโนมัติเท่านั้นที่ทำได้ในระดับนี้และเป็นไปได้ที่โปรแกรมควบคุมการทดสอบจะกำหนดข้อ จำกัด ด้านเวลาอย่างละเอียดซึ่งจะไม่ทำให้เกิดข้อผิดพลาด (Heisenbugs อีกครั้ง)

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

เพื่อเพิ่มความยากลำบากในการคอมไพเลอร์ (และแม้โปรเซสเซอร์ที่รันไทม์) มักจะมีอิสระในการจัดระเบียบรหัสในรูปแบบที่บางครั้งทำให้เหตุผลเกี่ยวกับหัวข้อความปลอดภัยมากเคาน์เตอร์ (อาจจะเป็นกรณีที่รู้จักกันดีคือการตรวจสอบสองครั้ง lock idiom แม้ว่าบางสภาพแวดล้อม (Java, C ++ ... ) ได้รับการแก้ไขเพื่อแก้ไขให้ดีขึ้น)

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

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

ในระหว่างการเปลี่ยนโครงสร้างเป็นครั้งคราวฉันพบชั้นเรียนวิธีการหรือบรรทัดของรหัสที่มีความคิดเห็นเช่น ["อย่าแตะต้องสิ่งนี้!"]

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

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

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

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

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

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

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

ตอนนี้ให้เรากลับไปที่สิ่งที่ต้องทำของเราเองและสิ่งที่เรารู้ว่าสามารถปรับปรุงในการสร้างรหัสของเราเองหากมีเวลามากขึ้น

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

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

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

หมดเวลาตั้งค่าให้โมดูล A เวลาในการทำสิ่งต่างๆ หากไม่ได้ตั้งเวลาเช่นนี้มันจะหยุด

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

อย่าเปลี่ยนสิ่งนี้ เชื่อฉันสิคุณจะทำลายสิ่งต่างๆ

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

ฉันรู้ว่าการใช้ setTimeout ไม่ใช่วิธีปฏิบัติที่ดี แต่ในกรณีนี้ฉันต้องใช้

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

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

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

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

รหัสอาจได้รับการพัฒนาผ่านการคาดเดาและการลองผิดลองถูกโดยไม่ต้องเข้าใจว่าเกิดอะไรขึ้นจริง

หมายความว่า:

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

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

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

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

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

คำถามที่ฉันถามคือทำไมมีคนเขียนอย่าแก้ไขตั้งแต่แรก

ฉันทำงานกับโค้ดจำนวนมากและบางอันก็น่าเกลียดและใช้เวลาและความพยายามมากในการทำงานภายใต้ข้อ จำกัด ที่กำหนดในเวลานั้น

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

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

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

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

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

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