จัดการเพื่อนร่วมงานที่ล้าสมัยของฉัน

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

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

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

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

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

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

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

ในทางกลับกันถ้าคุณถูกบังคับให้ออกไปจากเขา

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

ดังนั้นคุณมีสองทางเลือก:

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

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

• นำตัวเองออกcompanyจาก บางครั้งนี่เป็นทางออกเดียว

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

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

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

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

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

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

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

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

ผมเคยเห็นแบบนี้มาก่อน ,

และฉันก็เกือบจะเต็มใจที่จะเดิมพัน: ผู้ชายประเภทนี้จะปรากฏเพียง"เร็ว" เพราะเขามีชุดของ "รูปแบบ" ลองและทดสอบในหัวของเขา 99%ของแอพ Line of Business คือCRUDสิ่งพื้นฐาน

เขาอาจใช้การคัดลอกและวางจำนวนมากจากรหัสที่มีอยู่ของเขาเอง

แต่..

ช่วงเวลาที่เขาพบอะไรที่ซับซ้อนจากระยะไกลมันตกลงไปทำไม? เพราะมันไม่เหมาะกับ "รูปแบบ" พื้นฐานใด ๆ อีกต่อไป

ความท้าทายเล็กน้อย ...

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

จากนั้นให้เขาแสดงโปรเจ็กต์นั้นและขอให้เขาใช้ฟีเจอร์สำหรับฟีเจอร์

ฉันอยากเดิมพันว่าโค้ดของเขาจะใหญ่ขึ้น 10 เท่า & 10 เท่าเมื่อเขานำไปใช้

ดูที่นี่จากด้านธุรกิจ

คุณใช้เวลามากขึ้นในการสร้างรหัสบั๊กเกอร์ คุณสร้างรายได้น้อยลงดังนั้นคุณจึงดูด

หากเมื่อเวลาผ่านไปคุณสามารถย้อนกลับได้แล้วคุณสามารถย้อนกลับได้

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

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

หากผู้จัดการของคุณไม่ใช่โปรแกรมเมอร์ให้ลองใส่ในแง่ที่เขาจะเข้าใจ

• เราควรใช้ sourecontrol เพราะถ้าเราทำไม่ได้เราอาจมีปัญหาใหญ่ในการกู้คืน

• ฉันใช้เวลาxนานกว่านี้เพราะเขาปฏิเสธที่จะทำตามกระบวนการพื้นฐานที่ค่อนข้างเป็นธรรม

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

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

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

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

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

Apathy อาจเป็นผู้ต้องสงสัยอีกรายเพื่อดูว่าเป็นเพราะเหตุใดเขาจึงปฏิเสธบางสิ่งที่ฉันคิดว่าใกล้เคียงกับพื้นฐานในแง่ของวิธีที่ฉันมักจะออกแบบรหัส แต่บางทีฉันอาจมี Kool-aid มากเกินไป

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

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

เกี่ยวกับ OOP ให้เขาดูรูปแบบการออกแบบที่ซับซ้อน / ซับซ้อนเช่นรูปแบบคำสั่งรูปแบบงานและวิธีที่จะช่วยให้เขาประหยัดเวลาอันมีค่าและทีมงานทั้งหมดของคุณ

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

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

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

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

คุณควรขอให้หัวหน้างานของคุณทำการนำเสนอสำหรับทุกคนว่าทำไมซอฟต์แวร์ "รุ่น" จึงดี อย่าทำให้เพื่อนร่วมงานของคุณโสด

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

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