เป็นเรื่องปกติหรือไม่ที่ฉันไม่สามารถเก็บหัวเกินสามข้อที่กำหนดไว้ให้ฉันได้ฉันไม่สามารถเข้าใจรหัสสปาเก็ตตี้หนึ่งพันบรรทัดได้หรือไม่?

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

มันเจ็บที่จะรักษารหัส

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

เพื่อนร่วมงานของฉันดูเหมือนจะไม่มีปัญหาที่คล้ายกัน

1. พวกเขาจัดการเพื่อดีบักวิธีการเขียนที่ไม่ดีได้เร็วกว่าฉันมาก
2. พวกเขาแนะนำข้อบกพร่องน้อยกว่าที่ฉันทำเมื่อเปลี่ยนรหัสฐาน
3. ดูเหมือนว่าพวกเขาจะจำได้ดีมากสิ่งที่พวกเขาต้องการเพื่อเปลี่ยนรหัสแม้ว่ามันจะต้องอ่านรหัสหลายพันบรรทัดในยี่สิบไฟล์ที่แตกต่างกัน
4. ดูเหมือนว่าพวกเขาจะไม่ถูกรบกวนจากอีเมลโทรศัพท์ดังผู้คนที่พูดคุยกันและคนอื่น ๆ ถามคำถามพวกเขา
5. พวกเขาไม่ต้องการใช้ระบบติดตามบั๊กที่เรามีอยู่แล้วตั้งแต่เราใช้ TFS พวกเขาชอบที่จะจำงานที่ควรทำทุกครั้ง

ทำไมสิ่งนี้ถึงเกิดขึ้น มันเป็นทักษะที่นักพัฒนาเฉพาะได้รับเมื่อทำงานกับรหัสที่เขียนไม่ดีเป็นเวลานานหรือไม่? การที่ฉันไม่มีประสบการณ์เกี่ยวกับรหัสที่ไม่ดีมีส่วนทำให้เกิดปัญหา / ความรู้สึกเหล่านี้หรือไม่? ฉันมีปัญหากับหน่วยความจำของฉันหรือไม่?

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

เช่นเดียวกันกับรหัสเพื่อนร่วมงานของคุณอาจเรียนรู้ที่จะกรอง "เสียงรบกวนของรหัส" ที่มาจากหลายระดับของนามธรรมในวิธีการเดียว

ใช้เวลาปรับตัวเข้ากับฐานรหัสเช่นที่คุณอธิบาย เพื่อนร่วมงานของคุณอาจมีเวลามากขึ้นที่จะเติบโตและอาจเลือกแผนการประชุมรูปแบบและโครงสร้างที่ไม่โดดเด่นใน "รหัสฐานสามเณร" อาจมีโครงสร้างของความโกลาหลมากกว่าที่คุณสามารถจินตนาการได้ พูดคุยกับเพื่อนร่วมงานของคุณขอให้พวกเขาจับคู่กับคุณสักครู่และเลือกสมองของพวกเขาว่าพวกเขาเข้าใกล้การแก้ไขข้อบกพร่องข้อใดข้อหนึ่งที่ได้รับมอบหมายให้คุณได้อย่างไร เมื่อพวกเขาขอให้คุณเปิดหน่วย X, Y หรือ Z ให้ถามพวกเขาว่าทำไมหน่วยนั้น, สิ่งที่เกี่ยวกับมันบอกพวกเขาว่ามันอาจจะเกี่ยวข้อง ฯลฯ

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

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

ไม่มีใครต้องการให้คุณเก็บทุกอย่างไว้ในความทรงจำ หากเพื่อนร่วมงานของคุณไม่ต้องการหรือต้องการระบบบั๊กเพียงแค่เขียนงานที่มอบหมายให้คุณในรายการสิ่งที่ต้องทำของคุณเองและเขียนบันทึกเมื่อ / หลังจากพูดคุยกับใครบางคนเกี่ยวกับรายละเอียดของงานของคุณ

มี 3 ประเด็นหลักที่ฉันเห็น:

คะแนน 1, 2 และ 3 เกิดขึ้นจากข้อเท็จจริงที่ว่าเพื่อนร่วมงานของคุณมีประสบการณ์มากขึ้นกับ codebase ซึ่งหมายความว่าพวกเขารู้ถึงนิสัยใจคอของมัน ซึ่งหมายความว่าพวกเขาใช้หน่วยความจำระยะยาวสำหรับกระบวนการตรวจแก้จุดบกพร่องและสามารถจำได้ว่า doXYZ ทำ UVW ได้จริง แต่ไม่เคยเปลี่ยนชื่อด้วยเหตุผลทางประวัติศาสตร์ อย่างไรก็ตามพวกเขาควรใช้เวลาสองสามเดือนในการเขียนโค้ดจากนั้นพวกเขาจะเริ่มรู้สึกเจ็บปวดของคุณ

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

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

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

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

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

3. สร้างสิ่งที่คุณต้องการเพื่อให้งานสำเร็จลุล่วง ถ้านั่นหมายถึงการสร้างแผนภูมิการไหลหรือเอกสารอื่น ๆ ให้ทำเช่นนั้น ไม่ว่าพวกเขาต้องการหรือไม่และพวกเขาใช้หรือไม่หลังจากที่คุณสร้างมันไม่เกี่ยวข้อง

4. การขัดจังหวะทำให้ทุกคนช้าลง การมุ่งเน้นที่จะทำให้คุณช้าลงมากขึ้น ยอมรับมันและพยายามกลับเข้ามาในร่องอย่างเร็วที่สุดเท่าที่จะทำได้

5. การคำนึงถึงข้อผิดพลาดสองถึงสามข้อนั้นไม่ใช่เรื่องเลวร้ายสามหรือสี่ข้อจะดีกว่า แต่แทนที่จะพยายามปรับปรุงมันให้เลิกและจดบันทึกไว้ เศษกระดาษ, ไวท์บอร์ด, tfs, excel, word หรือ notepad - แค่เขียนมันลงไป ฉันพนันได้เลยว่าสิ่งที่เพื่อนร่วมงานของคุณกำลังทำอยู่ ไม่ว่าจะเป็นการแก้ไขแบบสุ่ม

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

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

คำตอบที่มั่นใจได้ทั้งหมด:

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

2) เหมือนกันกับหมายเลข 1 แต่ใช้เมตริกอื่น คำตอบเดียวกัน

3) noteblock และปากกา หรือเอกสาร word / excel ไม่ยากที่จะแก้ปัญหา

4) นั่นคือปัญหาส่วนตัวของสมาธิ ไม่แน่ใจว่าจะปรับปรุงได้ด้วยตัวเองหรือไม่

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

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

ดังนั้นขั้นตอนแรกคือการล้างความคิดของคุณจากสิ่งนั้นเมื่อคุณอยู่ในโต๊ะทำงานของคุณ

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

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