เรามีความรับผิดชอบในการปรับปรุงรหัสเก่าหรือไม่?


64

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

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


คุณทำสิ่งนี้ในเวลาของคุณเองหรือใน บริษัท เล็กน้อย?
JBRWilkinson

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

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

1
เพิ่มความคิดเห็นเกี่ยวกับการปรับปรุงที่เป็นไปได้ในเอกสารและปล่อยไว้ที่?
James P.

2
เขียนหน่วยหรือการทดสอบการถดถอย อย่าเปลี่ยนรหัส แต่ให้เป็นไปได้สำหรับบางคนที่จะเข้ามาในภายหลังและทำการเปลี่ยนแปลงที่จำเป็นอย่างมั่นใจแม้จะไม่คุ้นเคยกับรหัส
James Youngman

คำตอบ:


66

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

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


4
สิ่งที่ฉันคิดคือ "ซอฟต์แวร์เน่า" และทฤษฎีหน้าต่างแตกจากโปรแกรมเมอร์ในทางปฏิบัติและผลกระทบของเอนโทรปีของซอฟต์แวร์ pragprog.com/the-pragmatic-programmer/extracts/software-entropy
jmq

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

11
@jmquigley ซอฟต์แวร์จะเน่าเสียถ้ารหัสแหล่งที่มามีการเปลี่ยนแปลงและหน้าต่างที่เสียหายจะมีผลเฉพาะเมื่อเห็นเท่านั้น codebase เก่าหากไม่จำเป็นต้องสัมผัสมันจะทำงานในลักษณะเดียวกันตราบเท่าที่สภาพแวดล้อมอนุญาต
PéterTörök

2
พยายามอย่าแนะนำข้อผิดพลาดในโปรแกรมทำงานในกระบวนการ "ปรับปรุง" it ;-)
robrambusch

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

32

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

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

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

TLDR: refactor ตามต้องการไม่มีภาระผูกพัน


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

3
@ จอห์น: ใช่นั่นคือจุดประสงค์ของการ refactoring: ปรับปรุงรหัส แต่รักษาพฤติกรรม
เบอร์นาร์ด

@John การปรับโครงสร้างที่ไม่น่าสนใจใด ๆ เสี่ยงต่อการเปลี่ยนแปลงพฤติกรรมโดยไม่ตั้งใจโดยเฉพาะอย่างยิ่งเมื่อไม่มีการทดสอบการถดถอย
Garrett Hall

14

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

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

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

จะขายซอฟต์แวร์มากกว่านี้หรือไม่

มันจะทำให้ปวดหัวน้อยลงเพื่อรองรับ?

คุณจะเรียนรู้อะไร

มันจะกลายเป็นที่ชื่นชอบมากขึ้นหรือไม่

มันจะปรับปรุงชื่อเสียงของคุณหรือไม่

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

หรือถ้าคุณต้องการคำตอบที่ง่ายกว่าเพียงแค่หยุดรับชมทีวีจนกว่าคุณจะได้รหัสคงที่ :-)


4
การยืมจากตัวอย่างจริงที่ไม่ได้อยู่ในซอฟต์แวร์ บริษัท ขนส่งบางแห่งจะจ่ายพนักงานให้ทำความสะอาดและขัดถูแท่นขุดน้ำมันของพวกเขาด้วยเหตุผลหลายประการบ่อยครั้งเพราะช่วยให้ผู้ขับขี่ / ผู้ประกอบการสร้างความภาคภูมิใจในหน่วย 'พวกเขา' ของมันและใส่ใจกับมันมากขึ้น; หลีกเลี่ยงปัญหาอย่างรวดเร็วและสะดวกสบาย ในทำนองเดียวกันหากมีไมล์ที่ต้องทำให้ขึ้นรถบรรทุกแล้วขับและกังวลเกี่ยวกับการทำความสะอาดหลังจากนั้นอีกสองสามพันไมล์ (ไปชายฝั่งสู่ชายฝั่ง)
JustinC

@justinC - แน่นอน! ตัวอย่างของคุณรวบรวมทั้งเหตุผลอื่นและค่าเสียโอกาส
MathAttack

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

6

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

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

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

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

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


5

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

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

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

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

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


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

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

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

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

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

2

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

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


4
ฉันจะเพิ่ม "และหากการเปลี่ยนแปลงมันจะไม่เพิ่มเวลาลงในตารางที่วางแผนไว้"
HLGEM

2

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

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


2

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

ทุกครั้งที่ฉันพบรหัสดั้งเดิมฉันคิดถึงสิ่งต่าง ๆ ที่ดูเหมือนจะมีความสำคัญ

  1. แล้วฉันจะเปลี่ยนแปลงอะไร?
  2. ฉันจะต้องสนับสนุนรหัสนี้หรือไม่? มันจะเกิดขึ้นเร็วแค่ไหน (ใกล้ / ไกลอนาคต)?
  3. รหัสนี้สะดวกสบายพอที่จะใช้งานหรือไม่? (ตอนนี้)
  4. ฉันมั่นใจได้หรือไม่ว่าการเปลี่ยนแปลงทั้งหมดที่ฉันทำมีความปลอดภัยหรือไม่ การทดสอบที่แตกต่างกันมักจะช่วยตอบคำถามนี้
  5. ฉันจะได้รับผลกระทบอะไรบ้างหากฉันทำผิดระหว่างการแก้ไขโค้ด เป็นไปได้ไหมที่จะเปลี่ยนกลับการเปลี่ยนแปลงของฉันอย่างรวดเร็ว? มันจะเสียเวลาหรือเปล่า?
  6. ...

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

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


2

Microsoft จำเป็นต้องอัพเดท windows หรือไม่? * * * * * * * * Distrosnix ทั้งหมดต้องพัฒนาต่อไปหรือไม่? หรือตัวอย่างที่เป็นประโยชน์มากกว่าทุกคนยังคงขับรถยนต์ของปี 1970 อยู่หรือไม่


1

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

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

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


1

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

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

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

ฉันหวังว่าจะช่วย


1

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


1

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

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

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

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

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


การเปลี่ยนแปลงรหัสการผลิตที่ไม่ได้มีเจตนาที่จะผลักดันให้เกิดการผลิต? แต่จะถูกเก็บไว้ในสาขาการพัฒนาหรือไม่ อืมม อย่าคิดว่าฉันจะยอมรับสิ่งนั้น มันจะให้บริการเพื่อทำให้สับสนและการพัฒนาในภายหลังเพราะไม่มีใครจะแน่ใจได้ว่ามันควรจะเปลี่ยน (อีกครั้ง) หรือไม่เพื่อให้สอดคล้องกับการเปลี่ยนแปลงอื่น ๆ ที่มีไว้สำหรับการผลิต
Marjan Venema

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

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

@MarjanVenema: บางทีฉันควรจะบอกว่าตั้งใจที่จะผลักดันมันให้ผลิตทันที หากคุณมั่นใจว่าการเปลี่ยนแปลงนั้นจะไม่ถูกผลักไปสู่การแยงดังนั้นอย่าทำการเปลี่ยนแปลง ถ้า OTOH คุณไม่แน่ใจ แต่การเปลี่ยนแปลงนั้นทำได้ง่ายและคุณอยู่ที่นั่นแล้ว ... ทำการเปลี่ยนแปลง สำหรับการติดตามและการทดสอบนั่นหมายถึง "ได้รับการตรวจสอบตามต้องการ"
jmoreno

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

1

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

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

ดังที่ลุงบ็อบมาร์ตินกล่าวว่า "ออกจากที่ตั้งแคมป์สะอาดกว่าที่คุณพบ"


1

นี่เป็นคำถามที่ถามผู้บริหารใน บริษัท ของคุณ

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

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

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


0

มันขึ้นอยู่กับ.

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.