วิธีการของการดีบักรหัส (สถานการณ์ฝันร้าย)


16

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

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

  2. แทบจะไม่มีการบันทึกในแอพของเรา ไม่มีการทดสอบหน่วย

  3. การควบคุมเวอร์ชันมีโซลูชันเต็มรูปแบบเพียง 1 เวอร์ชันเท่านั้น (โดยใช้แหล่งที่มาที่ปลอดภัย 2005) ดังนั้นจึงเป็นไปไม่ได้ที่จะได้รับโซลูชั่นรุ่นก่อนหน้าทั้งหมด แต่เพียงไฟล์เดียว (ถ้าไม่มีใครรู้วิธีแก้ปัญหานี้)

  4. ไม่สามารถทำซ้ำภายในเครื่องบ่อยครั้งไม่สามารถทำซ้ำในสภาพแวดล้อมการทดสอบ (มีโอกาสสูงที่การทดสอบและการผลิตไม่เป็นรุ่นเดียวกัน)

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

  6. นี่คือโซลูชัน. net VB

  7. ไม่สามารถติดตั้งซอฟต์แวร์ใด ๆ ในเว็บไซต์ของลูกค้า แต่สามารถอยู่ในเครื่อง

  8. แอปพลิเคชันของเราสามารถปรับแต่งได้อย่างมาก แต่น่าเสียดายที่ตรรกะการปรับแต่งนั้นแพร่กระจายไปทั่วชั้นเรียนและไฟล์ทั้งหมดตั้งแต่ส่วนหน้าไปจนถึงชั้นข้อมูลรวมถึงการเปลี่ยนแปลงที่กำหนดเองไปยังฐานข้อมูลตามลูกค้าแต่ละราย

  9. แทบไม่มีความคิดเห็นในรหัส ไม่มีเอกสารเกี่ยวกับสถาปัตยกรรม ไม่มีเอกสารเกี่ยวกับ API สิ่งเดียวที่เรามีคือร้อยต่อร้อยอีเมลโซ่ที่ค่อนข้างจะอธิบายสิ่งที่เกิดขึ้น มีเพียงคนที่รู้รหัสเป็นคนแรกที่เขียนมัน แต่พวกเขาไม่ได้เป็นนักพัฒนาอีกต่อไปดังนั้นพวกเขาจึงไม่ได้มีส่วนร่วมมากนัก

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

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

ฉันรู้ว่าสิ่งนี้ออกมาเป็นคำพูดหยาบคายและในระดับหนึ่ง แต่ฉันหมดหวังสำหรับตัวเลือก มีวิธีการ / เครื่องมืออื่น ๆ ที่ฉันสามารถใช้ได้หรือไม่?


43
คุณมีประวัติย่อหรือไม่?
Robert Harvey

5
+1 สำหรับ "ฉันต้องการยิงตัวเองเช่นกัน" Source Safe 2005, อุ๊ปส์ อย่างน้อยคุณควร 'มุ่งเน้น' ในบทเรียนประวัติศาสตร์ที่ยอดเยี่ยม - โดยพื้นฐานแล้วคุณเป็นนักเดินทางข้ามเวลา! คุณจะได้เรียนรู้บทเรียนของทศวรรษของการพัฒนาความรู้อย่างระมัดระวัง "นี่คือเหตุผลที่เราไม่ทำเช่นนั้นอีกต่อไป" ความเร็วตั๊กแตน
BrianH

7
ความต้องการที่กำหนด # 1 วิธีเดียวที่จะมีประสิทธิภาพในการแก้ไขข้อบกพร่องนี้คือการมีญาณทิพย์ อย่างจริงจังไม่มีกระสุนวิเศษที่จะทำสิ่งนี้ยกเว้นการเล่นลูกเต๋าชนิดหนึ่ง ในบางวิธีสิ่งนี้ควรลดความกดดันของคุณเนื่องจากการแก้ไขข้อบกพร่องเป็นเรื่องของโชค หรือผู้บริหารของคุณจะสั่งให้คุณโชคดี? ชัดเจนว่านี่ไม่ยั่งยืนดังนั้นคุณควรมองหาโอกาสอื่น ๆ
Charles E. Grant

14
นี่คือคำแนะนำด้านอาชีพจริง: ใช้เวลานานเกินไปในบ้านที่มีแนวปฏิบัติด้านวิศวกรรมซอฟต์แวร์ที่น่ากลัวและคุณอาจถูกผู้บริหารกล่าวหาว่าเป็นผู้พัฒนาที่ไม่ดีสำหรับปัญหาที่ตามมาอย่างหลีกเลี่ยงไม่ได้ ฉันเคยไปที่นั่นและฉันมั่นใจว่าคนอื่น ๆ ก็มีเช่นกัน ที่ดีที่สุดมันนำไปสู่นิสัยการพัฒนาที่ไม่ดี
Gort หุ่นยนต์

2
ฉันจัดการสถานการณ์เหล่านี้ได้อย่างไร: ถ้าฉันไม่ได้รับค่าตอบแทนสูงกว่าตลาดฉันจะไปหาสิ่งอื่นให้ทำ
kevin cline

คำตอบ:


22

คำแนะนำของ Robert Harvey น่าจะดีที่สุด แต่เนื่องจากคำแนะนำด้านอาชีพอยู่นอกหัวข้อฉันจะให้คำตอบว่า:

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

ดูเหมือนว่าคุณจะรู้ว่าสิ่งต่าง ๆควรทำงานอย่างไร หากไม่มีใครช่วยคุณได้ (อีกครั้งให้เพิกเฉยต่อคำแนะนำด้านอาชีพ) ทางเลือกเดียวของคุณคือเริ่มแก้ไขสิ่งเหล่านี้ด้วยตัวเอง

อันดับแรกสำหรับทุกสิ่งที่ศักดิ์สิทธิ์รับสิ่งนั้นในระบบควบคุมเวอร์ชันจริง ไม่มีอะไรจะสวยเลยนอกจาก Source Safe ซึ่งเป็นที่รู้จักกันดีว่าเป็นกองขยะที่เหม็นอับ gitฟรีและสามารถตั้งค่าได้อย่างง่ายดาย คุณไม่สามารถแก้ไขปัญหาการขาดการควบคุมเวอร์ชันที่ผ่านมา แต่อย่างน้อยก็หยุดปัญหาไม่ให้ดำเนินต่อไปในอนาคต

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

และเริ่มเขียนแบบทดสอบอย่างน้อยก็สำหรับการเปลี่ยนแปลงใหม่ที่คุณทำ

ไม่มีการเคลือบน้ำตาล: ไม่มีคำตอบที่นี่ที่ไม่เกี่ยวข้องกับงานจำนวนมากหรือการปฏิบัติเช่นนี้เป็นคำถามของอาชีพ


เชื่อฉันฉันไม่ต้องการอะไรมากไปกว่าการเพิ่ม asserts, guards และ logging ซึ่งอาจจะเขียน layer ข้อมูลอีกครั้ง (ฉันกำลังเขียน validator ที่ใช้กำหนดค่าเพื่อวินิจฉัยปัญหาการกำหนดค่าทั่วไป) น่าเสียดายที่มันไม่ได้ขึ้นอยู่กับฉัน ฉันสามารถขอให้มีบางสิ่งผลักดันลงในซอร์สอย่างปลอดภัย แต่การตอบกลับโดยทั่วไปคือ 'ความตั้งใจของคุณดี แต่นี่ไม่ใช่สิ่งที่เราควรจะมุ่งเน้น' อนิจจาฉันเป็นรุ่นน้องที่มีประสบการณ์ 1/2 ปี ฉันจะปีนภูเขานี้ซักพัก
Igneous01

9
@ Igneous01 จริง ๆ แล้วลองหาภูเขาอื่นเพื่อปีน สภาพการทำงานในที่อื่นอาจไม่สมบูรณ์แบบ แต่ฉันคิดว่าอย่างน้อยที่สุดก็ดีกว่าสิ่งที่คุณกำลังประสบอยู่ หากผู้รักษาประตูปฏิเสธการปรับปรุงของคุณด้วย "นี่ไม่ใช่สิ่งที่เราควรมุ่งเน้นไปที่" นั่นคือการตัดสินใจของพวกเขาและพวกเขาจะเก็บเกี่ยวผลของนโยบายที่ล้มเหลวนั้น (พวกเขาสูญเสียเงินจำนวนมากในแง่ของเวลาในการพัฒนา . คำถามคือคุณต้องการที่จะติดกับพวกเขาจนกว่าพวกเขาจะทำอย่างไร
cmaster - คืนสถานะโมนิก้า

6
และโปรดจำไว้ว่าเมื่อนโยบายที่ไม่ดีล้มเหลวทุกคนที่เกี่ยวข้องดูไม่ดีแม้แต่คนที่ไม่เห็นด้วย
Gort the Robot

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

4
@ Igneous01: เรียกใช้อย่าเดิน สถานที่นี้ไม่สบายและจะทำให้คุณป่วย
Reinstate Monica - M. Schröder

8

1) ไม่สามารถใช้ดีบักเกอร์บนไซต์ลูกค้า ...

นั่นเป็นเรื่องปกติอย่างสมบูรณ์

... หรือในพื้นที่

นั่นเป็นปัญหา

2) แทบจะไม่มีการบันทึกในแอพของเรา

การบันทึกคือการแก้จุดบกพร่องการผลิต

ไม่มีการทดสอบหน่วย

โอ้ที่รัก ทุกคนถึงแม้ว่า

3) การควบคุมเวอร์ชันมีโซลูชันเต็มรูปแบบเพียงเวอร์ชันเดียวเท่านั้น

จากนั้นคุณไม่ได้ใช้การควบคุมเวอร์ชัน

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

ดังนั้นการปรับใช้เท่านั้นสภาพแวดล้อมไคลเอนต์แสดงข้อผิดพลาด

ในกรณีที่คุณจะต้องเข้าสู่ระบบ disgnostic ฝังตัวอยู่ในรหัสโปรแกรมที่ (ก) กับดักและ [เต็มที่] บันทึก [ร้ายแรง] ข้อผิดพลาดและ (ข) สามารถ "โทรออกขึ้น" ตามความต้องการในการผลิตที่เพิ่มขึ้นอย่างต่อเนื่องการวินิจฉัยที่มีประโยชน์ในการ ติดตามปัญหา

5) มีโอกาสสูงที่เวอร์ชันที่ไคลเอ็นต์กำลังใช้จะแตกต่างจากแหล่งที่ปลอดภัย

อีกครั้งคุณไม่ได้ใช้การควบคุมเวอร์ชันเพื่อประโยชน์ของคุณ

8) แอปพลิเคชันของเราสามารถปรับแต่งได้อย่างมาก

นั่นเป็นเรื่องปกติ

ความแตกต่างเฉพาะไซต์ควรได้รับการจัดการผ่านการควบคุมเวอร์ชัน "การแตกสาขา"

9) แทบไม่มีความคิดเห็นในรหัส

นั่นคือทั้งหมดที่พบบ่อยเกินไปเนื่องจากนักพัฒนาเขียนรหัส "เอกสารด้วยตนเอง" ไม่ใช่เหรอ?
หรืออย่างน้อยก็รหัสที่พวกเขาเข้าใจในวันที่พวกเขาเขียน

ไม่มีเอกสารเกี่ยวกับสถาปัตยกรรม

โอ้ที่รัก

ไม่มีเอกสารเกี่ยวกับ API

โอ้ที่รักโอที่รัก

และก่อนที่คุณจะพูดมัน ... ใช่ฉันรู้ ฉันต้องการยิงตัวเองเช่นกัน

ไม่มี คุณต้องการที่จะยิงคนที่เขียนสิ่งนี้สร้างระเบียบที่ไม่มีเอกสารและไม่เคลื่อนไหวแล้วย้ายไปยังทุ่งหญ้าใหม่ทิ้งความวุ่นวายไว้เบื้องหลัง

ข้อผิดพลาดที่พบบ่อยที่สุดที่ฉันพบคือข้อผิดพลาดในการอ้างอิงแบบ null, การ cast ที่ไม่ถูกต้องและฟังก์ชัน / ฟังก์ชั่นที่หายไปไม่ตรงกัน

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

ฟังก์ชั่นลายเซ็นไม่ตรงกันควรทำให้เกิดการสร้างเสีย; สิ่งเหล่านั้นควรทำให้เกิด "ชิ้นส่วนที่เสียหาย" และไม่ควรทำออกจากประตู!


2
"เขียนโค้ดให้เหมือนกับว่าคนที่จบลงด้วยการรักษารหัสของคุณนั้นเป็นนักจิตวิทยาที่รุนแรงที่รู้ว่าคุณอยู่ที่ไหน"
PerryC

ข้อผิดพลาดรันไทม์มีสาเหตุมาจากการขาดความเข้าใจมากกว่าการขาดการเขียนโปรแกรมป้องกัน การตั้งโปรแกรมป้องกันเป็นเพียงวิธีการซ่อนความจริงที่ว่ารหัสไม่ทำงาน
253751

1
"ไม่มีเอกสารเกี่ยวกับสถาปัตยกรรม" มักจะหมายถึง "ไม่มีสถาปัตยกรรม" ...
gnasher729

The site-specific differences should be managed through Version Control "Branching".- ฉันไม่คิดว่านี่เป็นวิธีที่ดีที่สุดในการดำเนินการต่อ การใช้ไฟล์กำหนดค่าและการสลับสลับคุณสมบัติดูเหมือนจะเป็นเรื่องปกติ
sixtyfootersdude

5

เริ่มด้วยการบันทึก สิ่งนี้จะมีผลกระทบมากที่สุด นำเฟรมเวิร์กการบันทึกไปใช้ในฐานของรหัสเช่น Log4Net หรือที่คล้ายกัน เริ่มบันทึกสิ่งที่รหัสทำ

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

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

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

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

จัดทำเอกสารความรู้เกี่ยวกับเผ่าตามต้องการ รหัสควรเป็นเอกสารด้วยตนเองดังนั้นความคิดเห็นจึงกระจัดกระจาย แต่หลาย ๆ ระบบมีวิธีที่ "ผิดปกติ" ในการทำสิ่งต่าง ๆ ชี้ไปที่การเข้ารหัส WIKI หรือที่เก็บแบบไม่เป็นทางการอื่น ๆ ลองพิจารณาถึงมาตรฐานการเข้ารหัสและแนวทางปฏิบัติด้วย บังคับใช้มาตรฐานเหล่านั้นผ่านชุดเครื่องมือเช่น Resharper เนื่องจากรหัสส่วนใหญ่อาจไม่เป็นไปตามมาตรฐานและแนวทางใด ๆ ให้ใช้มาตรฐานกับรหัสใหม่ที่เขียนขึ้น

ตั้งแต่ใหม่ของฉันฉันจะปฏิบัติเช่นนี้เหมือนการปฏิบัติหน้าที่ 6 เดือนถึง 2 ปีจากนั้นเลือกที่จะอยู่ต่อหรือย้ายไป นำความพึงพอใจจากการทำสิ่งต่าง ๆ ได้ดีกว่าวันก่อนเล็กน้อย


4

ก่อนอื่นทั้งหมดข้างต้น ... เหมือนกัน

ฮิวริสติกบางส่วน:

  • ใช้การควบคุมแหล่งที่มาบนคอมพิวเตอร์ที่กำลังพัฒนาของคุณ มันเป็นสิ่งที่ดีที่สุดที่ฉันทำ มันไม่ได้ใช้แทนการควบคุมเวอร์ชันของโครงการที่เรามี มันเป็นเครื่องมือที่ให้อิสระอย่างน่าอัศจรรย์ในการทดลองแฮ็คปัญหาการทำงานพร้อมกันอย่างอิสระ ฯลฯ ฉันดีกว่าในการใช้การควบคุมเวอร์ชันเพราะฉันมีอิสระที่จะกล้าแสดงออกและเรียนรู้
  • เท่าที่คุณเพิ่มความคิดเห็นจัดลำดับความสำคัญองค์ประกอบอินเทอร์เฟซสาธารณะเพื่อใช้ประโยชน์จาก Intellisense ทำสิ่งนี้ตามที่คุณถอดรหัสในระหว่างการผจญภัยที่ดีบั๊ก
  • อดทนกับการรีแฟคเตอร์ย่อย ๆ ไม่ช้าก็เร็วสำหรับโค้ดขนาดใหญ่ที่กำหนดคุณจะได้รับมวลที่สำคัญซึ่งจะช่วยให้การรีแฟคเตอร์ขนาดใหญ่เช่น DRYing โค้ดซ้ำซ้อนในคลาสต่างๆหมดลง
  • อย่าผสมการฟอร์แมตโค้ดและการเปลี่ยนแปลงจริงในการควบคุมเวอร์ชันเดียวกัน
  • หลักการที่เป็นของแข็ง
    • อย่าเพิกเฉยต่อความรับผิดชอบใด ๆ ทำได้ดีนี่คือเส้นทางสู่สัญญาที่มุ่งเน้นวัตถุ IMHO
    • ละเว้นการเปิด / ปิดเสมอ
    • เราไม่ได้พูดถึงรหัสใหม่ที่นี่
    • การสร้างอินเตอร์เฟสโดยไม่มีการออกแบบที่มีจุดประสงค์ขัดขวางการบำรุงรักษา
  • refactoring
  • ไฟล์รหัสบางไฟล์จำเป็นต้องทำการฟอร์แมตใหม่อย่างสมบูรณ์เปลี่ยนชื่อตัวแปร ฯลฯ ก่อนที่จะลองแก้ไขข้อบกพร่อง อย่าอายที่จะใช้เมนู refactor ของ visual studio โดยไม่ต้องทำการทดสอบยูนิต
  • เอกสารเดียวที่ไม่สามารถวางผิดที่อยู่ในไฟล์รหัส
  • เมื่อคุณได้รับการควบคุมเวอร์ชันให้คิดแผน VC และบันทึกไว้! และคิดแผนการตั้งชื่อสาขาแท็กที่จะเน้นรุ่นซอฟต์แวร์และเหตุการณ์สำคัญที่สำคัญ ๆ
  • ใช้อุปกรณ์ที่ดี
    • รับจอภาพที่หมุนได้ แนวตั้งเป็นวิธีการอ่านรหัสอย่างรวดเร็ว
    • ไดรฟ์ภายนอกสำหรับการสำรองข้อมูลแป้นพิมพ์พร้อมปุ่มชนิดขวาเมาส์มัลติฟังก์ชั่น อย่างน้อย 1 ไดรฟ์ USB ที่ดีจริงๆ ฉันยังมีของตัวเองเก้าอี้เฮอร์แมนมิลเลอร์
    • รับซอฟต์แวร์เปรียบเทียบที่ดีมาก ฉันมีความสุขกับBeyond เปรียบเทียบ
  • ฝึกการดีบักยาง Ducky
  • บางครั้งสิ่งที่แย่ที่สุดที่สามารถเกิดขึ้นได้คือพวกเขาไม่ได้ยิงคุณ

แก้ไข

การพัฒนาแอพพลิเคชั่น Brownfield ใน. NET

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

ยื่นออกมา

อยู่ต่อพูด 1.5 ปีถ้าทำได้ นานพอที่จะรู้ว่าคุณกำลังทำอะไรอยู่ คุณจะรู้ว่าถ้าคุณได้รับประสบการณ์ 2 ปีหรือประสบการณ์ 6 เดือน 4 ครั้ง

การเป็น "รุ่นน้องที่มีประสบการณ์ 1/2 ปี" ฉันกังวลว่านายจ้างที่มีศักยภาพจะมองว่าเป็นการประกันตัวเร็วเพราะคุณไม่สามารถแฮ็คมันได้ เป็นเรื่องหนึ่งที่จะบอกว่าคุณเรียนรู้ z, y, x, ใช้ชื่อและเตะตูด - แต่ไม่ได้รับอนุญาตให้มีส่วนร่วมในความสามารถของคุณ; และอีกอย่างหนึ่งก็เสี่ยงต่อการปลดงานรหัสการจัดการ ฯลฯ โดยวิธีการอธิบาย

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

สิ้นสุดการแก้ไข


+1 สำหรับอย่าผสมการฟอร์แมตโค้ดและการเปลี่ยนแปลงจริงในการควบคุมเวอร์ชันเดียวกัน
kiwiron

0

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

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

คุณอาจต้องสร้างสภาพแวดล้อมการทดสอบหลายแห่งเพื่อจำลองการปรับใช้ต่างๆ (แน่นอนว่าการแก้ไขที่ง่ายที่สุดคือการสร้าง clean build ใหม่และปรับใช้อย่างสม่ำเสมอทุกที่ แต่ดูเหมือนว่าเป็นไปไม่ได้ใช่ไหม?)

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

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

หลังจากนี้คุณสามารถเริ่มปรับปรุงฐานรหัสอย่างระมัดระวังเพื่อให้การดีบักง่ายขึ้น การเพิ่มการบันทึกอาจเป็นการปรับปรุงที่มีความเสี่ยงน้อยที่สุด

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


0

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


เมื่อคุณหมายถึง decompile คุณหมายถึงการใช้บางอย่างเช่น IDA Pro เพื่อดูรหัสเครื่อง? ฉันอาจจะเป็นคนเดียวที่ใช้มันแล้วเพราะไม่มีใครที่นี่รู้ว่าการชุมนุม (และฉันรู้พื้นฐานมาก)
Igneous01

อย่างนี้. NET ไบนารีไม่ได้เป็นรหัสเครื่องพวกเขาอยู่ใน CIL ( en.wikipedia.org/wiki/Common_Intermediate_Language ) สิ่งนี้สามารถแปลงกลับไปเป็น c # หรือ VB ได้อย่างง่ายดายและแม่นยำโดยเฉพาะอย่างยิ่งถ้ามันไม่งง คุณสามารถลองใช้ ILSpy ได้เช่น ( ilspy.net ) แต่อาจมีเครื่องมืออื่น ๆ ที่คุณสามารถใช้
20
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.