อะไรคือความรับผิดชอบโดยทั่วไปของนักพัฒนา Java? ท้ายที่สุดคุณต้องเข้าใจว่าคุณกำลังทำอะไรและสิ่งที่คุณจะทำใช่ไหม? วันนี้ฉันอยากจะพูดถึงงานที่สำคัญสิบประการที่นักพัฒนา Java ดำเนินการ ![งานทั่วไปของนักพัฒนา Java ในโครงการ - 1]()
แต่ก่อนอื่นเรามาทำความรู้จักกับเครื่องมือที่เรียกว่าจิรา หรือรีเฟรชความทรงจำของคุณหากคุณคุ้นเคยกับมันแล้ว จิระเป็นเครื่องมือสำหรับการจัดระเบียบปฏิสัมพันธ์ของมนุษย์ แม้ว่าในบางกรณีจะใช้สำหรับการจัดการโครงการด้วย กล่าวอีกนัยหนึ่ง โปรเจ็กต์ถูกแบ่งออกเป็นงานเล็กๆ ที่อธิบายไว้ในเครื่องมือนี้ งานเหล่านี้ถูกกำหนดให้กับนักพัฒนาซึ่งมีหน้าที่รับผิดชอบในการนำไปใช้งาน ตัวอย่างเช่นงานอาจเป็นการเพิ่มฟังก์ชันการทำงานบางอย่าง เมื่อทำงานเสร็จ นักพัฒนาซอฟต์แวร์และผู้เชี่ยวชาญคนอื่นๆ จะเพิ่มความคิดเห็นว่าใครทำอะไรและใช้เวลาเท่าไร สิ่งนี้ทำขึ้นเพื่อจุดประสงค์ในการติดตามเวลา - เพื่อทราบว่าใช้เวลาเท่าไรกับงานใดบ้าง ตามหลักการแล้ว ควรทำเช่นนี้วันละครั้ง ก่อนที่คุณจะลุกจากโต๊ะทำงานในตอนเย็น ให้คุณระบุเวลาทำงาน 8 ชั่วโมงที่คุณใช้ไปกับงานต่างๆ ฟังก์ชันการทำงานของ Jira มีมากกว่าที่อธิบายไว้ข้างต้น แต่นี่จะเพียงพอสำหรับการทำความเข้าใจเบื้องต้น
![Java webinar]()
![งานทั่วไปของนักพัฒนา Java ในโครงการ - 2]()
ยิ่งนักพัฒนามีตำแหน่งสูงเท่าไร เธอก็ยิ่งต้องใช้เวลาในการสื่อสารมากขึ้นและใช้เวลาเขียนโค้ดน้อยลงเท่านั้น หัวหน้าฝ่ายพัฒนาอาจใช้เวลาครึ่งหนึ่งหรือมากกว่านั้นของวันทำงานในการสนทนาและการประชุมเพียงลำพัง และอาจเขียนโค้ดน้อยลง (อาจทำให้เขาสูญเสียความสามารถในการเขียนโค้ดไปเล็กน้อย) แต่ถ้าคุณรักการพูดคุย ในฐานะหัวหน้าทีม คุณสามารถเปลี่ยนไปเป็นผู้บริหารและลืมเรื่องการเขียนโค้ดไปได้เลย คุณจะใช้เวลาทั้งวันในการสื่อสารกับทีมต่างๆ ลูกค้า และผู้จัดการคนอื่นๆ
![Java university]()
แต่ก่อนอื่นเรามาทำความรู้จักกับเครื่องมือที่เรียกว่าจิรา หรือรีเฟรชความทรงจำของคุณหากคุณคุ้นเคยกับมันแล้ว จิระเป็นเครื่องมือสำหรับการจัดระเบียบปฏิสัมพันธ์ของมนุษย์ แม้ว่าในบางกรณีจะใช้สำหรับการจัดการโครงการด้วย กล่าวอีกนัยหนึ่ง โปรเจ็กต์ถูกแบ่งออกเป็นงานเล็กๆ ที่อธิบายไว้ในเครื่องมือนี้ งานเหล่านี้ถูกกำหนดให้กับนักพัฒนาซึ่งมีหน้าที่รับผิดชอบในการนำไปใช้งาน ตัวอย่างเช่นงานอาจเป็นการเพิ่มฟังก์ชันการทำงานบางอย่าง เมื่อทำงานเสร็จ นักพัฒนาซอฟต์แวร์และผู้เชี่ยวชาญคนอื่นๆ จะเพิ่มความคิดเห็นว่าใครทำอะไรและใช้เวลาเท่าไร สิ่งนี้ทำขึ้นเพื่อจุดประสงค์ในการติดตามเวลา - เพื่อทราบว่าใช้เวลาเท่าไรกับงานใดบ้าง ตามหลักการแล้ว ควรทำเช่นนี้วันละครั้ง ก่อนที่คุณจะลุกจากโต๊ะทำงานในตอนเย็น ให้คุณระบุเวลาทำงาน 8 ชั่วโมงที่คุณใช้ไปกับงานต่างๆ ฟังก์ชันการทำงานของ Jira มีมากกว่าที่อธิบายไว้ข้างต้น แต่นี่จะเพียงพอสำหรับการทำความเข้าใจเบื้องต้น
1. ออกแบบโซลูชั่นใหม่ๆ
ก่อนที่คุณจะสร้างและใช้งานบางอย่าง คุณต้องกำหนดแนวคิดก่อนใช่ไหม อย่างที่ฉันพูดไปก่อนหน้านี้ นี่อาจเป็นงานใน Jira ที่มอบหมายให้คุณ ดังนั้นคุณจึงทำงานเพื่อออกแบบโซลูชันใหม่ โดยบันทึกใน Jira ว่าคุณใช้เวลาไปเท่าไรและทำอะไร งานนี้อาจเกิดขึ้นระหว่างการสนทนาในการประชุมทางโทรศัพท์ของทีม: ทุกคนสามารถแสดงความคิดเห็นและเสนอแนวทางที่พวกเขาคิดว่าดีที่สุด และที่นี่ฉันต้องการทราบบางจุด ประการแรก การพัฒนาซอฟต์แวร์เป็นอาชีพที่สร้างสรรค์มาก เนื่องจากคุณจำเป็นต้องใช้เครื่องมือมาตรฐานเพื่อหาวิธีใหม่ๆ ในการแก้ปัญหา หนึ่งงานมักจะมีวิธีแก้ปัญหาที่แตกต่างกันมากมาย ดังนั้นทุกอย่างขึ้นอยู่กับความคิดสร้างสรรค์ของนักพัฒนาซึ่งได้รับอิทธิพลอย่างมากจากความรู้และประสบการณ์ที่สั่งสมมา คุณสามารถแสดงความคิดสร้างสรรค์และอัจฉริยะทั้งหมดของคุณได้ที่นี่ แต่สิ่งสำคัญคืออย่าหักโหมจนเกินไป หากคุณทำเช่นนั้น โค้ดจะซับซ้อนเกินไปและอ่านไม่ออก ดังนั้น หลังจากที่คุณจากไป จะไม่มีใครเข้าใจสิ่งที่คุณเขียนและวิธีการทำงานของมันอย่างถ่องแท้ และพวกเขาจะต้องเขียนใหม่ทั้งหมดตั้งแต่เริ่มต้น และพวกเขาอาจนึกถึงคุณ มากกว่าหนึ่งครั้ง. และไม่น่าเป็นไปได้ที่จะมีคำพูดที่อบอุ่นและใจดี คุณต้องการที่? ประการที่สอง นักพัฒนาซอฟต์แวร์ต้องรักษาความยืดหยุ่นทางจิตวิทยาในแง่ที่ว่า คุณไม่ควรยึดติดกับโซลูชันเดียวและปิดใจผู้อื่น ราวกับว่าคุณต้องทำอะไรเพียงทางเดียวและไม่มีทางเลือกอื่น คุณอาจตกหลุมพรางนี้ด้วยเหตุผลหลายประการ ตัวอย่างเช่น สมมติว่าคุณต้องการพิสูจน์ว่ามุมมองของคุณถูกต้อง หรือบางทีคุณอาจออกแบบและนำโซลูชันที่คุณคุ้นเคยไปใช้แล้ว — แน่นอนว่า คุณไม่อยากยอมรับว่ามันไม่ดีที่สุด สถานการณ์เหล่านี้อาจทำให้คุณตาบอดได้ ในความเป็นจริง คุณต้องสามารถยอมรับข้อผิดพลาดของคุณและเปิดใจอยู่เสมอ แม้ว่าคุณจะต้องลบฟังก์ชันการทำงานที่คุณภาคภูมิใจและเขียนโค้ดมากว่าหนึ่งสัปดาห์ออกไปก็ตาม ฉันจำได้ว่าเพื่อนร่วมงานคนหนึ่งทำให้วันของทุกคนสดใสขึ้นด้วยการแสดงความคิดเห็นติดตามเวลานี้ใน Jira: "ฉันถอดอวัยวะที่ตายแล้วออก และโศกเศร้า"
2. การเขียนฟังก์ชันใหม่
ขั้นตอนนี้ - การใช้ฟังก์ชันใหม่ - ดำเนินการตามหลังขั้นตอนก่อนหน้าอย่างมีเหตุผล งานทั้งหมดที่เกี่ยวข้องในโครงการจะแบ่งออกเป็นงานใน Jira ซึ่งจะถูกแจกจ่ายให้กับนักพัฒนาตามปริมาณงานของพวกเขา มีแนวทางที่แตกต่างกันสำหรับกระบวนการนี้ ซึ่งเรียกว่า "วิธีการ" ซึ่งคุณสามารถอ่านรายละเอียดเพิ่มเติมได้ในบทความเกี่ยวกับ CodeGym นี้ ตามกฎแล้วงานจะมีการประมาณการซึ่งเป็นเวลาที่คาดการณ์ไว้เพื่อดำเนินการให้เสร็จสิ้น ซึ่งถูกกำหนดโดยคุณ ผู้พัฒนา เมื่อคุณได้รับงาน หรือโดยหัวหน้าทีม หรือระหว่างการวางแผน โดยทีมพัฒนาร่วมกัน การเดาในครั้งนี้ไม่ค่อยแม่นยำนัก เนื่องจากปัจจัยต่างๆ มากมายส่งผลต่อการพัฒนาซอฟต์แวร์ ตัวอย่างเช่น ไม่ว่าโปรแกรมเมอร์จะคุ้นเคยหรือไม่คุ้นเคยกับเทคโนโลยีที่เกี่ยวข้อง ประสบการณ์โดยรวมของเขาหรือเธอ หลุมพรางที่คาดไม่ถึงต่างๆ ฯลฯ ดังนั้น หากคุณไม่ใช้เวลาทั้งหมดที่คุณคาดไว้ตอนเขียนโค้ด นั่นไม่ใช่จุดจบของโลก นี่เป็นเพียงการประมาณการทั่วไป ที่กล่าวว่าไม่มีทุกโครงการที่ต้องการการประมาณเวลา โดยส่วนตัวแล้ว ฉันคิดว่าการใช้ชีวิตโดยปราศจากนาฬิกานั้นง่ายกว่ามาก โดยเฉพาะอย่างยิ่งเมื่อนายกรัฐมนตรีไม่รบกวนฉันวันละสองสามครั้งด้วยคำถาม "เวลาของคุณประมาณการไว้ที่ไหน" ดังนั้น คุณได้รับงานพร้อมสำหรับการตรวจสอบ " ใน Jira และอธิษฐานว่าการเปลี่ยนแปลงรหัสของคุณจะไม่ถูกส่งกลับสำหรับการแก้ไขพร้อมกับความคิดเห็น3. การทดสอบการเขียน
ผู้ตรวจสอบคือผู้ที่ตรวจสอบโค้ดของคุณ ชอบฟังก์ชันการทำงานที่คุณนำมาใช้ แต่เธอมีคำถามสำหรับคุณ: การทดสอบที่เกี่ยวข้องอยู่ที่ไหน ดังนั้นเธอจึงส่งงานกลับมาให้คุณแก้ไข การทดสอบเป็นส่วนสำคัญของแอปพลิเคชัน Java เมื่อเรียกใช้การทดสอบ คุณสามารถระบุตำแหน่งที่แอปพลิเคชันทำงานไม่ถูกต้องได้ทันที ตัวอย่างเช่น นักพัฒนาทำการเปลี่ยนแปลงบางอย่างในส่วนหนึ่งของระบบ ซึ่งส่งผลให้พฤติกรรมในอีกส่วนหนึ่งเปลี่ยนไป แต่เขาไม่ได้สังเกตเห็นสิ่งนี้ขณะเขียนโค้ด เมื่อเรียกใช้การทดสอบ เขาจะสามารถเห็นได้ว่าการทดสอบบางอย่างล้มเหลว หมายความว่าการทดสอบเหล่านั้นไม่ได้ผลลัพธ์ตามที่คาดไว้ สิ่งนี้บอกเขาว่ามีบางอย่างเสียที่อื่นในระบบ เมื่อทราบสิ่งนี้ เขาจะไม่กระทำการเปลี่ยนแปลงที่มีผลกับเซิร์ฟเวอร์ และจะดำเนินการแก้ไขข้อบกพร่องโค้ดของเขาต่อไปแทน ใช่, นักพัฒนาค่อนข้างน้อยที่ชอบการทดสอบการเขียน แต่ก็ไม่มีการปฏิเสธถึงประโยชน์ที่พวกเขานำมาสู่การพัฒนาซอฟต์แวร์ ลูกค้าเองมักจะระบุระดับความครอบคลุมการทดสอบที่พวกเขาต้องการรักษาไว้ (เช่น 80%) นั่นหมายความว่าคุณต้องรู้แบบทดสอบประเภทต่าง ๆและสามารถเขียนได้ นักพัฒนา Java ส่วนใหญ่เขียนการทดสอบหน่วยและการทดสอบการรวม ในขณะที่การทดสอบที่ครอบคลุมมากขึ้น (ตั้งแต่ต้นจนจบ) จะจัดการโดย QA และผู้เชี่ยวชาญด้านการทดสอบอัตโนมัติ4. ค้นหาและแก้ไขจุดบกพร่อง
นี่เป็นงานทั่วไปและบ่อยครั้งสำหรับนักพัฒนา Java งานหลักของผู้เชี่ยวชาญด้าน QA และทดสอบระบบอัตโนมัติคือตรวจจับจุดบกพร่อง กล่าวอีกนัยหนึ่ง พวกเขามองหาตำแหน่งที่โปรแกรมทำงานไม่ถูกต้อง จากนั้นจึงสร้างงานใน Jira และมอบหมายงานให้กับใครบางคน ตัวอย่างเช่น สำหรับหัวหน้าทีม ผู้ซึ่งเป็นผู้ตัดสินใจว่าจะมอบหมายให้นักพัฒนารายใด โดยขึ้นอยู่กับภาระงานและความคุ้นเคยกับส่วนที่เกี่ยวข้องของระบบ หลังจากนั้น นักพัฒนาที่ได้รับมอบหมายจะค้นหาสาเหตุของข้อผิดพลาด โดยใช้เวลาหลายชั่วโมงในการดีบั๊กโดยใช้คำอธิบายจุดบกพร่องที่ผู้เชี่ยวชาญ QA ให้มาเพื่อสร้างเงื่อนไขที่เกิดจุดบกพร่องขึ้นใหม่ เมื่อผู้พัฒนาพบจุดบกพร่องและทำการแก้ไขแล้ว เขาก็จะส่งการแก้ไขไปตรวจสอบ บางครั้งผู้พัฒนาไม่สามารถสร้างจุดบกพร่องซ้ำได้ ดังนั้นเขาจึงส่งงานกลับไปยังผู้เชี่ยวชาญ QA พร้อมกับคำอธิบายอธิบาย ดูเหมือนว่าจะใช้เวลาไม่นานนักในการค้นหาและแก้ไขจุดบกพร่อง แต่ก็มีความแตกต่างบางประการ ทุกอย่างส่วนใหญ่ขึ้นอยู่กับความคุ้นเคยกับส่วนนี้ของโค้ดของนักพัฒนาเป็นอย่างดีเพียงใด ตลอดจนประสบการณ์และความรู้ทางทฤษฎีของเขา บางครั้งสามารถพบข้อบกพร่องและแก้ไขได้ภายใน 20 นาที และบางครั้งอาจใช้เวลาสามวัน ซึ่งหมายความว่างานประเภทนี้จะประเมินล่วงหน้าได้ยากเป็นพิเศษ เว้นแต่นักพัฒนาซอฟต์แวร์จะเข้าใจได้ทันทีว่าข้อผิดพลาดคืออะไร ที่ไหน และอย่างไร เมื่ออ่านคำอธิบายแล้ว ในกรณีนี้,5. ตรวจสอบโค้ด
ตามที่กล่าวไว้ข้างต้น ทันทีที่คุณทำงานเสร็จ ควรส่งไปตรวจสอบ หากผ่านการตรวจสอบก็จะเข้าสู่สาขาหลัก หากไม่เป็นเช่นนั้น จะถูกส่งกลับไปยังนักพัฒนาพร้อมกับความคิดเห็นที่ต้องแก้ไข แน่นอน คุณเข้าใจดีว่ารหัสของคุณทั้งหมดถูกตรวจสอบโดยเพื่อนนักพัฒนา ไม่ใช่โดยพลังงานสูง ที่กล่าวว่า ไม่ใช่ทุกคนที่ได้รับอนุญาตให้ทำการตรวจสอบโค้ด — มีเพียงนักพัฒนาที่มีประสบการณ์มากที่สุดเท่านั้นที่ฝึกฝนในโลกแห่งความเป็นจริงให้แข็งกระด้าง ผู้ที่สามารถบอกความแตกต่างระหว่างโค้ดที่ดีและโค้ดที่ไม่ดีได้ การตรวจสอบโค้ดมักดำเนินการโดยใช้เครื่องมือช่วยเหลือ เช่นCrucible. ผู้ตรวจสอบอ่านรหัสและหากจำเป็นให้แสดงความคิดเห็นเกี่ยวกับบางบรรทัด สามารถแสดงความคิดเห็นได้หลากหลายประเภท ตัวอย่างเช่น บางคนมีความสำคัญ หากไม่ได้รับการแก้ไข ผู้ตรวจสอบจะไม่อนุญาตให้มีการส่งรหัส ความคิดเห็นอื่นๆ พูดง่ายๆ ก็คือ ข้อสังเกตเกี่ยวกับแนวทางที่เลือก สิ่งเหล่านี้ผู้พัฒนาสามารถฟัง จด หรือเพิกเฉยได้ ทีมสามารถสร้างกฎและขั้นตอนของตนเองสำหรับการตรวจสอบโค้ด การตกลงว่าอะไรควรค่าแก่การเอาใจใส่และสิ่งใดไม่ควร ควรกำหนดกรอบเวลาใดสำหรับการตรวจสอบโค้ดให้เสร็จสิ้น ฯลฯ ประสบการณ์เพียงอย่างเดียวไม่เพียงพอที่จะดำเนินการตรวจสอบ: คุณยังคง จำเป็นต้องพัฒนาทักษะทางเทคนิคให้มาก และอ่านหนังสือหลายเล่ม (เช่น "Clean Code")6. การวิเคราะห์รหัส
เนื่องจากมีคนหลายคนที่คิดต่างกันเขียนโค้ดสำหรับโครงการพร้อมกัน โค้ดและแนวทางของพวกเขาจะแตกต่างกัน และเมื่อเวลาผ่านไป ทุกอย่างก็ค่อยๆ กลายเป็นความยุ่งเหยิง ในการปรับปรุงโค้ด บางครั้งงานจะถูกสร้างขึ้นเพื่อ เช่น วิเคราะห์โมดูลหรือแอปพลิเคชันทั้งหมด ค้นหาและจดบันทึกข้อบกพร่อง และสร้างงานการปรับโครงสร้างใหม่ตามการวิเคราะห์นี้ในภายหลัง การวิเคราะห์ดังกล่าวยังช่วยในสถานการณ์ที่เมื่อการพัฒนาเริ่มต้นขึ้น ทีมมองไม่เห็นโซลูชันที่ง่ายกว่าและรัดกุมกว่านี้ แต่พวกเขามองเห็นแล้วในตอนนี้ ตัวอย่างเช่น ตรรกะมักจะซ้ำกันในบางวิธี ดังนั้นจึงสามารถสกัดด้วยวิธีที่แยกจากกันซึ่งสามารถนำกลับมาใช้ใหม่ได้หลายครั้ง หรือบางทีคลาสอาจเยอะเกินไป หรือบางโค้ดก็ดูแลรักษายากหรือล้าสมัย หรือ... งานวิเคราะห์ช่วยปรับปรุงคุณภาพของโค้ดและแอปพลิเคชัน สำหรับฉันแล้ว การวิเคราะห์โค้ดจำนวนมากอาจเป็นเรื่องที่น่าเบื่อ7. การปรับโครงสร้างโค้ด
ส่วนต่อไปของการวิเคราะห์โค้ดคือการปรับโครงสร้างใหม่ โค้ดอาจล้าสมัย ล้าสมัย เขียนไม่ดี อ่านยาก และอื่นๆ คุณควรพยายามเพื่อความสมบูรณ์แบบอยู่เสมอ (แม้ว่าจะไม่มีอยู่จริงก็ตาม) และสำหรับโค้ดที่เป็นปัจจุบัน ให้ลบสิ่งที่ไม่จำเป็นออก เพราะสิ่งที่ไม่จำเป็นจะนำไปสู่ความสับสนและขัดขวางความสามารถในการดูว่าโค้ดกำลังทำอะไรอยู่ ไม่ต้องบอกว่าคุณไม่น่าจะเห็นงานเหล่านี้ในตอนเริ่มต้นของโปรเจกต์: คุณเจองานเหล่านี้ในขั้นตอนต่อมาของการพัฒนาเมื่อแอปพลิเคชันได้รับการขัดเกลาและนำไปสู่ความสมบูรณ์แบบ ที่นี่ อาจเป็นการเหมาะสมที่จะปรึกษากับเพื่อนร่วมงานเกี่ยวกับสิ่งที่พวกเขาจะทำและสิ่งที่พวกเขาเห็นข้อผิดพลาด หัวใจของพวกเขาคืองานดังกล่าวคล้ายกับการพัฒนาฟังก์ชันใหม่ ตัวอย่างเช่น สมมติว่าคุณได้รับงานให้แก้ไขฟังก์ชันบางอย่างโดยไม่เปลี่ยนลักษณะการทำงาน ในการทำเช่นนี้ คุณต้องลบโค้ดเก่า เขียนโค้ดของคุณเอง และตรวจสอบการทดสอบ หากคุณทำทุกอย่างถูกต้องโดยไม่ต้องทำการเปลี่ยนแปลงใด ๆ การทดสอบทั้งหมดควรผ่านเหมือนก่อน หลังจากทุกอย่างในโค้ดเป็นไปตามที่ควรจะเป็น เราก็ส่งไปตรวจสอบและไปจิบกาแฟกัน :)8. การเขียนเอกสาร
ลองจินตนาการว่าคุณเป็นนักพัฒนาใหม่ในโครงการพัฒนาซอฟต์แวร์ระยะยาว คุณต้องทำความคุ้นเคยกับฐานโค้ดหรือดำเนินการบางอย่าง เช่น วินิจฉัยจุดบกพร่อง คุณจะสำรวจโครงการอย่างไร รบกวนเพื่อนร่วมทีมของคุณทุก ๆ ห้านาที? แล้วถ้าพวกเขายุ่งหรือเป็นวันหยุดสุดสัปดาห์ล่ะ? นี่คือเหตุผลที่เรามีเอกสารประกอบ — เพื่อให้ผู้ที่ไม่คุ้นเคยกับโค้ดสามารถเข้ามา ค้นหาหน้าที่เกี่ยวข้อง และค้นหาได้อย่างรวดเร็วว่าเกิดอะไรขึ้นในส่วนของแอปพลิเคชันที่เธอสนใจ แต่ต้องมีคนทำเอกสารนะ 555 หากโครงการมีเอกสารประกอบที่นักพัฒนาต้องสนับสนุน เมื่อพวกเขานำฟังก์ชันการทำงานใหม่ไปใช้ พวกเขาจะอธิบายและอัปเดตเอกสารพร้อมกับการเปลี่ยนแปลงโค้ดหรือการปรับโครงสร้างใหม่ คุณยังสามารถมีสถานการณ์ที่จ้างพนักงานแยกต่างหาก — นักเขียนด้านเทคนิค — เพื่อเขียน บำรุงรักษา และดูแลเอกสาร หากมีผู้เชี่ยวชาญดังกล่าว ชีวิตของนักพัฒนาทั่วไปจะง่ายขึ้นเล็กน้อย9. การประชุมต่างๆ
เวลาส่วนใหญ่ของนักพัฒนาหมดไปกับการประชุม การเจรจา และการวางแผนต่างๆ ตัวอย่างที่ง่ายที่สุดคือการประชุมเดี่ยวประจำวัน ซึ่งคุณต้องรายงานสิ่งที่คุณทำเมื่อวานและสิ่งที่คุณกำลังจะทำในวันนี้ นอกจากนี้ คุณจะต้องมีการติดต่อทางโทรศัพท์แบบตัวต่อตัว เช่น กับผู้ทดสอบ เพื่อให้พวกเขาสามารถสาธิต/อธิบายถึงความแตกต่างของการทำให้เกิดข้อผิดพลาด หรือหารือเกี่ยวกับรายละเอียดปลีกย่อยและข้อกำหนดกับนักวิเคราะห์ธุรกิจ หรือพูดคุยเกี่ยวกับปัญหาขององค์กร กับ PM ซึ่งหมายความว่าแม้ว่านักพัฒนาอาจเป็นคนเก็บตัวที่ชอบความสันโดษ แต่เธอก็ยังต้องหาจุดร่วมกับผู้อื่นได้ (อย่างน้อยก็เล็กน้อย)
ยิ่งนักพัฒนามีตำแหน่งสูงเท่าไร เธอก็ยิ่งต้องใช้เวลาในการสื่อสารมากขึ้นและใช้เวลาเขียนโค้ดน้อยลงเท่านั้น หัวหน้าฝ่ายพัฒนาอาจใช้เวลาครึ่งหนึ่งหรือมากกว่านั้นของวันทำงานในการสนทนาและการประชุมเพียงลำพัง และอาจเขียนโค้ดน้อยลง (อาจทำให้เขาสูญเสียความสามารถในการเขียนโค้ดไปเล็กน้อย) แต่ถ้าคุณรักการพูดคุย ในฐานะหัวหน้าทีม คุณสามารถเปลี่ยนไปเป็นผู้บริหารและลืมเรื่องการเขียนโค้ดไปได้เลย คุณจะใช้เวลาทั้งวันในการสื่อสารกับทีมต่างๆ ลูกค้า และผู้จัดการคนอื่นๆ
GO TO FULL VERSION