ฉันจะจำสิ่งที่ฉันทำและทำไมในโครงการสามเดือนกลับ?


72

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

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

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


98
แสดงความคิดเห็นและส่งข้อความมีเหตุผลที่ผู้คนบอกให้คุณทิ้งพวกเขา
ratchet freak

5
สิ่งนี้ไม่ได้ขึ้นอยู่กับการติดตามโครงการของคุณตั้งแต่แรกไหม? เราควรสมมติว่าคุณกำลังทำทุกอย่างจากหน่วยความจำและไม่มีเอกสารอื่น ๆ ?
JeffO

4
@ ratchetfreak ฉันกำลังจะพูดว่า "นั่นเป็นเพียงประโยชน์สำหรับนักพัฒนา" จนกว่าฉันจะรู้ว่าคุณสามารถใช้หลักการเดียวกันกับอะไรก็ได้ ที่เก็บเอกสารส่วนใหญ่มีส่วนโน้ตหรือคำอธิบาย การส่งมอบผ่านอีเมลมีเนื้อหาข้อความ (มักจะละเว้น) เอกสารสามารถติดตามการเปลี่ยนแปลงและคำอธิบายประกอบได้ มีความคิดเห็นและการส่งข้อความในระบบ PM ทั่วโลกเช่นกัน! </epiphany>
corsiKa

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

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

คำตอบ:


35

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

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

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

  • ข้อสังเกตเกี่ยวกับคุณภาพของโครงการ

    รหัสนี้สามารถใช้การ refactoring

    ดำเนินการอย่างรวดเร็วเพื่อให้สิ่งนี้ทำงานได้ แต่ABCน่าจะดีกว่า

  • รายการ / ปัญหาสิ่งที่ต้องทำที่คุณไม่ต้องการบันทึกอย่างเป็นทางการในตัวติดตามปัญหา

    "ควรทำให้วิธีนี้ใช้งานได้x < 0แต่อยู่นอกขอบเขต

  • การตัดสินใจออกแบบ - โดยเฉพาะอย่างยิ่งสิ่งที่ไม่สำคัญ

    ฟังก์ชันการเรียงลำดับมาตรฐานของเราทำการเรียงลำดับอย่างรวดเร็ว แต่ไม่ได้รักษาลำดับของรายการเท่ากันภายใต้เงื่อนไขการเรียงลำดับซึ่งเราต้องการที่นี่

    อัลกอริทึมที่ชัดเจนจะเป็นABCแต่ล้มเหลวที่นี่เพราะxอาจเป็นลบดังนั้นเราจึงต้องการรูปแบบทั่วไป ( ลิงก์ Wikipedia )

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

    ตรวจสอบรหัส แต่ให้ข้อผิดพลาด XYZ0123 ปรากฎว่าก่อนอื่นฉันต้องอัพเกรดส่วนประกอบ C เป็นรุ่น 1.2 ขึ้นไป

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

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


68

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

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

แก้ไข :

ฉันควรพูดถึงรายการสิ่งที่ต้องทำ (รายการที่ต้องทำที่ต้องจัดลำดับความสำคัญเป็นพิเศษโดยแยกตามสถานที่และโครงการ) เป็นส่วนสำคัญของหนังสือGetting Things Doneซึ่งฉันพบว่ามีอิทธิพลสูง


22
และถ้าคุณกำลังทำงานกับโปรเจ็กต์เปรียวที่มีงานเล็ก ๆ งานค้างควรเป็นรายการสิ่งที่ต้องทำหลักของคุณสำหรับโครงการนั้น
Bart van Ingen Schenau

1
ฉันเพิ่งเริ่มทำสิ่งที่คุณพูดถึงในวรรคที่แล้วและมันช่วยให้ฉันไปในตอนเช้าได้อย่างหนาแน่น
TMH

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

3
สิ่งที่ต้องทำในโค้ดนั้นยอดเยี่ยม แต่คุณต้องมีความขยันหมั่นเพียรในการวางมันไว้แม้สำหรับสิ่งเล็ก ๆ น้อย ๆ การมีtodoเป้าหมายใน makefile ของคุณที่ทิ้งออกไปนั้นก็มีประโยชน์เช่นกัน
Blrfl

4
trello.comเป็นเครื่องมือช่วยชีวิต แม้แต่การประชุมทีมวันจันทร์มอนริงที่ฉันพยายามจำสิ่งที่ฉันทำเมื่อสัปดาห์ที่แล้วและสิ่งที่ฉันควรทำในสัปดาห์นี้ มันยังฟรี
SimonGates

33

ต้องทำอะไรตอนนี้

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

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

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

วิธีที่จะทำให้สิ่งนี้ดีขึ้นสำหรับตัวคุณเองในอนาคต

ฉันต้องการทราบวิธีจัดทำเอกสารโครงการดังกล่าวทุกครั้งที่ฉันมองย้อนกลับไปฉันไม่ควรใช้เวลาเกินกว่าสองสามนาทีในการเดินทางจากทุกที่ที่ฉันไป!

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

พรุ่งนี้ฉันจะโดนรถบัสและทีมของฉันก็มีไอเดียที่ดีเกี่ยวกับไอเท็มแอคชั่นของฉันมากกว่า 90% นี่เป็นเพราะฉันมีระบบเหนียวสำหรับการบันทึกของฉัน:

  • todos ทันที (รายการ <1 สัปดาห์)
  • "ยินดีที่ได้เป็น" todos
  • เหตุการณ์สำคัญและมาโครโทโกส (กรณีเฉพาะไม่มีความหมาย)
  • บันทึกข้อกำหนด / การประชุม

นอกจากนี้ฉันใช้ VCS และแสดงความคิดเห็นรหัสของฉันตามความเหมาะสม

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

ประเด็นคืออะไร?

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

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


@TheIndicationsAquarius ไม่มีปัญหาดีใจที่มันเป็นประโยชน์ สถานการณ์นั้นสามารถครอบงำได้
enderland

@TheIndyingAquarius อาจเป็นเพราะความคิดเห็นโดยทั่วไปมีจุดประสงค์เพื่อโพสต์ / Stickies ของมันไม่มากก็น้อย วิธีที่ Stack Exchange มีการตั้งค่าที่จะพูดว่า "คำตอบนี้ยอดเยี่ยมมาก" คือการถอนหรือยอมรับคำตอบ ความคิดเห็นที่นี่ไม่จำเป็นต้องมีไว้เพื่อความยั่งยืน
enderland

รายการ "สิ่งที่ต้องทำ" ที่มีความคล่องตัวมากขึ้นคือการใช้ระบบติดตามปัญหา มีระบบฟรีจำนวนมากที่มีอยู่และผู้ให้บริการ Git ฟรีจำนวนมากมีระบบที่ติดตั้งอยู่ในบริการของพวกเขา (ดู: GitHub)
BTownTKD

@BTownTKD ผมบอกว่าในคำตอบของฉัน :)
enderland

มันเป็นคำตอบที่ดี เพิ่มเพื่อเน้น
BTownTKD

14

ในความคิดของฉันมีสองส่วนเพื่อ "กลับมา" โครงการรหัส:

  1. การพิจารณาว่าคุณค้างไว้ที่ไหน
  2. จดจำสิ่งที่คุณต้องทำ

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

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

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

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


10

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

1. ไม่มีงานใดที่เร็วเกินไปหรือเล็กเกินไปที่จะจดบันทึก

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

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

2. ใช้ไวท์บอร์ดที่โต๊ะทำงานของคุณเพื่อรวบรวมแนวคิดภาพใหญ่

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

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

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

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

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

ฉันแนะนำให้คุณใช้เงินเพื่อซื้อไวท์บอร์ดที่ดีอย่างน้อย 3 "x 4" และวางมันไว้ในพื้นที่ที่คุณทำงานปกติ มีข้อดีหลายประการของไวท์บอร์ดแบบฟิสิคัลบนระบบเสมือนใด ๆ

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

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

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

3. ทำให้ผู้มีส่วนได้เสียตระหนักถึงต้นทุนของการขัดจังหวะโครงการ

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

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

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

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

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


ในระยะสั้น:

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

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

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

2

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


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

2

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

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

1

มีคำตอบยาว ๆ มากมาย นี่เป็นสั้น ๆ เกี่ยวกับสิ่งที่ช่วยฉันได้มากที่สุด:

  • รหัสสะอาด
  • รหัสสะอาด
  • รหัสสะอาด
  • การควบคุมเวอร์ชัน (แตกต่างและส่งความคิดเห็น)
  • โพสต์ - อิทโน๊ตหรือ Todo-List หรือ Kanban-Board (ดูเช่น Trello และ Evernote)

อย่างไรก็ตาม Diffs, คอมมิทคอมเม้นท์, โพสต์ - อิท, Todo-Lists หรือ Kanban-Board สามารถตีความผิดเมื่อเวลาผ่านไปเนื่องจากขาดบริบท ดังนั้นนี่คือสิ่งหนึ่งที่สำคัญที่สุด:

รหัสทำความสะอาด


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

@JensG: รหัสเป็นสถาปัตยกรรม ในโปรแกรมที่เขียนได้ดีฉันสามารถเห็นส่วนบนสุดของโปรแกรมสถาปัตยกรรมในฟังก์ชั่นmainซึ่งสำหรับโปรแกรมขนาดใหญ่จะค่อนข้างเป็นนามธรรม ฉันสามารถดำน้ำได้ลึกขึ้นและดูสถาปัตยกรรมของวิธีที่โปรแกรมทำความสะอาดตัวเองตัวอย่างเช่น นอกจากนี้รหัสสะอาดหมายถึงฟังก์ชั่น / ตัวแปร / ฯลฯ มีชื่อที่สมเหตุสมผลและสร้างข้อความเกี่ยวกับความหมายของพวกเขา ถ้าฉันเขียนรหัสปาเก็ตตี้ / เขียนอย่างเดียวแทนฉันมักจะตื่นขึ้นมาในเช้าวัน / เดือน / ปีถัดไปดูรหัสของฉันและความคิดเดียวที่จะเป็น wtf-did-i-do-there มันเหมือนกันเมื่อ ..
phresnel

... การอ่านหรือการเขียนหนังสือ: มันมีความหมายกับดัชนีการอ่านของ Flesch-Kincaid 10 มีวลีขนาดใหญ่คำที่ซับซ้อนมากสร้างให้ผู้อ่านมุ่งเน้นไวยากรณ์แทนความหมายหรือง่ายต่อการอ่าน ด้วยดัชนีประมาณ 80 และดังนั้นจึงไม่ได้เป็นไปในทางของตัวเอง
phresnel

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

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

1

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

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

มีวิธีปฏิบัติที่ดีที่สุดหรือไม่?

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

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

  2. ทำให้เป็นรหัสของคุณเป็นโมดูล (ขึ้นอยู่กับภาษาและสภาพแวดล้อมการเขียนโปรแกรมใช้คลาสโมดูลแพ็คเกจส่วนประกอบ)

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

  4. เพิ่มTODOและFIXMEแสดงความคิดเห็นในขณะที่คุณกำลังเข้ารหัส สิ่งนี้ช่วยในการจดจำ whys และสิ่งที่แปลกประหลาดที่จะเข้าสู่ฐานรหัสของคุณอย่างหลีกเลี่ยงไม่ได้และหลังจากนั้นคุณจะถามWTF หรือไม่! . เช่น:

    //TODO shall actually compute X and return it
    ... some code that does not compute X yet (maybe returns a fixed value instead)
    
    //FIXME make this constant time instead of n^2 as it is now 
    ... some code that works but is not efficient yet
    
  5. สร้างนิสัยในการวาดไดอะแกรมให้กับโครงสร้างเอกสารและพฤติกรรมที่ซับซ้อนเช่นลำดับการโทรระหว่างโมดูล / วัตถุ / ระบบ ฯลฯ โดยส่วนตัวแล้วฉันชอบUMLetเพราะมันใช้งานได้เร็วสร้างกราฟิกที่ดี . แต่แน่นอนคุณควรใช้เครื่องมือวาดรูปที่คุณพบว่าทำงาน โปรดจำไว้ว่าจุดประสงค์ของภาพวาดใด ๆ นั้นเพื่อสื่อสารอย่างกระชับไม่ต้องระบุระบบในรายละเอียดนาที (!!)

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

  7. เพิ่มเอกสารโค้ดภายนอกก่อน เริ่มต้นด้วย README ที่อธิบายถึงการพึ่งพาที่จำเป็นเพื่อเรียกใช้และพัฒนาโครงการวิธีการติดตั้งและวิธีการใช้งาน

  8. ทำให้พฤติกรรมของอัตโนมัติงานซ้ำ เช่นการรวบรวม / สร้าง / ทดสอบรอบควรเขียนสคริปต์โดยบางรูปแบบ (เช่นในการใช้ JavaScript grunt, Python fabric, ใน Java Maven) สิ่งนี้จะช่วยให้คุณเร่งความเร็วได้อย่างรวดเร็วเมื่อคุณกลับมา

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

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


0

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

นั่งลงทำ 'ทดสอบการทำงาน' และเลือกตำแหน่งที่คุณค้าง


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

1
@ หลักฉันไม่ได้พูดกระทำ เพียงแค่ในประเทศ
Pete

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

1
@MainMa next-stepsแล้วกระทำและผลักดันไปยังสาขาที่มีชื่อว่า ฉันไม่แน่ใจว่าสิ่งที่คุณกังวลเกี่ยวกับวิธีการควบคุมการแก้ไขเฉพาะเจาะจงนั้นเกี่ยวข้องกับหลักฐานขั้นพื้นฐานของการทดสอบที่ล้มเหลวเพื่อช่วยในการกระตุ้นสมองของคุณเมื่อกลับมาที่บางสิ่งบางอย่าง อีกครั้งนี้ถูกนำเสนอในนอกจากนี้ยังมีวิธีการมาตรฐานเช่น backlogs, รายการที่ต้องทำ ฯลฯ
พีท

2
@MainMa: การควบคุมเวอร์ชันอาจเหมือนกันมากกับการสำรองข้อมูล แต่นั่นไม่ใช่จุดประสงค์หลัก หากคุณต้องการระบบสำรองข้อมูลและวิธีที่คุณใช้การควบคุมเวอร์ชันป้องกันไม่ให้บรรลุวัตถุประสงค์นั้นให้ใช้ Time Capsule หรือสิ่งที่คล้ายกัน คุณไม่ควรถูกบังคับให้กระทำก่อนกำหนดเพียงเพื่อบังคับให้ VCS ของคุณทำหน้าที่เป็นข้อมูลสำรอง และคุณไม่ควรถูกห้ามมิให้ทำสิ่งใดก็ตามที่เป็นประโยชน์เพราะคุณทำตามนโยบาย "มอบทุกอย่างทันที"
iconoclast

0

นอกจากความคิดเห็น / รายการสิ่งที่ต้องทำ / กระทำมันเป็นสิ่งสำคัญที่จะเป็นจริง

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

ความอดทนเก่าที่ดีจะเป็นประโยชน์

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


0

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

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


นี้ไม่ได้ดูเหมือนจะนำเสนออะไรที่สำคัญกว่าจุดทำและอธิบายในก่อน 11 คำตอบ
ริ้น

0

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

นี่คือบางสิ่งที่ฉันทำใน OneNote ซึ่งช่วยให้ฉันดำเนินการต่อในโครงการ:

  • บันทึกรายวัน / รายสัปดาห์ - เก็บบันทึกความคืบหน้ารายวันหรือรายสัปดาห์เพื่อช่วยให้คุณทราบความคืบหน้าของโครงการที่ทำไปแล้ว

  • รายการสิ่งที่ต้องทำ - ฉันมีรายการสิ่งที่ต้องทำทั่วไป แต่ฉันยังเก็บรายการสิ่งที่ต้องทำแยกต่างหากสำหรับโครงการที่ฉันกำลังทำอยู่เพื่อให้ฉันจำได้ว่าสิ่งที่ฉันยังไม่ได้ทำสำหรับโครงการ บางครั้งฉันก็ออก // TODO: รายการในรหัสของฉัน

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

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


-2

สำหรับโครงการง่ายๆฉันทำสิ่งนี้:

  1. ไฟล์ README ง่าย ๆ ในไดเรกทอรีราก (ซึ่งจะสิ้นสุดลงในการควบคุมเวอร์ชันด้วย) ที่ฉันบันทึกสิ่งที่ปรากฏขึ้นขณะที่กำลังพัฒนา: สิ่งที่ต้องทำข้อบกพร่องการปรับปรุง / แนวคิด นั่นคือไฟล์แรกที่ฉันจะอ่านฉันควรจะใส่โปรเจคลงใน back burner
  2. ความคิดเห็น TODO / FIXME / XXX
  3. ฉันมักจะใช้ ToDoList
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.