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

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

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

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

2
วิธีการจัดระเบียบรหัสซ้ำ ๆ
ทีมของฉันสร้างเว็บฟอร์มได้หลายครั้ง แบบฟอร์มเหล่านี้ส่วนใหญ่เพียงส่งอีเมลและมีเพียงไม่กี่อย่างที่เขียนฐานข้อมูล ตอนนี้แต่ละรูปแบบอาศัยอยู่ในโซลูชันแยกต่างหากใน Visual Studio Team Foundation Server นั่นหมายความว่าเรามีโครงการที่แตกต่างกันเกือบ 100 โครงการซึ่งทำให้ยากต่อการรักษาความมั่นคง แต่ละรูปแบบมีลักษณะเฉพาะที่แตกต่างกันไป แต่ทุกคนก็ทำในสิ่งเดียวกัน ฉันกำลังมองหาที่จะรวมตัวเหล่านี้อย่างใดและฉันสามารถใช้คำแนะนำบางอย่าง ฉันควรพยายามสร้างไฟล์โซลูชันหนึ่งไฟล์โดยใช้โปรเจคฟอร์มทั้งหมดของเราหรือไม่ ไม่มีรหัสการประปาจำนวนมาก แต่ฉันสามารถสร้างผู้ช่วยสองสามชั้นเพื่อช่วยในการจัดรูปแบบอีเมลและอื่น ๆ มันจะมีประโยชน์มากในการแบ่งปัน CSS, JavaScript, การควบคุมและรูปภาพในโครงการต่างๆ เนื่องจากเราเป็นร้านค้าของ Microsoft จะมีประโยชน์ใด ๆ ที่จับต้องได้ในการไปกับ MVC ผ่าน Webforms สำหรับสถานการณ์เฉพาะนี้หรือไม่ ฉันขายให้กับแนวคิดของ MVC โดยรวม แต่มันจะช่วยให้ฉันรวบรวมแบบฟอร์มการเก็บข้อมูล 15 เขตข้อมูลได้อย่างมีประสิทธิภาพมากขึ้นหรือไม่ถ้าแบบฟอร์มทั้งหมดนั้นส่งอีเมลหรือไม่ รูปแบบที่ทำให้ฉันคิดว่าเรื่องนี้มีตรรกะที่ดีเล็กน้อยเพื่อแสดงและซ่อนฟิลด์ตามการตอบสนองของผู้ใช้และดูเหมือนว่ามันจะมีประสิทธิภาพน้อยกว่าในการใช้ MVC และ jQuery

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

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

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

4
แทนที่เงื่อนไขด้วยความหลากหลายในวิธีที่เหมาะสม?
พิจารณาสองคลาสDogและCatทั้งสองสอดคล้องกับAnimalโปรโตคอล (ในแง่ของภาษาการเขียนโปรแกรม Swift นั่นคืออินเทอร์เฟซใน Java / C #) เรามีหน้าจอที่แสดงรายการสุนัขและแมวที่หลากหลาย มีInteractorคลาสที่จัดการตรรกะเบื้องหลัง ตอนนี้เราต้องการที่จะนำเสนอการแจ้งเตือนการยืนยันให้กับผู้ใช้เมื่อเขาต้องการที่จะลบแมว อย่างไรก็ตามสุนัขจะต้องถูกลบทันทีโดยไม่มีการแจ้งเตือนใด ๆ วิธีที่มีเงื่อนไขจะมีลักษณะเช่นนี้: func tryToDeleteModel(model: Animal) { if let model = model as? Cat { tellSceneToShowConfirmationAlert() } else if let model = model as? Dog { deleteModel(model: model) } } รหัสนี้จะถูก refactored ได้อย่างไร? เห็นได้ชัดว่ามันมีกลิ่น

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

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

5
การใช้รูปแบบที่แตกต่างกันสำหรับคุณสมบัติที่คล้ายกัน
ฉันเป็นผู้พัฒนาเพียงผู้เดียวในโครงการที่อาจมีคนอื่นนำไปใช้ในโครงการต่อไปในอนาคต สมมติว่าฉันใช้รูปแบบ X เพื่อใช้คุณสมบัติ A หลังจากพัฒนาและทำให้คุณลักษณะเสร็จสมบูรณ์ฉันรู้ว่าฉันสามารถใช้คุณสมบัติเดียวกันโดยใช้รูปแบบ Y ซึ่งฉันเพิ่งเรียนรู้มา แต่ฟีเจอร์ A ทำงานได้ดีและการเปลี่ยนจาก X เป็น Y นั้นใช้เวลานานและให้ประโยชน์เล็กน้อย จากนั้นก็ถึงเวลาที่จะใช้งานคุณสมบัติ B มันคล้ายกับ A แต่คราวนี้ฉันต้องการใช้โอกาสนี้เพื่อเล่นกับรูปแบบ Y ฉันมีความสุขกับผลลัพธ์สุดท้ายดีกว่าเมื่อใช้คุณสมบัติ A แต่ตอนนี้โค้ดของฉันใช้สอง รูปแบบที่ต่างกัน, X และ Y, สำหรับคุณสมบัติที่คล้ายกัน แต่ไม่มีเหตุผลที่แท้จริงที่จะใช้รูปแบบที่แตกต่างกันยกเว้นความจริงที่ว่าเมื่อการสร้างฟีเจอร์ AI นั้นไม่ชำนาญพอที่จะใช้รูปแบบเดียวกันกับฟีเจอร์ B โปรดทราบว่าคำถามนี้ไม่ได้เกี่ยวกับการเลือกรูปแบบที่เหมาะสมสำหรับปัญหาที่กำหนด ; มันมีอยู่สองรูปแบบที่อยู่ร่วมกันในฐานของรหัสเพื่อแก้ปัญหาที่คล้ายกันซึ่งสามารถลดลงเหลือเพียงครั้งเดียวเพื่อให้มีการปรับโครงสร้าง รหัสนั้นมีกลิ่นหรือไม่? อะไรคือข้อเสียของการรักษาซอร์สโค้ดเช่นนี้? ฉันควรจะใช้รูปแบบเดียวเท่านั้นหรือไม่ เช่น refactor A เพื่อใช้ Y หรือใช้ X ต่อไปเมื่อเขียน B? ฉันจะสื่อสารได้อย่างไรว่าสาเหตุที่มีสองรูปแบบที่แตกต่างกันสำหรับคุณสมบัติที่คล้ายกันนั้นไม่มีเหตุผล ฉันกังวลมากเกินไปเกี่ยวกับสิ่งที่นักพัฒนาคนต่อไปคิดเกี่ยวกับรหัสของฉันหรือไม่

4
ลดความซับซ้อนของคลาส
ฉันได้ดูคำตอบและค้นหาใน Google แล้ว แต่ฉันไม่พบสิ่งที่เป็นประโยชน์ (เช่นนั่นจะไม่มีผลข้างเคียงที่น่าอึดอัดใจ) ปัญหาของฉันในเชิงนามธรรมคือฉันมีวัตถุและจำเป็นต้องดำเนินการลำดับที่ยาวนานของมัน ฉันคิดว่ามันเป็นสายการประกอบเช่นการสร้างรถ ผมเชื่อว่าวัตถุเหล่านี้จะเรียกว่าวิธีวัตถุ ดังนั้นในตัวอย่างนี้ในบางครั้งฉันจะมี CarWithoutUpholstery ซึ่งฉันจะต้องเรียกใช้ installBackSeat, installFrontSeat, installWoodenInserts (การดำเนินการไม่รบกวนซึ่งกันและกันและอาจทำได้ในแบบคู่ขนาน) การดำเนินการเหล่านี้ดำเนินการโดย CarWithoutUpholstery.worker () และให้ผลลัพธ์เป็นวัตถุใหม่ซึ่งจะเป็น CarWithUpholstery ซึ่งฉันจะเรียกใช้ cleanInsides (), validNoUpholsteryDefects () และอื่น ๆ การดำเนินงานในเฟสเดียวนั้นมีความเป็นอิสระอยู่แล้วเช่นฉันกำลังต่อสู้กับส่วนย่อยของพวกเขาที่อาจดำเนินการในลำดับใด ๆ (ที่นั่งด้านหน้าและด้านหลังอาจติดตั้งในลำดับใดก็ได้) ตรรกะของฉันในปัจจุบันใช้ Reflection เพื่อความง่ายในการใช้งาน นั่นคือเมื่อฉันมี CarWithoutUpholstery วัตถุจะตรวจสอบตัวเองสำหรับวิธีที่เรียกว่า performSomething () ณ จุดนั้นมันรันวิธีการเหล่านี้ทั้งหมด: myObject.perform001SomeOperation(); myObject.perform002SomeOtherOperation(); ... ในขณะที่ตรวจสอบข้อผิดพลาดและสิ่งต่างๆ ในขณะที่คำสั่งของการดำเนินงานเป็นสำคัญผมได้รับมอบหมายเพื่อทำพจนานุกรมในกรณีที่ผมเคยค้นพบคำสั่งบางเป็นสิ่งสำคัญหลังจากทั้งหมด สิ่งนี้ขัดแย้งกับYAGNIแต่มีค่าใช้จ่ายน้อยมาก - การเรียงลำดับแบบง่าย ๆ () …

3
ฉันต้องประนีประนอม: DRY หรือ Command-Query-Separation
ฉันเพิ่ง refactoring วิธีที่ทั้งคำสั่งและวิธีการสืบค้น หลังจากแยกมันเป็นวิธีการหนึ่งคำสั่งและวิธีการค้นหาฉันพบว่าขณะนี้มีหลายสถานที่ในรหัสที่ฉันเรียกคำสั่งแล้วรับค่าจากแบบสอบถามซึ่งดูเหมือนว่าเป็นการละเมิดหลักการ DRY แต่ถ้าฉันจะตัดโค้ดทั่วไปลงในเมธอดเมธอดนั้นจะเป็นทั้งคำสั่งและคิวรี เป็นที่ยอมรับหรือไม่?

3
อะไรจะช่วยได้เมื่อทำการเปลี่ยนวิธีการขนาดใหญ่เพื่อให้แน่ใจว่าฉันจะไม่ทำลายอะไรเลย?
ขณะนี้ฉันกำลัง refactoring ส่วนหนึ่งของ codebase ขนาดใหญ่ที่ไม่มีหน่วยทดสอบใด ๆ ฉันพยายาม refactor code ในแบบที่โง่เง่านั่นคือการพยายามเดาว่าโค้ดกำลังทำอะไรและการเปลี่ยนแปลงใดที่จะไม่เปลี่ยนความหมาย แต่ไม่ประสบความสำเร็จ: มันสุ่มแยกคุณสมบัติรอบ ๆ codebase โปรดทราบว่าการเปลี่ยนโครงสร้างรวมถึงการย้ายรหัส C # ดั้งเดิมไปสู่รูปแบบการทำงานที่มากขึ้น (รหัสดั้งเดิมไม่ได้ใช้คุณสมบัติใด ๆ ของ. NET Framework 3 และใหม่กว่ารวมถึง LINQ) การเพิ่มข้อมูลทั่วไปที่รหัสอาจได้รับประโยชน์จากพวกเขาเป็นต้น ฉันไม่สามารถใช้วิธีการที่เป็นทางการได้เพราะจะมีค่าใช้จ่ายเท่าใด ในทางกลับกันฉันคิดว่าอย่างน้อย"กฎใด ๆ ที่ได้รับการปรับเปลี่ยนใหม่จะต้องมาพร้อมกับการทดสอบหน่วย"ควรปฏิบัติตามกฎอย่างเคร่งครัดไม่ว่าจะต้องเสียค่าใช้จ่ายเท่าใด ปัญหาคือเมื่อฉันสร้างส่วนเล็ก ๆ ของวิธีส่วนตัว 500 LOC การเพิ่มการทดสอบหน่วยดูเหมือนจะเป็นงานที่ยาก สิ่งใดที่สามารถช่วยฉันในการรู้ว่าการทดสอบหน่วยใดที่เกี่ยวข้องกับโค้ดบางส่วน ฉันเดาว่าการวิเคราะห์โค้ดแบบคงที่จะมีประโยชน์ แต่เครื่องมือและเทคนิคที่ฉันสามารถใช้เพื่อ: รู้ว่าฉันควรสร้างการทดสอบหน่วยใด และ / หรือทราบว่าการเปลี่ยนแปลงที่ฉันทำมีผลกับรหัสต้นฉบับในแบบที่มันทำงานแตกต่างจากนี้หรือไม่?

7
ตัวแปรชั่วคราวเทียบกับข้อกำหนดความยาวบรรทัด
ฉันได้อ่านRefactoringของ Martin Fowler แล้ว โดยทั่วไปถือว่ายอดเยี่ยม แต่คำแนะนำอย่างหนึ่งของ Fowler ดูเหมือนจะก่อให้เกิดปัญหาเล็กน้อย ฟาวเลอร์แนะนำให้คุณแทนที่ตัวแปรชั่วคราวด้วยเคียวรีดังนั้นแทนที่จะเป็น: double getPrice() { final int basePrice = _quantity * _itemPrice; final double discountFactor; if (basePrice > 1000) discountFactor = 0.95; else discountFactor = 0.98; return basePrice * discountFactor; } คุณดึงออกมาเป็นวิธีการช่วยเหลือ: double basePrice() { return _quantity * _itemPrice; } double getPrice() { …

5
วิธีทดสอบหน่วยฟังก์ชันที่ปรับโครงสร้างรูปแบบกลยุทธ์ใหม่แล้วหรือไม่
ถ้าฉันมีฟังก์ชั่นในรหัสของฉันที่จะไป: class Employee{ public string calculateTax(string name, int salary) { switch (name) { case "Chris": doSomething($salary); case "David": doSomethingDifferent($salary); case "Scott": doOtherThing($salary); } } โดยปกติฉันจะ refactor นี้เพื่อใช้ Ploymorphism โดยใช้คลาสโรงงานและรูปแบบกลยุทธ์: public string calculateTax(string name) { InameHandler nameHandler = NameHandlerFactory::getHandler(name); nameHandler->calculateTax($salary); } ตอนนี้ถ้าฉันใช้ TDD ฉันก็จะมีการทดสอบบางอย่างที่ทำงานกับต้นฉบับcalculateTax()ก่อนที่จะทำการรีแฟคเตอร์ อดีต: calculateTax_givenChrisSalaryBelowThreshold_Expect111(){} calculateTax_givenChrisSalaryAboveThreshold_Expect111(){} calculateTax_givenDavidSalaryBelowThreshold_Expect222(){} calculateTax_givenDavidSalaryAboveThreshold_Expect222(){} calculateTax_givenScottSalaryBelowThreshold_Expect333(){} calculateTax_givenScottSalaryAboveThreshold_Expect333(){} …

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