จะเถียงกับการลดมาตรฐานคุณภาพสำหรับ codebase แบบเดิมได้อย่างไร [ปิด]

28

เรามีฐานรหัสดั้งเดิมขนาดใหญ่ที่มีรหัสไม่ดีซึ่งคุณไม่สามารถจินตนาการได้

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

และเราบังคับใช้กับ Sonar (เครื่องมือวิเคราะห์รหัส) ซึ่งมีการละเมิดหลายพันครั้งแล้ว

ตอนนี้การสนทนาขึ้นมาเพื่อลดการละเมิดเหล่านั้นสำหรับมรดก เพราะมันเป็นมรดก

การสนทนาเป็นเรื่องเกี่ยวกับกฎของการอ่าน ชอบจำนวน ifs ที่ซ้อนกัน / for .. มันสามารถมีได้

ตอนนี้ฉันจะเถียงกับการลดคุณภาพการเข้ารหัสของเราลงบนรหัสดั้งเดิมได้อย่างไร

code-quality static-analysis legacy-code

— Keiki
แหล่งที่มา

2

การสนทนาเกี่ยวกับการลดเกณฑ์ของเครื่องมือคืออะไร? ... หรือฉันเข้าใจผิด มันเขียนในลักษณะที่สับสน

— dagnelies

13

ฉันจะอธิบาย $ {some} ถึง $ {someone} ได้อย่างไร

— ริ้น

4

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

— Doc Brown

4

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

— Bernhard Hiller

4

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

— Doc Brown

73

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

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

— เบรนแดน
แหล่งที่มา

15

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

— Alessandro Teruzzi

21

@AlessandroTeruzzi คุณสามารถปฏิเสธที่จะทำสิ่งใดก็ได้ในพื้นที่ทางศีลธรรมได้ทุกที่โดยไม่คำนึงถึงความเป็นมืออาชีพ ไม่รับประกันว่าคุณจะยังคงทำงานในสถานที่นั้น

— Kromster พูดว่าสนับสนุน Monica

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

— mkataja

17

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

— Doc Brown

2

@DocBrown ฉันเห็นด้วยอย่างไม่แน่นอน แต่ฉันคิดว่าการพัฒนาที่ขับเคลื่อนด้วยจำนวนซ้อนกันเป็น la OP ไม่ใช่วิธีการที่มีประสิทธิภาพในการปรับปรุง codebase แบบดั้งเดิม

— brian_o

44

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

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

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

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

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

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

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

— John Forkosh
แหล่งที่มา

2

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

— Basilevs

9

ตรงนี้คำถามที่อยู่ซึ่งไม่เกี่ยวกับการเขียนใหม่ OP ต้องการโต้แย้งว่า 'จัดการการบำรุงรักษารหัสดั้งเดิมในแบบเดียวกับที่คุณต้องการเกี่ยวกับการพัฒนาใหม่' คำตอบนี้บอกว่า "WOAH! คุณไม่ควรทำอย่างนั้น!" อาจไม่ใช่คำตอบของ OP หรือคุณต้องการได้ยิน แต่ตอบคำถามโดยสมบูรณ์

— Jonathan Eunice

1

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

— John Forkosh

1

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

— supercat

@supercat ถ้าสามารถทำได้ก็เป็นวิธีที่ดีอย่างแน่นอน แต่การนึกถึงโครงการฟื้นฟู y2k ของฉันหลายครั้งคุณต้อง "ดำดิ่งลงไป" ตรงกลางของโค้ดที่มีอยู่และยุ่งกับมัน ไม่มีความเป็นไปได้ (อีกครั้ง) ที่จะแยกออกเป็นแบบเก่า / ใหม่ที่เป็นไปได้ (ไม่มี >> ขนาดใหญ่ << rewrite) ตัวอย่างเช่นแทนที่จะเพิ่มสองไบต์ลงในฟิลด์วันที่สำหรับปีที่จัดรูปแบบ ccyy แบบสี่ไบต์ต้องการการอัปเดตฐานข้อมูลขนาดใหญ่เพียงตีความ yy> 50 เป็น 19yy และ yy <= 50 เป็น 20yy แต่การใช้งานอย่างชาญฉลาดเพียงอย่างเดียวสำหรับสิ่งนั้นเกี่ยวข้องกับการเปลี่ยนแปลงเล็กน้อยจำนวนมากทุกที่ที่ใช้ yy

— John Forkosh

13

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

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

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

— gnasher729
แหล่งที่มา

2

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

— CodeMonkey

7

ถ้ามันไม่พังไม่ได้แก้ไข

สิ่งนี้ควรจะเป็นรอยสักบนนักพัฒนาซอฟต์แวร์และผู้จัดการทุกคนเพื่อที่พวกเขาจะไม่ลืมมัน

ใช่มันแบ่งอนุสัญญาการเข้ารหัสที่ทันสมัยทั้งหมด ใช่มันเขียนใน FORTRAN-77 พร้อมด้วย wrapper ใน C จึงสามารถเรียกใช้งานได้จาก Python ใช่ GOTO เหล่านี้ไม่มีโครงสร้าง ใช่มีหนึ่งรูทีนย่อยสามพันบรรทัด ใช่ชื่อตัวแปรเหมาะสมกับ Croat เท่านั้น ฯลฯ

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

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

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

— nigel222
แหล่งที่มา

2

คุณหมายถึงWestern Digitalหรือเปล่า มันเป็นการเรียกคืนครั้งนี้หรือไม่ คุณสามารถให้แหล่งข้อมูลเพื่อสำรองเรื่องราวของคุณได้หรือไม่?

— การแข่งขัน Lightness กับโมนิก้า

3

ค่อนข้างแน่ใจว่าเขาหมายถึง Digital Equipment Corp ริบหรี่จาง ๆ ซึ่งอาจยังคงอยู่ลึกลงไปในหัวใจสีดำของ Hewlett Packard

— John Hascall

1

ใช่ - ดิจิตอลหรือที่รู้จักในชื่อ DEC

— nigel222

5

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

มันเป็นวิธีการที่เรียบง่ายเหมือนกันและตาย

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

— Basilevs
แหล่งที่มา

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

— John Forkosh

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

— Basilevs

3

การควบคุมความเสี่ยง….

รหัสใน codebase ขนาดใหญ่ได้รับการทดสอบอย่างน้อยโดยการใช้งานจริงของซอฟต์แวร์
มันไม่น่าเกลียดมากรหัสใน codebase ขนาดใหญ่ที่ครอบคลุมโดยการทดสอบหน่วยอัตโนมัติ
ดังนั้นการเปลี่ยนแปลงใด ๆ ที่เกิดจากความหนาวเย็นใน codebase ขนาดใหญ่แบบดั้งเดิมนั้นมีความเสี่ยงสูง

ค่าใช้จ่าย ...

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

ประโยชน์

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

คำแนะนำ ...

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

ประสบการณ์ส่วนตัว….

ในอีก 20 ปีของการทำงานเป็นโปรแกรมเมอร์ฉันไม่เคยเห็นกรณีที่เปลี่ยนเก่าไปอย่างสิ้นเชิงเพื่อลบเอาต์พุตทั้งหมดจากตัวตรวจสอบมาตรฐานการเข้ารหัสใหม่มีประโยชน์นอกเหนือจากการเพิ่มรายได้ของผู้รับเหมาที่ได้รับคำสั่งให้ทำเช่นนั้น
ในทำนองเดียวกันเมื่อรหัสเก่าจะต้องทำผ่านการตรวจสอบรหัส (TickIt / ISO 9001 ทำผิด) ที่ต้องใช้รหัสเก่าจะมีลักษณะเหมือนมาตรฐานการเข้ารหัสใหม่
ฉันได้เห็นหลายกรณีที่การใช้เครื่องมือตรวจสอบมาตรฐานการเข้ารหัสรหัสใหม่มีประโยชน์มากโดยการลดต้นทุนอย่างต่อเนื่อง
ฉันไม่เคยเห็น บริษัท ล้มเหลวในการรักษารหัสเก่าที่ใช้ในผลิตภัณฑ์ที่มีลูกค้าจำนวนมาก
ฉันเห็น บริษัท ล้มเหลวเนื่องจากไม่ได้รับรายได้จากลูกค้าด้วยการทำตลาดช้าเกินไป….

— เอียน
แหล่งที่มา

0

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

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

... นอกจากนั้นแค่พูดคุยกับคนที่เกี่ยวข้องและรับทราบเหตุผลของพวกเขาด้วย

— dagnelies
แหล่งที่มา

0

ฉันจะพยายามแยกรหัสดั้งเดิมออกจากรหัสใหม่ที่สะอาด ใน Eclipse เช่นคุณสามารถทำได้โดยใส่พวกเขาในโครงการที่แตกต่างกันซึ่งใช้กัน 'clean' โครงการและ' legacy' โครงการ

วิธีนี้คุณสามารถวิเคราะห์ทั้งสองโครงการในโซนาร์ด้วยมาตรฐานคุณภาพที่แตกต่างกัน มาตรฐานควรแตกต่างกันในความสำคัญของกฎ กฎของตัวเองควรจะเหมือนกัน วิธีนี้คุณสามารถเห็นใน 'legacy' โครงการสิ่งที่จะต้องมี 'ถาวร' เป็นไปตามมาตรฐานของ ' clean' โครงการ

เมื่อใดก็ตามที่คุณจัดการเพื่อยกรหัสดั้งเดิมให้สูงขึ้นคุณสามารถย้ายรหัสไปยังโครงการ 'clean'

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

— MrSmith42
แหล่งที่มา