ทำงานเป็นนักพัฒนาเพียงผู้เดียว: รับโค้ดดู


39

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

ฉันคิดว่าฉันจะได้รับคำตอบผ่านบทความของ Jeff Atwood: ในการเขียนโปรแกรม One Is The Loneliest Numberที่ดีที่สุดที่ฉันสามารถหาได้ในเรื่องนี้ แต่มันกลับกลายเป็นเพียงแค่ย้ำคำถามของฉัน

ฉันรู้ว่าเว็บไซต์ Stack Exchange เช่นนี้และการตรวจสอบโค้ดเป็นคำตอบที่เป็นไปได้ชัดเจน แต่หลาย ๆ คนคงชื่นชมมันไกลจากอุดมคติ:

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

มีคำตอบอื่นนอกเหนือจากการจ่ายที่ปรึกษาเพื่อดูรหัสของฉัน


3
ฉันมีปัญหานี้เช่นกัน (กับโครงการเพื่อความสนุกสนาน) ฉันเพียงคนเดียวที่โชคดีพอที่จะมีเพื่อนโปรแกรมเมอร์สักสองสามคนที่เต็มใจมองผ่านโค้ดของฉัน
Austin Hyde

23
คุณสามารถพูดคุยกับตัวเองได้เสมอ - นี่เป็นสิ่งที่ดีสำหรับการตรวจสอบความบ้า :-)
Danny Varod

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

6
การทำงานด้วยตัวเองอาจจะดีกว่าการทำงานกับคนโง่
งาน

2
ไม่ใช่วิธีแก้ปัญหาจริงๆ แต่คุณสามารถออกไปเที่ยวกับแชท SO หรือช่อง IRC ที่เหมาะสมได้ ที่อาจช่วยแบ่งเบาภาระในการทำงานด้วยตัวเอง
Tikhon Jelvis

คำตอบ:


36

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


สิ่งที่ดี! ... 15
Marjan Venema

2
ในทางทฤษฎีสิ่งนี้สามารถใช้งานได้จริงในทางปฏิบัติไม่มีทางที่จะนรกเขาจะกลับไปดูรหัสที่เขาเขียนเมื่อ 2 สัปดาห์ก่อนถ้ามันใช้งานได้ และถ้าหากมันกลับไปใช้เวลากับมันเพราะเหตุผลเดียวที่ทำให้มัน "สวยกว่า" เสียเวลาก็ควรทำเมื่อใดและถ้ามันถูกสัมผัสอีกครั้ง
โทมัสโบนินี

3
@Krelp: ฉันดูรหัสที่ผ่านมาตลอดเวลาและไม่มีวิธีที่คุณสามารถเพิ่มคุณสมบัติและโดยทั่วไปบำรุงรักษาซอฟต์แวร์โดยไม่ต้องดูโค้ดที่เขียนก่อนหน้านี้ ไม่มีสิ่งเช่นสถาปัตยกรรมที่สมบูรณ์แบบและ abstractions รั่วเป็นกฎมากกว่าข้อยกเว้นดังนั้นการมองไปที่รหัสที่เขียนก่อนหน้านี้เป็นสิ่งที่หลีกเลี่ยงไม่ได้ ฉันรู้ว่าตัวเขียนรหัสมาราธอนเป็นรูปเคารพในวงการการเขียนโปรแกรม แต่การเขียนโค้ดมาราธอนนำไปสู่ความเหนื่อยหน่ายและโครงการที่ถูกทิ้งไว้อย่างรวดเร็วดังนั้นนอกเหนือจากการปรับปรุงคุณภาพโค้ดแล้วการหยุดพักและกลับมาอีกครั้ง
davidk01

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

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

17

มีคำตอบอื่นนอกเหนือจากการจ่ายที่ปรึกษาเพื่อดูรหัสของฉัน

เลขที่

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

หากพวกเขาตรวจสอบการออกแบบของคุณแม้จะไม่ได้ดูรหัสของคุณก็ควรจะดีพอ


4
นักเขียนมืออาชีพหลายคนทำเช่นนี้
JeffO

10

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

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

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

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


ฉันไม่เห็นว่าคำตอบของ TDD เป็นอย่างไร
Aaronaught

1
@Aaraught ฉันอยู่ในเรือลำเดียวกันกับ TS และฉันรับรองได้ว่าการทดสอบการเขียน (ทั้งก่อนรหัสใน TDD หรือหลังจากนั้น) เป็นวิธีการตรวจสอบว่ารหัสของคุณมีสติ หากคุณไม่สามารถทดสอบได้ก็ไม่ดี
stijn

1
@stijn: มันอาจจะเป็น (ค่อนข้าง) จริงที่โค้ดไม่ดีนั้นยากกว่าในการเขียนการทดสอบ แต่มันไม่เคยเป็นไปไม่ได้เลย - มันเป็นวิธีที่ระบบดั้งเดิมได้รับการอัพเกรด แม้ว่าเราจะยอมรับการเรียกร้องที่น่าสงสัยว่ารหัสที่ดีนั้นนำไปสู่การทดสอบที่ดี แต่การอ้างสิทธิ์แบบผกผันยังไม่ได้รับการพิสูจน์ การทดสอบที่ผ่านไม่ได้หมายความว่ารหัสมีคุณภาพที่สมเหตุสมผล ในความเป็นจริงหลักฐานของ TDD - "แดงเขียวเขียว refactor" เป็นหลักหมายถึงการเขียนรหัสเลอะเทอะที่ผ่านการทดสอบแล้ว refactoring มันเพื่อปรับปรุงคุณภาพดังนั้นในตอนท้ายของวันที่คุณกลับมาที่คุณเริ่ม เพียงแค่มีการทดสอบ
Aaronaught

2
@Aaraught: คุณทำคะแนนให้ถูกต้อง แต่ถึงกระนั้นฉันก็ยังยืนหยัดอยู่ได้ว่าการทดสอบนั้นเป็นวิธีที่ดีมากในการตรวจสอบการใช้รหัส (แม้ว่าไม่ใช่วิธีเดียวเท่านั้น); ประสบการณ์ได้พิสูจน์ฉันดังนั้นมันจึงมีประโยชน์โดยเฉพาะอย่างยิ่งเพื่อดูว่า SRP ถูกละเมิดอย่างหนักแค่ไหน
stijn

@ Mark: นั่นดี แต่เกร็ดเล็กเกร็ดน้อยเหล่านี้ทั้งหมดมีมูลค่าน้อยกว่า "ฉันหายไป 50 ปอนด์ใน 2 สัปดาห์" โฆษณาเรียกร้องเพราะสิ่งที่ได้รับการพูดคุยเกี่ยวกับยังไม่ได้รับแม้จริงวัดให้อยู่คนเดียวที่สังเกตภายใต้สภาวะควบคุม ใช่มีหลักฐานว่า TDD ช่วยลดข้อบกพร่องก่อนเผยแพร่และนั่นเป็นสิ่งที่ยอดเยี่ยม การตรวจสอบโค้ดจะช่วยแก้ปัญหาที่แตกต่างกันอย่างสิ้นเชิงและไม่มีพื้นฐานสำหรับการสมมติว่า TDD แก้ปัญหาเดียวกัน การทดสอบหน่วย "โรงเรียนเก่า" น่าจะดีกว่าสำหรับเรื่องนี้เพราะพวกเขาวางข้อ จำกัด ในการทดสอบในแต่ละชั้นเรียนแทนที่จะเป็นกลุ่ม
Aaronaught

6

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


4

ฉันอยู่ในสถานการณ์ที่คล้ายกันและฉันต้องพึ่งพา Stack Overflow มากเพื่อรับฟังความคิดเห็นเกี่ยวกับคำถาม gnarly ฉันยังพบโดยอาศัยอำนาจตามจริงต้องเขียนคำอธิบายของปัญหาที่คำตอบมักจะชัดเจน ในแง่ของแนวปฏิบัติที่ดีที่สุดฉันเป็นนักพัฒนา. Net และฉันใช้ ReSharper ซึ่งจะให้คำแนะนำเกี่ยวกับทางเลือกฝึกหัดที่ดีในการเขียนโค้ดที่ฉันเขียน (ซึ่งบางครั้งฉันก็เพิกเฉย และอีกเครื่องมือที่มีประโยชน์คือ FxCop ซึ่งจะทำการวิเคราะห์โค้ดแบบคงที่และเน้นปัญหาใด ๆ ที่ไม่ตรงกับ ruleset

ไม่อย่างนั้นมันก็ขึ้นอยู่กับคุณที่จะอ่านและติดตามข่าวสารล่าสุดเกี่ยวกับแนวทางปฏิบัติในปัจจุบัน ฉันชอบอัลวินแอชคราฟท์ของ Morning Dewสำหรับลิงก์ไปยังสิ่งใหม่และปรับปรุงในโลกของ. Net


4

ฉันขอแนะนำให้พยายามสร้าง (หรือค้นหา) กลุ่มผู้ใช้ขนาดเล็ก ทำให้โค้ดของคุณพร้อมใช้งานและให้ทุกคนทุ่มเทเพื่อให้ทำงานได้ - ครึ่งชั่วโมงหรือมากกว่าทุกวัน


3

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


2

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

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

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


2

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

ฉันรู้สึกเหมือนกันกับ> 75% ของคำถามที่ฉันโพสต์

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

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

กรณีในจุด:

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

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


นอกจากนี้ในขณะที่ฉันไม่สามารถจับมันได้ แต่การตอบสนองของการสนทนาฟรีไม่สามารถจับคู่ได้โดยการสนทนาทางอินเทอร์เน็ตในรูปแบบใด ๆ ที่ฉันนึกออก

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

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

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

สี่จุดในกรณี:

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

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


นอกจากนี้การซ่อนรายละเอียดเพื่อถามคำถามที่กำหนดไว้อย่างดีช่วยลดความเป็นไปได้ที่จะมีคนเจอปัญหาที่คุณไม่ได้คิด

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

กรณีในจุด:

ฉันมักจะมี Visual Studio ที่สองที่ทำงานด้วยแอปคอนโซลที่เรียกว่า Sandbox เมื่อใดก็ตามที่ฉันพบปัญหาทางเทคนิคฉันจะคัดลอกรหัสที่กระทำผิดลงในกล่องทรายและเริ่มเล่นกับมัน

  • จะเกิดอะไรขึ้นเมื่อฉันเปลี่ยนการตั้งค่านี้
  • ฉันสามารถทำให้เกิดปัญหาซ้ำได้หรือไม่ถ้าฉันย่อรหัสให้สั้นลง
  • การตั้งค่าใดที่ทำให้เป็นไปได้ / เป็นไปไม่ได้ที่จะทำให้เกิดปัญหาอีกครั้ง

ใน 90% ของกรณีฉันพบสาเหตุของปัญหาเพราะ sandbox ช่วยให้ฉันดูรหัสที่ละเมิดโดยไม่ถูกรบกวนโดยบริบทโดยรอบ (หรือตัวอย่างเช่นความไม่แน่นอนเกี่ยวกับค่าที่มาสำหรับส่วนต่าง ๆ ของรหัส

ในอีก 10% ของกรณีฉันเหลือรหัสขั้นต่ำในการทำซ้ำปัญหาซึ่งทำหน้าที่เป็นตัวอย่างที่สมบูรณ์แบบเพื่อโพสต์บน StackOverflow


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

เมื่อคุณมี MCVE แล้วคุณไม่ควรมีข้อมูลส่วนบุคคล (หรือ บริษัท ) มากนัก หากคุณทำเช่นนั้นเนื่องจากรหัสมีน้อยจึงเป็นเรื่องง่ายที่จะเปลี่ยนชื่อสิ่งต่าง ๆ เป็นตัวอย่าง foo / bar / baz ขั้นพื้นฐานเพิ่มเติม

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