คำถามติดแท็ก refactoring

คำเตือน: ฉันเป็นผู้มาใหม่ (นี่เป็นวันที่สามของการทำงาน) และเพื่อนร่วมทีมส่วนใหญ่ของฉันมีประสบการณ์มากกว่าฉัน เมื่อฉันดูรหัสของฉันฉันเห็นกลิ่นของรหัสและวิธีปฏิบัติทางวิศวกรรมที่ไม่ดีเช่นดังต่อไปนี้: หลักเกณฑ์การตั้งชื่อค่อนข้างไม่สอดคล้องกัน คุณสมบัติไม่ถูกทำเครื่องหมายว่าอ่านได้อย่างเดียวเมื่อเป็นไปได้ คลาสขนาดใหญ่ - ฉันสังเกตเห็นคลาสยูทิลิตี้ที่ประกอบด้วยวิธีการขยายหลายร้อยรายการ (สำหรับหลายประเภท) มันยาวกว่า 2,500 บรรทัด! วิธีการขนาดใหญ่ - ฉันกำลังพยายามปรับวิธีการที่มีความยาว 150 บรรทัด สองหลังดูเหมือนจะเป็นปัญหาจริง ฉันต้องการโน้มน้าวให้เพื่อนร่วมทีมใช้คลาสและวิธีการที่เล็กลง แต่ฉันควรทำอย่างนั้น? ถ้าใช่แล้วได้อย่างไร ทีมของฉันได้รับที่ปรึกษาจากทีมหลัก (เราเป็นทีมดาวเทียม) ฉันควรไปหาเขาก่อนไหม UPDATE : เนื่องจากคำตอบบางอย่างถามเกี่ยวกับโครงการโปรดทราบว่าเป็นโครงการที่ทำงานได้ และ IMHO คลาส / วิธีการขนาดใหญ่นั้นไม่ดีเสมอไป ยังไงก็ตามฉันไม่ต้องการที่จะฉี่ทีมของฉันออก นั่นเป็นเหตุผลที่ฉันถาม - ฉันควรทำอย่างนั้นหรือไม่และถ้าใช่แล้วฉันจะทำอย่างนั้นเบา ๆ ? UPDATE : ฉันตัดสินใจที่จะทำบางสิ่งตามคำตอบที่ยอมรับ: เพราะฉันเป็นผู้มาใหม่ดังนั้นฉันจึงเห็นทุกอย่างใน "ตาสด" ฉันจะจดบันทึกทุกรหัสกลิ่นที่ฉันพบ (ตำแหน่งทำไมมันแย่เราจะทำอย่างไร ดีกว่า ... ) …

27 .net  code-quality  team  refactoring 

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

26 object-oriented  functional-programming  refactoring 

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

25 refactoring 

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

25 refactoring  unit-testing 

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

24 version-control  refactoring  branching 

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

23 scrum  refactoring 

ไม่แน่ใจว่าจะไปเกี่ยวกับวิธีการนี้เพื่อลดความซับซ้อนของวัฏจักร โซนาร์รายงาน 13 ขณะที่ 10 คาดว่าจะเป็น ฉันแน่ใจว่าไม่มีอะไรเป็นอันตรายต่อการออกจากวิธีการนี้เหมือนเดิมอย่างไรก็ตามเพียงแค่ท้าทายฉันว่าจะทำตามกฎของ Sonar อย่างไร ความคิดใด ๆ ที่จะได้รับการชื่นชมอย่างมาก public static long parseTimeValue(String sValue) { if (sValue == null) { return 0; } try { long millis; if (sValue.endsWith("S")) { millis = new ExtractSecond(sValue).invoke(); } else if (sValue.endsWith("ms")) { millis = new ExtractMillisecond(sValue).invoke(); } else if (sValue.endsWith("s")) …

23 java  code-quality  refactoring  coding-standards  cyclomatic-complexity 

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

23 git  refactoring 

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

23 programming-practices  refactoring 

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

22 self-improvement  time-management  refactoring 

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

22 git  refactoring  branching  gitflow 

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

21 project-management  refactoring  maintenance 

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

21 unit-testing  team  refactoring  bad-code  integration-tests 

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

21 design  refactoring  terminology 

ฉันได้รับมอบหมายให้รับแอปพลิเคชันรุ่นเก่าภายใต้การทดสอบหน่วย เริ่มจากพื้นฐานเกี่ยวกับแอปพลิเคชั่น: เป็นฐานรหัส LOC Java RCP 600k ที่มีปัญหาสำคัญเหล่านี้ การทำสำเนารหัสจำนวนมาก ไม่มีการห่อหุ้มข้อมูลส่วนตัวส่วนใหญ่สามารถเข้าถึงได้จากภายนอกข้อมูลทางธุรกิจบางส่วนยังสร้างซิงเกิลตันดังนั้นจึงไม่เพียง แต่เปลี่ยนแปลงจากภายนอก แต่ยังมาจากทุกที่ ไม่มี abstractions (เช่นไม่มีโมเดลธุรกิจข้อมูลธุรกิจถูกเก็บไว้ใน Object [] และ double [] []) ดังนั้นจึงไม่มี OO มีชุดทดสอบการถดถอยที่ดีและทีมงาน QA ที่มีประสิทธิภาพคือการทดสอบและค้นหาข้อบกพร่อง ฉันรู้เทคนิคในการทดสอบจากหนังสือคลาสสิกเช่น Michael Feathers แต่มันช้าเกินไป เนื่องจากมีระบบทดสอบการถดถอยที่ใช้งานได้ฉันจึงไม่กลัวที่จะทำการปรับโครงสร้างระบบใหม่อย่างจริงจังเพื่อให้สามารถเขียนการทดสอบหน่วยได้ ฉันจะเริ่มโจมตีปัญหาเพื่อให้ได้ความครอบคลุมได้อย่างรวดเร็วดังนั้นฉันจึงสามารถแสดงความคืบหน้าต่อการจัดการ (และอันที่จริงแล้วเริ่มมีรายได้จากความปลอดภัยของการทดสอบ JUnit) ฉันไม่ต้องการใช้เครื่องมือในการสร้างชุดทดสอบการถดถอยเช่น AgitarOne เพราะการทดสอบเหล่านี้ไม่ได้ทดสอบว่ามีบางอย่างถูกต้องหรือไม่

21 object-oriented  refactoring  test-coverage  junit