ทำไมการคอมเม้นท์โค้ดออกไปแล้วค่อย ๆ ลบมันออกเพื่อติดตามสิ่งที่ฉันได้ทำไปแล้วและยังคงต้องทำอะไรอีก?

21

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

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

ฉันควรทราบว่าฉันกำลังทำสิ่งนี้ในโครงการส่วนบุคคลที่ฉันพัฒนาอยู่คนเดียว

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

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

ฉันขอถามข้อบกพร่องเหล่านี้ของสิ่งที่ฉันทำที่ฉันไม่สามารถเห็นได้ตอนนี้หรือไม่

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

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

anti-patterns comments

— gaazkam
แหล่งที่มา

คุณส่งมอบรหัสความคิดเห็นไปยังการควบคุมเวอร์ชันหรือไม่?

— หยุดทำร้ายโมนิก้า

1

@Goyo ฉันไม่ได้ใช้การควบคุมเวอร์ชันเลย ฉันถูกบอกว่าฉันควรเริ่มใช้การควบคุมเวอร์ชัน (แม้ว่าจะเป็นโครงการส่วนบุคคลชายคนหนึ่ง) และแน่นอนว่าการควบคุมเวอร์ชันจะช่วยให้ฉันหยุดการแสดงความคิดเห็นรหัส (ซึ่งฉันควร)

— gaazkam

4

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

— หยุดทำร้ายโมนิก้า

4

มันเป็นความจริงที่ว่าถ้าคุณใช้รหัส cmoment คุณสามารถยกเลิกได้โดยง่ายโดยไม่ใส่เครื่องหมายข้อคิดเห็น แต่ถ้าคุณเปลี่ยนสิ่งที่ ssome ในไฟล์บางไฟล์และจำเป็นต้องย้อนกลับไปคุณจะเมาโดยไม่มีการควบคุมเวอร์ชัน ดังนั้น "เริ่มใช้การควบคุมแหล่ง" ควรจะเป็นวิธีการดังกล่าวข้างต้นจัดลำดับความสำคัญของคุณมากกว่า "ไม่ได้แสดงความคิดเห็นรหัส" :)

— Walfrat

2

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

— Doc Brown

29

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

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

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

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

— JimmyJames
แหล่งที่มา

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

— Peter M

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

— JimmyJames

ฉันมีหลายฐานรหัสฉันทำงานที่เกลื่อนไปด้วยกับความคิดเห็นสิ่งที่ต้องทำ มันไม่เลวจริงๆเพราะปกติแล้วจะมี 1-2 บรรทัด สิ่งที่ฉันชอบเกี่ยวกับความคิดเห็นของสิ่งที่ต้องทำคือ IDE ของฉันมีแท็บ "สิ่งที่ต้องทำ" ใกล้กับสถานีที่เติมรายการความคิดเห็นนั้นโดยอัตโนมัติพร้อมตัวอย่างของความคิดเห็นและหมายเลขไฟล์ / บรรทัด ประเด็นคือมันมีประโยชน์เมื่อในบาง บริษัท ที่พวกเขาไม่ใช้อ้าปากค้างใช้ปัญหาถึงแม้ว่าพวกเขาจะใช้ Git / Github ใช่คุณสามารถทำอะไรได้บ้างพยายามโน้มน้าวให้ฝ่ายจัดการใช้ปัญหา Git แทนที่จะเป็น Google ชีต? ใช่พยายามและล้มเหลว โอ้ดี แสดงความคิดเห็นสิ่งที่ต้องทำมันคือ!

— Chris Cirefice

6

ฉันขอถามข้อบกพร่องเหล่านี้ของสิ่งที่ฉันทำที่ฉันไม่สามารถเห็นได้ตอนนี้หรือไม่

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

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

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

เนื้อหานี้สามารถนำมาเปรียบเทียบกับซอฟต์แวร์ฮาร์ดไดรฟ์ "snap shot" เช่นเดียวกับ Windows ที่มี (สิ่งคืนค่า) หากใช้สแนปชอตพร้อมกับไวรัสในนั้นคุณจะฆ่าไวรัส แต่หลังจากนั้นต้องย้อนกลับคุณสามารถย้อนกลับไปยังจุดที่ไวรัสปรากฏขึ้นอีกครั้ง

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

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

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

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

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

— เจมส์
แหล่งที่มา

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

— จูลส์

4

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

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

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

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

/*
 * Need this sort of functionality added back before too long:
 * .... OLD CODE HERE
 */

โดยส่วนตัวแล้วฉันเอนตัวไปทางอะไรมากกว่านี้:

 * TODO:
 *      @todo   Possible get rid of intermediate LRUCache_ object.
 *
 *      @todo   Find some reasonable/simple way to get
 *              LRUCache<PHRShortcutSpec, PHRShortcutSpec, PHRShortcutSpecNoAuthCacheTraits_>   sRecentlyUsedCache (kMaxEltsInReceltlyUsedCache_);
 *              Working with ONE T argument
 *              Add(elt2cache).
 ...

และฉันสามารถโยน 'ข้อมูลโค้ด' จากโค้ดเก่าเป็นประโยชน์ได้

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

ขอให้โชคดี!

— Lewis Pringle
แหล่งที่มา

2

มีหลายเหตุผลที่จะแสดงความคิดเห็นรหัส: -

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

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

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

— Simon B
แหล่งที่มา

1

เหล่านี้เป็นเหตุผลที่ว่าทำไมคุณค่อนข้างควรใช้ SCM (และ cranches ภายใน)

— ทิโมธียอมจำนน

2

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

ตัวอย่างเช่นหากคุณต้องการเปลี่ยนชื่อเมธอดหรือคลาสหรือเปลี่ยนจำนวนพารามิเตอร์ที่ใช้เมธอด IDE ของคุณควรมีตัวเลือก refactor เพื่อทำสิ่งนี้ซึ่งจะค้นหาการอ้างอิงที่เหมาะสมทั้งหมดและอัปเดตตาม - แต่อาจชนะ ' ไม่ค้นหาความคิดเห็น

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

— Chris Cooper
แหล่งที่มา

1

มันเป็นเรื่องที่ไม่ดีและคุณควรจะหยุด

เหตุผลที่เดือดลงไปพยายามที่จะทำการปรับโครงสร้างจำนวนมากในครั้งเดียว

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

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

คุณต้องเปลี่ยนวิธีการทำงานของคุณเพื่อที่ว่าถ้าคุณต้องหยุดกลางคันทุกอย่างยังคงทำงาน

ทำตามขั้นตอนทารกแล้วเช็คอินหลังจากนั้น

แยกส่วนต่อประสาน
เขียนทดสอบ
refactor ฟังก์ชั่น

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

หากคุณต้องการติดตามสิ่งที่ต้องทำให้ใช้บอร์ดงานเช่นการต่อสู้หรือเล่น Trello

— Ewan
แหล่งที่มา