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

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

57 refactoring  teamwork 

ฉันได้อ่านคำตอบของคำถามในบรรทัดที่คล้ายกันเช่น "คุณจะให้การทดสอบหน่วยของคุณทำงานอย่างไรเมื่อทำการรีแฟคเตอร์?" ในกรณีของฉันสถานการณ์แตกต่างกันเล็กน้อยซึ่งฉันได้รับโครงการเพื่อตรวจสอบและนำไปสู่มาตรฐานที่เรามีอยู่ในขณะนี้ไม่มีการทดสอบใด ๆ สำหรับโครงการ! ฉันได้ระบุหลายสิ่งที่ฉันคิดว่าทำได้ดีกว่าเช่นไม่ผสมรหัสประเภท DAO ในเลเยอร์บริการ ก่อนที่จะทำการเปลี่ยนรูปใหม่ดูเหมือนว่าเป็นความคิดที่ดีที่จะเขียนการทดสอบสำหรับโค้ดที่มีอยู่ ปัญหาที่ฉันเห็นก็คือเมื่อฉันทำ refactor แล้วการทดสอบเหล่านั้นจะแตกในขณะที่ฉันกำลังเปลี่ยนแปลงที่ตรรกะบางอย่างจะทำและการทดสอบจะถูกเขียนด้วยโครงสร้างก่อนหน้าในใจ (ล้อเลียนอ้างอิง ฯลฯ ) ในกรณีของฉันสิ่งที่จะเป็นวิธีที่ดีที่สุดในการดำเนินการ? ฉันถูกล่อลวงให้เขียนการทดสอบเกี่ยวกับรหัส refactored แต่ฉันรู้ว่ามีความเสี่ยงที่ฉันอาจ refactor สิ่งที่ไม่ถูกต้องที่อาจเปลี่ยนพฤติกรรมที่ต้องการ ไม่ว่าจะเป็น refactor หรือการออกแบบใหม่ฉันมีความสุขที่จะเข้าใจคำศัพท์เหล่านั้นที่จะได้รับการแก้ไขในขณะนี้ฉันกำลังทำงานกับคำจำกัดความต่อไปนี้สำหรับการ refactoring "ด้วยการ refactoring ตามนิยามคุณจะไม่เปลี่ยนแปลงสิ่งที่ซอฟต์แวร์ของคุณทำ คุณเปลี่ยนวิธีการใช้งาน ". ดังนั้นฉันจะไม่เปลี่ยนแปลงสิ่งที่ซอฟต์แวร์ทำฉันจะเปลี่ยนวิธี / มันทำ เท่าเทียมกันฉันสามารถดูอาร์กิวเมนต์ว่าถ้าฉันเปลี่ยนลายเซ็นของวิธีการที่อาจถือเป็นการออกแบบใหม่ นี่เป็นตัวอย่างสั้น ๆ MyDocumentService.java (ปัจจุบัน) public class MyDocumentService { ... public List<Document> findAllDocuments() { DataResultSet rs = …

55 unit-testing  refactoring 

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

55 refactoring  code-reviews 

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

52 refactoring  code-reviews  clean-code  code-smell 

ฉันมีโครงการแล้ว ในโครงการนี้ฉันต้องการ refactor เพื่อเพิ่มคุณสมบัติและฉัน refactored โครงการเพื่อเพิ่มคุณสมบัติ ปัญหาคือเมื่อฉันเสร็จแล้วมันกลับกลายเป็นว่าฉันต้องการที่จะทำการเปลี่ยนแปลงอินเตอร์เฟซเล็กน้อยเพื่อรองรับมัน ดังนั้นฉันจึงทำการเปลี่ยนแปลง จากนั้นคลาสการบริโภคไม่สามารถนำไปใช้กับอินเทอร์เฟซปัจจุบันในแง่ของอินเทอร์เฟซใหม่ดังนั้นมันจึงต้องการอินเทอร์เฟซใหม่เช่นกัน ตอนนี้สามเดือนต่อมาและฉันต้องแก้ไขปัญหาที่ไม่เกี่ยวข้องอย่างมากมายนับไม่ถ้วนและฉันกำลังมองหาการแก้ปัญหาที่ถูกทำแผนที่สำหรับหนึ่งปีต่อจากนี้ อีกครั้ง ฉันจะหลีกเลี่ยงการปรับลดประเภทของการเรียงซ้อนในอนาคตได้อย่างไร มันเป็นแค่อาการของชั้นเรียนก่อนหน้าของฉันซึ่งขึ้นอยู่กับแต่ละคนแน่นเกินไปหรือไม่? การแก้ไขสั้น ๆ : ในกรณีนี้ refactor เป็นคุณลักษณะเนื่องจาก refactor เพิ่มความสามารถในการขยายของโค้ดบางส่วนและลดการเชื่อมต่อบางส่วน นั่นหมายความว่าผู้พัฒนาภายนอกสามารถทำอะไรได้มากกว่าซึ่งเป็นคุณลักษณะที่ฉันต้องการนำเสนอ ดังนั้นตัวปรับเปลี่ยนดั้งเดิมเองไม่ควรเปลี่ยนฟังก์ชัน แก้ไขที่ใหญ่กว่าที่ฉันสัญญาห้าวันที่ผ่านมา: ก่อนที่ฉันจะเริ่ม refactor นี้ฉันมีระบบที่ฉันมีอินเทอร์เฟซ แต่ในการนำไปใช้นั้นฉันเพิ่งdynamic_castผ่านการใช้งานที่เป็นไปได้ทั้งหมดที่ฉันจัดส่ง เห็นได้ชัดว่านั่นหมายความว่าคุณไม่สามารถสืบทอดจากอินเทอร์เฟซสำหรับสิ่งใดสิ่งหนึ่งและอย่างที่สองว่ามันจะเป็นไปไม่ได้สำหรับทุกคนที่ไม่มีการเข้าถึงเพื่อใช้งานอินเทอร์เฟซนี้ ดังนั้นฉันตัดสินใจว่าฉันต้องการแก้ไขปัญหานี้และเปิดอินเทอร์เฟซสำหรับการบริโภคสาธารณะเพื่อให้ทุกคนสามารถใช้งานได้และการใช้อินเทอร์เฟซนั้นเป็นสัญญาทั้งหมดที่จำเป็นต้องมี - การปรับปรุงอย่างชัดเจน เมื่อฉันค้นหาและฆ่าด้วยไฟในทุกสถานที่ที่ฉันได้ทำสิ่งนี้ฉันพบที่เดียวที่พิสูจน์แล้วว่าเป็นปัญหาเฉพาะ มันขึ้นอยู่กับรายละเอียดการใช้งานของคลาสที่ได้รับมาทั้งหมดและฟังก์ชั่นการทำซ้ำที่มีการใช้งานแล้ว แต่ดีกว่าที่อื่น มันอาจถูกนำมาใช้ในแง่ของอินเทอร์เฟซสาธารณะแทนและนำมาใช้ใหม่การใช้งานที่มีอยู่ของฟังก์ชั่นนั้น ฉันค้นพบว่ามันจำเป็นต้องใช้บริบทบางอย่างในการทำงานอย่างถูกต้อง พูดโดยประมาณการเรียกใช้งานก่อนหน้านี้ดูเหมือนจะเป็นไปได้ for(auto&& a : as) { f(a); } อย่างไรก็ตามเพื่อให้ได้บริบทนี้ฉันต้องเปลี่ยนมันเป็นอะไรที่มากกว่า std::vector<Context> contexts; for(auto&& a …

52 design  programming-practices  refactoring  coupling 

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

52 refactoring  clean-code  functions  parameters  order 

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

52 refactoring  communication  technical-debt 

เมื่อนานมาแล้วเราได้เพิ่มคุณสมบัติที่ผู้ใช้ของเราสามารถ "ยอมรับ" ภาพหลังจากที่เพิ่มเข้าไปในคิวเวิร์กโฟลว์ ปรากฎว่าเราใช้คำผิดและผู้ใช้ "อนุมัติ" รูปภาพ การเปลี่ยนยอมรับเป็นอนุมัติบนอินเทอร์เฟซของเรานั้นง่ายดายเพียงแค่เปลี่ยนคำเดียว แต่เราตั้งโปรแกรมเลเยอร์ทั้งหมดด้วยคำว่า "accept" จากชื่อคลาส CSS ไปจนถึงค่าฐานข้อมูล คลาส CSS ที่เปลี่ยนเป็นปุ่มสีเขียว: ".accepted"; เมธอดโมเดลที่ตรวจสอบและผูกแอ็ตทริบิวต์คลาสบนโหนด DOM: "isAccepted"; แอตทริบิวต์สถานะ JavaScript: อาร์เรย์ที่มี "unreviewed", "ยอมรับ" และ "เผยแพร่"; คอลัมน์สถานะ Mysql: ENUM ที่มี "ไม่ได้ตรวจสอบ", "ยอมรับ" และ "เผยแพร่"; ชื่อทดสอบ เป็นเรื่องเล็กน้อย (โดยเฉพาะเมื่อคุณมีการทดสอบ) เพื่อแทนที่การยอมรับส่วนใหญ่ที่จะอนุมัติ ยากกว่าเล็กน้อยคือการโยกย้ายข้อมูลโดยเฉพาะอย่างยิ่งเนื่องจากต้องมีการซิงโครไนซ์กับการปรับใช้ คดีเฉพาะเรื่องนี้เรียบง่าย แต่ฉันเคยเจอคดีที่คล้ายกัน แต่มีความซับซ้อนมากกว่าในระหว่างการทำงาน เมื่อไฟล์ถูกเปลี่ยนชื่อและการปรับใช้เกิดขึ้นในเซิร์ฟเวอร์หลายสิบเครื่องหรือเมื่อแคชพร็อกซี memcached และ mysql เกี่ยวข้อง การปล่อย "ยอมรับ" ในทุก …

50 refactoring  domain-driven-design 

ฉันทำงานกับรหัสฐานที่มีโค้ดมากกว่า 500K บรรทัด มันเป็นความต้องการที่จริงจังในการ refactoring มีการพยายามปรับโครงสร้างใหม่ที่ระบุว่าจะใช้เวลานานกว่าการวิ่งสองสัปดาห์ปกติ สิ่งเหล่านี้ไม่สามารถแยกย่อยเป็นงานเล็ก ๆ อย่างที่ฉันเห็นในคำตอบอื่น ๆ ในเว็บไซต์นี้ ผลิตภัณฑ์จำเป็นต้องทำงานในตอนท้ายของการทำซ้ำและการรีแฟคเตอร์บางส่วนจะทำให้ระบบอยู่ในสถานะใช้งานไม่ได้เนื่องจากการพึ่งพาระหว่างไอเท็มนั้นแย่มาก ดังนั้นวิธีที่ดีที่สุดในการเข้าถึงอุปสรรค์นี้คืออะไร? อีกครั้งฉันพูดถึงการแบ่งมันเป็นชิ้นเล็ก ๆ ไม่ใช่ตัวเลือกที่ได้ทำไปแล้ว อัปเดต: ผู้คนดูเหมือนจะต้องการคำอธิบายว่าทำไมสิ่งนี้ถึงไม่เหมาะกับการวิ่ง 2 สัปดาห์ มีส่วนร่วมในการวิ่งมากกว่าแค่การเขียนโค้ด เรามีนโยบายที่ไม่มีรหัสหากไม่มีการทดสอบ นโยบายนั้นไม่ได้มีอยู่เสมอและส่วนใหญ่ของ codebase ไม่มีอยู่ นอกจากนี้การทดสอบการรวมบางส่วนของเรายังเป็นการทดสอบด้วยตนเอง ปัญหาไม่ได้อยู่ที่การปรับโครงสร้างใหม่นั้นใหญ่มาก มันเป็นความจริงที่ว่าการเปลี่ยนแปลงเล็กน้อยมีผลกระทบกับหลาย ๆ ส่วนของระบบและเราต้องมั่นใจว่าชิ้นส่วนเหล่านั้นยังคงทำงานได้อย่างถูกต้อง เราไม่สามารถชะลอหรือขยาย sprint ได้เนื่องจากเรามีโปรแกรมแก้ไขด่วนรายเดือน ดังนั้นการเปลี่ยนแปลงนี้ขยายผ่าน sprint ไม่สามารถหยุดงานอื่น ๆ ที่ถูกเพิ่มลงในโปรแกรมแก้ไขด่วน Refactoring vs Redesign: เพียงเพราะกระบวนการพัฒนาของเราไม่ได้มีประสิทธิภาพเพียงพอที่จะจัดการ refactoring นี้ในรอบสองสัปดาห์ไม่รับประกันว่าจะเปลี่ยนชื่อเป็นการออกแบบใหม่ ฉันอยากจะเชื่อว่าในอนาคตเราสามารถทำงานเดียวกันให้สำเร็จภายในสองสัปดาห์เมื่อกระบวนการของเราดีขึ้น รหัสที่เป็นปัญหาที่นี่ไม่ต้องเปลี่ยนในเวลานานมากและค่อนข้างมีเสถียรภาพ ตอนนี้เมื่อทิศทางของ บริษัท ปรับเปลี่ยนได้มากขึ้นเราต้องการให้ส่วนฐานของโค้ดนี้สามารถปรับเปลี่ยนได้เหมือนกับส่วนที่เหลือ ซึ่งต้องมีการปรับสภาพใหม่ …

49 refactoring  sprint 

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

48 refactoring  gui 

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

46 refactoring  development-methodologies  technical-debt 

ฉันต้องขยายโมดูลที่มีอยู่ของโครงการ ฉันไม่ชอบวิธีที่เคยทำ (มีรูปแบบการต่อต้านจำนวนมากที่เกี่ยวข้องเช่นคัดลอก / วางโค้ด) ฉันไม่ต้องการดำเนินการ refactor แบบสมบูรณ์ด้วยเหตุผลหลายประการ ฉันควร: สร้างวิธีการใหม่โดยใช้การประชุมที่มีอยู่แม้ว่าฉันจะรู้สึกผิดเพื่อหลีกเลี่ยงความสับสนสำหรับผู้ดูแลต่อไปและสอดคล้องกับรหัสฐานหรือไม่ หรือ ลองใช้สิ่งที่ฉันรู้สึกดีขึ้นแม้ว่าจะมีการแนะนำรูปแบบอื่นในรหัสหรือไม่ Precison แก้ไขหลังจากคำตอบแรก: รหัสที่มีอยู่ไม่เป็นระเบียบ มันง่ายที่จะติดตามและทำความเข้าใจ แต่มันก็แนะนำรหัสสำเร็จรูปจำนวนมากที่สามารถหลีกเลี่ยงได้ด้วยการออกแบบที่ดี (รหัสผลลัพธ์อาจกลายเป็นเรื่องยากที่จะปฏิบัติตามแล้ว) ในกรณีปัจจุบันของฉันมันเป็นโมดูล DAO เก่าแก่ของ JDBC (บอร์ดเทมเพลตสปริง) แต่ฉันได้พบปัญหานี้แล้วและฉันกำลังมองหาความคิดเห็น dev อื่น ๆ ฉันไม่ต้องการ refactor เพราะฉันไม่มีเวลา และถึงเวลาจะยากที่จะพิสูจน์ว่าโมดูลที่ทำงานได้อย่างสมบูรณ์แบบนั้นต้องการการปรับโครงสร้างใหม่ ต้นทุนการปรับโครงสร้างจะหนักกว่าประโยชน์ของมัน จำเอาไว้: รหัสไม่ยุ่งหรือซับซ้อนเกิน ฉันไม่สามารถแยกวิธีการไม่กี่ที่นั่นและแนะนำคลาสนามธรรมที่นี่ มันเป็นข้อบกพร่องในการออกแบบมากขึ้น (เพราะ 'Keep It Stupid Simple' สุดขีดฉันคิดว่า) ดังนั้นคำถามที่สามารถถามได้เช่น: คุณในฐานะนักพัฒนาคุณต้องการที่จะรักษาโค้ดที่น่าเบื่องี่เง่าที่ง่ายหรือจะมีผู้ช่วยบางคนที่จะทำโค้ดที่น่าเบื่อแบบโง่ในที่ของคุณหรือไม่? ข้อเสียของความเป็นไปได้ครั้งสุดท้ายที่คุณจะต้องเรียนรู้บางสิ่งและบางทีคุณอาจจะต้องรักษารหัสที่น่าเบื่ออย่างง่าย ๆ ไว้เช่นกันจนกว่าจะทำการรีแฟคเตอร์เสร็จสมบูรณ์)

45 refactoring  coding  maintenance  anti-patterns 

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

42 project-management  programming-practices  refactoring  maintenance 

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

41 git  refactoring  code-quality 

ทุกคนรู้ว่านักพัฒนาใหม่เขียนฟังก์ชันที่ยาวนาน ในขณะที่คุณก้าวหน้าคุณจะดีขึ้นเมื่อแบ่งรหัสของคุณออกเป็นชิ้นเล็ก ๆ และประสบการณ์สอนคุณค่าของการทำเช่นนั้น ป้อน SQL ใช่วิธีคิด SQL เกี่ยวกับโค้ดนั้นแตกต่างจากวิธีคิดขั้นตอนเกี่ยวกับโค้ด แต่หลักการนี้ดูเหมือนว่าใช้ได้ สมมติว่าฉันมีแบบสอบถามที่ใช้แบบฟอร์ม: select * from subQuery1 inner join subQuerry2 left join subquerry3 left join join subQuery4 ใช้ ID หรือวันที่เป็นต้น คิวรีย่อยเหล่านั้นซับซ้อนและอาจมีคิวรีย่อยของตนเอง ในบริบทการเขียนโปรแกรมอื่น ๆ ฉันจะคิดว่าตรรกะสำหรับเคียวรีย่อยที่ซับซ้อน 1-4 อยู่ในแนวเดียวกันกับแบบสอบถามหลักของฉันที่รวมพวกเขาทั้งหมด ดูเหมือนตรงไปตรงมาว่าเคียวรีย่อยเหล่านั้นควรถูกกำหนดเป็นมุมมองเหมือนพวกมันจะเป็นฟังก์ชันถ้าฉันกำลังเขียนโค้ดโพรซีเดอร์ เหตุใดจึงไม่ปฏิบัติกันทั่วไป ทำไมผู้คนจึงเขียนแบบสอบถาม SQL แบบเสาหินยาวเหล่านี้บ่อยๆ เหตุใด SQL จึงไม่สนับสนุนการใช้มุมมองที่กว้างขวางเช่นเดียวกับการเขียนโปรแกรมตามขั้นตอนสนับสนุนการใช้ฟังก์ชันที่กว้างขวาง (ในสภาพแวดล้อมแบบองค์กรจำนวนมากการสร้างมุมมองไม่ใช่สิ่งที่ทำได้ง่ายมีคำขอและการอนุมัติที่จำเป็นลองนึกภาพหากโปรแกรมเมอร์ประเภทอื่นต้องส่งคำขอทุกครั้งที่สร้างฟังก์ชัน!) ฉันคิดถึงคำตอบที่เป็นไปได้สามข้อ: นี่เป็นเรื่องปกติอยู่แล้วและฉันกำลังทำงานกับคนที่ไม่มีประสบการณ์ โปรแกรมเมอร์ที่มีประสบการณ์ไม่ได้เขียน SQL ที่ซับซ้อนเพราะพวกเขาต้องการที่จะแก้ปัญหาการประมวลผลข้อมูลอย่างหนักด้วยรหัสขั้นตอน อื่น ๆ …

39 refactoring  sql  enterprise-development