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

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

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

สิ่งที่ฉันได้เรียนรู้ (ฉันลองคำสั่งอื่นฉันผิดนี่เป็นลำดับที่สิ่งต่าง ๆ เกี่ยวข้องกัน)

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

2. สร้างพื้นที่ QA / Test ที่แยกจากสภาพแวดล้อม "ทำงาน" หรือ "พัฒนา" ส่วนบุคคลของคุณโดยสิ้นเชิง อย่างน้อย ID ผู้ใช้แยกต่างหาก เป็นการดีที่บน VM ที่แยกต่างหาก
   แยกจากกันโดยสิ้นเชิง ไม่ทับซ้อนกับสภาพแวดล้อมการทำงานปัจจุบันของคุณ

3. หยุดการทดสอบที่นอกเหนือจากการทดสอบหน่วยในสภาพแวดล้อมการทำงานของคุณเอง การทดสอบรหัสและหน่วยการเรียนรู้คุณเป็น "ตัวคุณเอง" การทดสอบอื่น ๆ ทั้งหมด (การรวม, ประสิทธิภาพ, อะไรก็ตาม) ที่คุณทำบน VM แยกต่างหาก อย่าทดสอบด้วยตัวเอง ทดสอบในฐานะผู้ใช้ QA แยกต่างหากเสมอ เป็นการดีที่บน VM ที่แยกต่างหาก

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

4. วางแผนที่จะเขียนทุกอย่าง ใช้เครื่องมือมาร์กอัปข้อความธรรมดา (RST หรือ Markdown หรือบางอย่าง) เพื่อให้เอกสารทั้งหมดเป็นข้อความธรรมดาในที่เก็บการควบคุมเวอร์ชัน เครื่องมือสามารถสร้างหน้า HTML (เช่น Docutils for RST) หรือ PDF หรืออะไรก็ตามที่ดูดีที่สุด อย่าใช้รูปแบบเอกสารที่เป็นกรรมสิทธิ์ (เช่น MS-Word) พวกเขาอาจเล่นได้ไม่ดีกับระบบควบคุมซอร์สโค้ดบางตัว

5. สิ่งแรกที่คุณต้องจดบันทึกมีดังต่อไปนี้

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

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

   • วิธีรันชุดทดสอบการรวมระบบ

   อย่าเสียเวลาอธิบายสถาปัตยกรรมหรือหลักการออกแบบ คุณต้องทำให้ใครบางคนและทำงานก่อน คุณสามารถอธิบายสิ่งต่าง ๆ ในภายหลัง

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

   คุณจะแบ่งปันสิ่งนี้ มันอยู่ภายใต้การควบคุมซอร์สโค้ด

7. ในที่สุดคุณสามารถบันทึก 4 มุมมองอื่น ๆ

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

   • มุมมองกระบวนการมักเป็นประโยชน์ ขึ้นอยู่กับแอปพลิเคชันโดยรวมว่ามีความสำคัญเพียงใด

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

     นอกเหนือจากการยอมรับอย่างไม่เป็นทางการแล้วสิ่งนี้มีแนวโน้มที่จะเปลี่ยนแปลงอย่างรวดเร็ว

   • ข้อมูลการปรับใช้ เซิร์ฟเวอร์ ที่อยู่ IP ฐานข้อมูลรับรอง ทุกสิ่งนั้นจะต้องถูกเขียนลงไป ในที่สุด

เครื่องมือและวิธีการ

อะไรคือสิ่งที่จำเป็นในการทำงานร่วมกันให้ประสบความสำเร็จและมีประสิทธิผล

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

การจัดการ / การทำงานเป็นทีม

... หรือสิ่งอื่นใดในระดับระหว่างบุคคล

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

หนังสืออ้างอิง

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

หนังสือเหล่านี้คุ้มค่าที่จะอ่านเกี่ยวกับทีมองค์กรและโครงการการเขียนโปรแกรม:

• Peopleware
• เดือนคนในตำนาน
• การประมาณค่าซอฟต์แวร์ Demystifying the Black Art

ไม่มีคู่มือเหล่านี้ในทางปฏิบัติเกี่ยวกับวิธีการใช้วิธีการ X (ยกเว้นการประเมินซอฟต์แวร์หนังสือเล่มนี้จะช่วยให้คุณเลือกกระบวนการประมาณค่าที่เหมาะสม) แน่นอนว่าหนังสือที่เน้นการเขียนโปรแกรมเองเช่น Code Complete นั้นมีคุณค่ามากเช่นกัน

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

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

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

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

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

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

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

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

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

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

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

ภารกิจที่สำคัญอื่น ๆ คือเอกสาร @dimitris ที่บันทึกไว้ @S Lott ได้เพิ่มรายละเอียดเพิ่มเติมเกี่ยวกับเรื่องนี้ดังนั้นเพียง +1 ให้กับเขาแทนที่จะทำซ้ำ :-)

นี่คือความคิดบางส่วนขึ้นอยู่กับประสบการณ์ส่วนตัว:

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

• ในตอนแรกให้จดจ่อกับรหัส API- / core-level ด้วยตัวคุณเองในขณะที่ให้พนักงานใหม่ทำงาน "application layer" หรือแก้ไขข้อผิดพลาดเพื่อค่อยๆทำความคุ้นเคยกับรหัสเหล่านั้น โดยทั่วไปเริ่มต้นด้วยง่ายแต่มีความหมายและทำให้รางวัลงาน

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

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

• ใช้ระบบควบคุมการแก้ไข รักษารูปแบบไฟล์ต้นฉบับตรรกะและสร้างวินัย

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

เทคโนโลยี

หากคุณนำคนอื่นมาเป็นนักพัฒนามีสิ่งสำคัญสามอย่างที่ฉันอยากแนะนำให้เริ่มต้นใช้งานก่อนที่จะเริ่ม

1. การควบคุมแหล่งที่มา
2. ติดตามปัญหา
3. บูรณาการอย่างต่อเนื่อง

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

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

Pragmatic Programmer มีหนังสือดี ๆ เกี่ยวกับเรื่องนี้ นี่คือบางส่วนที่ฉันแนะนำ มีชื่อเรื่องอื่นที่คล้ายคลึงกันตามภาษาการเขียนโปรแกรมที่คุณใช้หรือการควบคุมเวอร์ชันที่คุณต้องการใช้:

http://www.pragprog.com/titles/tpp/the-pragmatic-programmer http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git http: //www.pragprog co.th / ชื่อ / รถยนต์ / ปฏิบัติโครงการอัตโนมัติ

ส่วนบุคคล

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

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

ประเด็นเหล่านี้สำคัญที่สุดในความคิดของฉัน:

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

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