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

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

16
เจ้านายของฉันขอให้ฉันหยุดเขียนฟังก์ชั่นเล็ก ๆ และทำทุกอย่างในลูปเดียวกัน
ฉันอ่านหนังสือชื่อClean Codeของ Robert C. Martin แล้ว ในหนังสือเล่มนี้ฉันได้เห็นวิธีการมากมายในการทำความสะอาดโค้ดเช่นการเขียนฟังก์ชั่นเล็ก ๆ การเลือกชื่ออย่างระมัดระวัง ฯลฯ ดูเหมือนว่าหนังสือที่น่าสนใจที่สุดเกี่ยวกับรหัสที่ฉันอ่าน อย่างไรก็ตามวันนี้เจ้านายของฉันไม่ชอบวิธีที่ฉันเขียนโค้ดหลังจากอ่านหนังสือเล่มนี้ ข้อโต้แย้งของเขาคือ การเขียนฟังก์ชั่นเล็ก ๆ เป็นความเจ็บปวดเพราะมันบังคับให้คุณย้ายเข้าไปในฟังก์ชั่นเล็ก ๆ แต่ละอันเพื่อดูว่าโค้ดกำลังทำอะไรอยู่ ใส่ทุกอย่างไว้ในลูปหลักหลักแม้ว่าลูปหลักจะมีมากกว่า 300 บรรทัดมันจะอ่านเร็วขึ้น เขียนฟังก์ชั่นเล็ก ๆ เท่านั้นหากคุณต้องทำซ้ำรหัส อย่าเขียนฟังก์ชั่นที่มีชื่อของความคิดเห็นใส่รหัสบรรทัดที่ซับซ้อนของคุณ (3-4 บรรทัด) ด้วยความคิดเห็นด้านบน คุณสามารถแก้ไขโค้ดที่ล้มเหลวได้เช่นเดียวกัน สิ่งนี้ขัดต่อทุกสิ่งที่ฉันอ่าน ปกติคุณเขียนรหัสได้อย่างไร หนึ่งวงใหญ่หลักไม่มีฟังก์ชั่นเล็ก ๆ ? ภาษาที่ฉันใช้ส่วนใหญ่เป็นจาวาสคริปต์ ตอนนี้ฉันมีปัญหาในการอ่านเนื่องจากฉันได้ลบฟังก์ชั่นที่ตั้งชื่อไว้อย่างชัดเจนแล้วนำทุกอย่างมารวมกันเป็นวงใหญ่ อย่างไรก็ตามเจ้านายของฉันชอบวิธีนี้ ตัวอย่างหนึ่งคือ: // The way I would write it if (isApplicationInProduction(headers)) { phoneNumber = …

21
ส่วนใหญ่ของรหัสของฉันมีข้อบกพร่องในการออกแบบที่สำคัญ ปิดมันหรือแก้ไขมันตอนนี้เหรอ? [ปิด]
ฉันเป็นนักเรียนมัธยมปลายที่ทำงานในโครงการ C # กับเพื่อนของฉันเกี่ยวกับระดับทักษะเดียวกันกับฉัน จนถึงตอนนี้เราได้เขียนโค้ด 3,000 บรรทัดและโค้ดทดสอบ 250 บรรทัดในช่วง 100 คอมมิต เนื่องจากโรงเรียนฉันจึงเลื่อนโครงการไปสองสามเดือนและเมื่อเร็ว ๆ นี้ฉันสามารถเลือกได้อีกครั้ง เมื่อถึงเวลาหยิบขึ้นมาฉันเข้าใจว่ารหัสที่ฉันเขียนนั้นได้รับการออกแบบมาไม่ดีเช่นการรวมเธรดที่มากเกินไปในโหมดแสดงภาพการป้องกันสภาวะการแข่งขันที่ไม่ดีในการทำงานร่วมกันระหว่างซีพียู GPU และเกมตลับ เช่นเดียวกับรหัสที่ซ้ำซ้อนและสับสนเพียงอย่างเดียว ปัญหาคือฉันยังไม่เสร็จแม้ฟังก์ชั่นหลักของโปรแกรมของฉันดังนั้นฉันจึงไม่สามารถปรับโครงสร้างได้อย่างแท้จริงและฉันรู้สึกท้อแท้ที่จะรู้อย่างสมบูรณ์แบบว่าการออกแบบรหัสของฉันนั้นมีข้อบกพร่อง ในขณะเดียวกันฉันไม่ต้องการละทิ้งโครงการ มีความคืบหน้าเป็นจำนวนมากและงานต้องไม่ไปเสีย ฉันรู้สึกราวกับว่าฉันมีทางเลือกสองทาง: เพียงแค่ทำฟังก์ชั่นให้สมบูรณ์โดยการแก้ไขการออกแบบที่ไม่ดีและทำการปรับโครงสร้างใหม่เมื่อทุกอย่างทำงานหยุดทำงานทุกอย่างและทำงานเพื่อแก้ปัญหาทุกอย่างก่อนที่การทำงานจะเสร็จสิ้น ทั้งหมดนี้อยู่ในใจฉันใหม่อีกครั้งหรือทิ้งโครงการอย่างจริงจังเนื่องจากมีขนาดที่มากเกินไป จากประสบการณ์ของผู้อื่นในโครงการดังกล่าวการขอความช่วยเหลือในการกลับไปสู่เส้นทางที่ถูกต้องคืออะไร? จากคำตอบในเว็บไซต์นี้ฉันทามติทั่วไปคือการเขียนใหม่โดยไม่จำเป็นแต่เป็นตัวเลือกที่ใช้ได้หากไม่สามารถดูแลรักษารหัสได้โดยไม่ต้องเสียค่าใช้จ่ายมากเกินไป ฉันต้องการดำเนินโครงการนี้อย่างแท้จริง แต่อย่างที่มันเป็นรหัสของฉันไม่ได้ออกแบบมาอย่างดีพอสำหรับฉันที่จะดำเนินการต่อและความรู้สึกของความสิ้นหวังทำให้ฉันไม่สามารถดำเนินการต่อได้

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

13
ฉันควรปรับเปลี่ยนรหัสที่ทำเครื่องหมายว่า“ ไม่เปลี่ยนแปลง” หรือไม่
ฉันกำลังจัดการกับ codebase ที่ใหญ่มากและฉันได้รับสองสามเดือนเพื่อ refactor รหัสที่มีอยู่ กระบวนการ refactor นั้นเป็นสิ่งจำเป็นเพราะในไม่ช้าเราจะต้องเพิ่มคุณสมบัติใหม่ ๆ ให้กับผลิตภัณฑ์ของเราและในตอนนี้เราไม่สามารถเพิ่มคุณสมบัติใด ๆ ได้อีกต่อไปโดยไม่ทำลายสิ่งอื่นใด ในระยะสั้น: ยุ่งรหัสขนาดใหญ่ที่เราหลายคนเคยเห็นในอาชีพของพวกเขา ในระหว่างการเปลี่ยนโครงสร้างเป็นครั้งคราวฉันพบชั้นเรียนวิธีการหรือบรรทัดของรหัสที่มีความคิดเห็นเช่น หมดเวลาตั้งค่าให้โมดูล A เวลาในการทำสิ่งต่างๆ หากไม่ได้ตั้งเวลาเช่นนี้มันจะหยุด หรือ อย่าเปลี่ยนสิ่งนี้ เชื่อฉันสิคุณจะทำลายสิ่งต่างๆ หรือ ฉันรู้ว่าการใช้ setTimeout ไม่ใช่วิธีปฏิบัติที่ดี แต่ในกรณีนี้ฉันต้องใช้ คำถามของฉันคือ: ฉันควร refactor รหัสเมื่อฉันพบคำเตือนดังกล่าวจากผู้เขียน (ไม่ฉันไม่สามารถติดต่อกับผู้เขียน)?

5
ประเด็นสำคัญของการทำงานอย่างมีประสิทธิภาพด้วยรหัสมรดกคืออะไร [ปิด]
ฉันเคยเห็นหนังสือทำงานอย่างมีประสิทธิภาพด้วยรหัสมรดกแนะนำสองสามครั้ง ประเด็นสำคัญของหนังสือเล่มนี้คืออะไร? มีการจัดการกับรหัสดั้งเดิมมากกว่าการเพิ่มการทดสอบหน่วย / การรวมและการเปลี่ยนโครงสร้างอีกครั้งหรือไม่

16
ฉันควรลบรหัสที่ไม่อ้างอิงหรือไม่
ฉันกำลังทำงานกับฐานรหัสขนาดกลาง (100k บรรทัด) โค้ดทั้งหมดเป็นรหัสล่าสุด (น้อยกว่าหนึ่งปี) และมีการทดสอบหน่วยที่ครอบคลุม ฉันพบกับวิธีการที่ไม่ได้ใช้งานที่ใดอีกต่อไปหรืออ้างอิงในการทดสอบหน่วยซึ่งทดสอบเฉพาะวิธีนั้นเท่านั้น ฉันควรลบรหัสนี้หรือไม่ถ้าฉันแน่ใจว่าไม่จำเป็นอีกต่อไป เหตุผลในการลบ: รหัสน้อยกว่าข้อบกพร่องน้อยลง รหัสที่น้อยลงจะง่ายกว่าสำหรับผู้อื่นในการย่อย มันยังอยู่ภายใต้การควบคุมของแหล่งที่มา เหตุผลที่จะเก็บมันไว้: สามารถใช้เป็นข้อมูลอ้างอิง มันอาจจะมีประโยชน์ในบางครั้ง มันอาจถูกเขียนขึ้นเพื่อ 'ปัดเศษ' ฟังก์ชันการทำงานสำหรับชั้นเรียน

12
เหตุผลที่ต้องการตัวแปรท้องถิ่นมากกว่าตัวแปรอินสแตนซ์?
codebase ที่ฉันใช้บ่อยใช้ตัวแปรอินสแตนซ์เพื่อแชร์ข้อมูลระหว่างวิธีการต่าง ๆ นักพัฒนาดั้งเดิมยืนยันว่านี่เป็นไปตามแนวทางปฏิบัติที่ดีที่สุดที่ระบุไว้ในหนังสือClean Codeของลุงบ๊อบ / โรเบิร์ตมาร์ติน: "กฎข้อแรกของฟังก์ชั่นคือพวกเขาควรมีขนาดเล็ก" และ "จำนวนที่เหมาะสมของการขัดแย้งสำหรับฟังก์ชั่นคือศูนย์ (niladic) (... ) การโต้เถียงนั้นยากพวกเขาใช้พลังทางแนวคิดมากมาย" ตัวอย่าง: public class SomeBusinessProcess { @Inject private Router router; @Inject private ServiceClient serviceClient; @Inject private CryptoService cryptoService; private byte[] encodedData; private EncryptionInfo encryptionInfo; private EncryptedObject payloadOfResponse; private URI destinationURI; public EncryptedResponse process(EncryptedRequest encryptedRequest) { checkNotNull(encryptedRequest); getEncodedData(encryptedRequest); …
109 java  refactoring 

15
TDD Red-Green-Refactor และหาก / วิธีการทดสอบวิธีการที่เป็นส่วนตัว
เท่าที่ฉันเข้าใจคนส่วนใหญ่ดูเหมือนจะยอมรับว่าวิธีการส่วนตัวไม่ควรทดสอบโดยตรง แต่ผ่านวิธีการสาธารณะใด ๆ เรียกพวกเขา ฉันสามารถเห็นประเด็นของพวกเขา แต่ฉันมีปัญหาบางอย่างกับเรื่องนี้เมื่อฉันพยายามติดตาม "สามกฏของ TDD" และใช้วงจร "สีแดง - เขียว - refactor" ฉันคิดว่าตัวอย่างอธิบายได้ดีที่สุด: ตอนนี้ฉันต้องการโปรแกรมที่สามารถอ่านไฟล์ (ที่มีข้อมูลคั่นด้วยแท็บ) และกรองคอลัมน์ทั้งหมดที่มีข้อมูลที่ไม่ใช่ตัวเลข ฉันคิดว่าอาจมีเครื่องมือง่ายๆที่มีอยู่แล้วในการทำเช่นนี้ แต่ฉันตัดสินใจที่จะใช้มันตั้งแต่ต้นตัวเองเพราะฉันคิดว่ามันอาจเป็นโครงการที่ดีและสะอาดสำหรับฉันที่จะได้รับการฝึกฝนด้วย TDD ดังนั้นก่อนอื่นฉัน "ใส่หมวกสีแดง" นั่นคือฉันต้องการการทดสอบที่ล้มเหลว ฉันคิดว่าฉันจะต้องใช้วิธีการที่พบเขตข้อมูลที่ไม่ใช่ตัวเลขทั้งหมดในบรรทัด ดังนั้นฉันจึงเขียนการทดสอบอย่างง่ายแน่นอนว่ามันไม่สามารถรวบรวมได้ทันทีดังนั้นฉันจึงเริ่มเขียนฟังก์ชั่นของตัวเองและหลังจากผ่านไปมาสองรอบ (แดง / เขียว) ฉันมีฟังก์ชั่นการทำงานและการทดสอบที่สมบูรณ์ ถัดไปฉันใช้ฟังก์ชัน "gatherNonNumericColumns" ที่อ่านไฟล์ครั้งละหนึ่งบรรทัดและเรียก "findNonNumericFields" ของฉัน - ฟังก์ชันในแต่ละบรรทัดเพื่อรวบรวมคอลัมน์ทั้งหมดที่ต้องถูกลบออกในที่สุด สองรอบสีแดงสีเขียวและฉันเสร็จแล้วมีอีกครั้งฟังก์ชั่นการทำงานและการทดสอบที่สมบูรณ์ ตอนนี้ฉันคิดว่าฉันควร refactor เนื่องจากวิธีการของฉัน "findNonNumericFields" ได้รับการออกแบบเพราะฉันคิดว่าฉันจะต้องใช้เมื่อใช้งาน "gatherNonNumericColumns" ดูเหมือนว่าฉันจะมีเหตุผลที่จะให้ "findNonNumericFields" เป็นแบบส่วนตัว อย่างไรก็ตามนั่นจะเป็นการทำลายการทดสอบครั้งแรกของฉันเนื่องจากพวกเขาจะไม่สามารถเข้าถึงวิธีการทดสอบได้อีกต่อไป ดังนั้นฉันจบลงด้วยวิธีการส่วนตัวและชุดทดสอบที่ทดสอบ เนื่องจากผู้คนจำนวนมากให้คำแนะนำว่าไม่ควรทำการทดสอบวิธีส่วนตัวจึงรู้สึกเหมือนว่าฉันได้ทาสีตัวเองให้เป็นมุมตรงนี้ …

20
การแทนที่รหัสที่ได้รับการปรับปรุงด้วยรหัสที่อ่านได้นั้นเป็นเรื่องปกติหรือไม่
บางครั้งคุณพบสถานการณ์ที่คุณต้องขยาย / ปรับปรุงบางรหัสที่มีอยู่ คุณจะเห็นว่ารหัสเก่านั้นผอมมาก แต่มันก็ยากที่จะขยายและใช้เวลาในการอ่าน มันเป็นความคิดที่ดีที่จะแทนที่ด้วยรหัสที่ทันสมัย? ก่อนหน้านี้ฉันชอบวิธีการแบบลีน แต่ตอนนี้ฉันคิดว่ามันจะดีกว่าถ้าเสียสละจำนวนมากเพื่อเพิ่มประสิทธิภาพให้กับ abstractions ที่สูงขึ้นอินเตอร์เฟสที่ดีขึ้นและโค้ดที่อ่านได้และสามารถขยายได้มากขึ้น คอมไพเลอร์ดูเหมือนว่าจะเริ่มดีขึ้นเช่นกันดังนั้นสิ่งต่าง ๆ เช่นstruct abc = {}กลายเป็นเงียบ ๆmemset, shared_ptrs ค่อนข้างผลิตรหัสเดียวกันเป็นตัวชี้ดิบ twiddling, แม่แบบทำงานได้ดีสุดเพราะพวกเขาผลิตรหัสซุปเปอร์ลีนและอื่น ๆ แต่ถึงกระนั้นบางครั้งคุณก็เห็นอาร์เรย์ตามสแต็กและฟังก์ชั่น C เก่าที่มีตรรกะคลุมเครือและมักจะไม่ได้อยู่ในเส้นทางที่สำคัญ เป็นความคิดที่ดีที่จะเปลี่ยนรหัสดังกล่าวถ้าคุณต้องสัมผัสชิ้นส่วนเล็ก ๆ ด้วยวิธีใด?

11
เป็นการปฏิบัติที่ไม่ถูกต้องหรือไม่ที่จะแก้ไขโค้ดอย่างเคร่งครัดเพื่อการทดสอบ
ฉันมีการถกเถียงกับเพื่อนร่วมงานโปรแกรมเมอร์เกี่ยวกับว่ามันเป็นการปฏิบัติที่ดีหรือไม่ดีในการปรับเปลี่ยนรหัสการทำงานเพียงเพื่อให้สามารถทดสอบได้ (ผ่านการทดสอบหน่วยตัวอย่าง) ความคิดเห็นของฉันคือว่ามันใช้ได้ภายในขอบเขตของการบำรุงรักษาวัตถุที่ดีและการปฏิบัติด้านวิศวกรรมซอฟต์แวร์ที่แน่นอน (ไม่ใช่ "ทำให้ทุกอย่างเป็นสาธารณะ" ฯลฯ ) ความคิดเห็นของเพื่อนร่วมงานของฉันคือการแก้ไขรหัส (ใช้งานได้) เพื่อการทดสอบเท่านั้นผิด เป็นเพียงตัวอย่างง่ายๆลองนึกถึงโค้ดชิ้นนี้ที่ใช้โดยองค์ประกอบบางส่วน (เขียนใน C #): public void DoSomethingOnAllTypes() { var types = Assembly.GetExecutingAssembly().GetTypes(); foreach (var currentType in types) { // do something with this type (e.g: read it's attributes, process, etc). } } ฉันได้แนะนำว่ารหัสนี้สามารถแก้ไขเพื่อเรียกวิธีอื่นที่จะทำงานจริง: public void DoSomething(Assembly asm) { // not …

10
Java แต่ละบรรทัดมีจำนวนบรรทัดเท่าใด [ปิด]
จากประสบการณ์ของคุณกฎของหัวแม่มือที่มีประโยชน์สำหรับจำนวนบรรทัดของโค้ดมีมากเกินไปสำหรับคลาสหนึ่งใน Java เพื่อความชัดเจนฉันรู้ว่าจำนวนบรรทัดไม่ได้ใกล้เคียงกับมาตรฐานจริงเพื่อใช้สำหรับสิ่งที่ควรอยู่ในชั้นเรียนเฉพาะและสิ่งที่ไม่ควร คลาสควรได้รับการออกแบบให้สอดคล้องกับปรัชญา OOP (การห่อหุ้ม ฯลฯ ) ที่เหมาะสม ที่กล่าวว่ากฎง่ายๆสามารถให้เป็นจุดเริ่มต้นที่มีประโยชน์สำหรับการพิจารณาการรีแฟคเจอริ่ง (เช่น "อืมชั้นนี้มีบรรทัดของรหัส> n มันอาจไม่สามารถอ่านได้และทำงานของการห่อหุ้มด้วยหมัด ถูก refactored ในบางจุด ") ในทางกลับกันคุณอาจพบตัวอย่างของคลาสที่มีขนาดใหญ่มากที่ยังคงเชื่อฟังการออกแบบ OOP ได้ดีและอ่านได้และบำรุงรักษาได้แม้จะมีความยาวอยู่หรือไม่ นี่คือที่เกี่ยวข้องที่ไม่ซ้ำกันคำถามเกี่ยวกับเส้นต่อฟังก์ชั่น

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

10
มันสมเหตุสมผลหรือไม่ที่จะเขียนการทดสอบสำหรับรหัสดั้งเดิมเมื่อไม่มีเวลาสำหรับการปรับโครงสร้างที่สมบูรณ์?
ผมมักจะพยายามที่จะทำตามคำแนะนำของหนังสือเล่มนี้ทำงานอย่างมีประสิทธิภาพกับมรดกค้อจ ฉันทำลายการพึ่งพาย้ายส่วนต่าง ๆ ของรหัสไปยัง@VisibleForTesting public staticวิธีการและไปยังคลาสใหม่เพื่อให้รหัส (หรืออย่างน้อยก็บางส่วนของมัน) ทดสอบได้ และฉันเขียนการทดสอบเพื่อให้แน่ใจว่าฉันจะไม่ทำลายสิ่งใดเมื่อฉันแก้ไขหรือเพิ่มฟังก์ชั่นใหม่ เพื่อนร่วมงานคนหนึ่งบอกว่าฉันไม่ควรทำเช่นนี้ เหตุผลของเขา: รหัสต้นฉบับอาจทำงานไม่ถูกต้องตั้งแต่แรก และการเขียนการทดสอบทำให้การแก้ไขและการแก้ไขในอนาคตยากขึ้นเนื่องจาก devs ต้องเข้าใจและแก้ไขการทดสอบด้วย หากเป็นโค้ด GUI ที่มีตรรกะ (ตัวอย่างเช่น ~ 12 บรรทัด, 2-3 if / else บล็อก) การทดสอบจะไม่คุ้มกับปัญหาเนื่องจากรหัสนั้นเล็กน้อยเกินไปที่จะเริ่มต้น รูปแบบที่ไม่ดีที่คล้ายกันอาจมีอยู่ในส่วนอื่น ๆ ของ codebase เช่นกัน (ซึ่งฉันยังไม่ได้เห็นฉันค่อนข้างใหม่); มันจะง่ายกว่าในการทำความสะอาดพวกเขาทั้งหมดใน refactoring ใหญ่ การแยกตรรกะออกอาจทำให้ความเป็นไปได้ในอนาคตลดลง ฉันควรหลีกเลี่ยงการแยกส่วนที่สามารถทดสอบได้ออกมาและเขียนการทดสอบหรือไม่หากเราไม่มีเวลาสำหรับการเปลี่ยนโครงสร้างใหม่ให้สมบูรณ์? มีข้อเสียใด ๆ ที่ฉันควรพิจารณาหรือไม่?

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

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

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