สร้างแรงบันดาลใจให้เพื่อนร่วมงานนำวิธีการเข้ารหัสที่ดีกว่า

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

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

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

อย่างไรก็ตามรหัส (C #) จริงที่ฉันเคยเห็นคือการย้อนกลับไปสู่ ​​VB6 วัน โครงสร้างขั้นตอน, สัญกรณ์ฮังการี, ตัวแปรทั่วโลก (การละเมิดstatic), ไม่มีส่วนต่อประสาน, ไม่มีการทดสอบ, การไม่ใช้ Generics, การขว้างSystem.Exception... คุณจะได้รับแนวคิด

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

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

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

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

ชี้แจง:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

หากเขาไม่สนใจหลังจากนั้นคุณสามารถอ้างถึงคำถามแรกที่คุณเชื่อมโยง

มันเป็นหน้าที่ของผู้จัดการของคุณจริงๆ

1. ตระหนักดีว่า บริษัทต้องมีมาตรฐานการเข้ารหัส บริษัท มืออาชีพทุก ๆ แห่งมีขนาดนี้
2. พาทุกคนมานั่งด้วยกันแล้วเริ่มสร้างมาตรฐาน ด้วยวิธีนี้ทุกคนสามารถพูดได้และจากนั้นพวกเขาจะมีแรงจูงใจที่จะทำตามมาตรฐานมากขึ้น

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

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

สำหรับการอ้างอิงตรวจสอบวิธีการเขียนมาตรฐาน MISRA-C / C ++ และ CERT C / C ++ / Java

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

อย่างไรก็ตามหากมีเหตุผลทางเทคนิคคุณควรพิจารณาเข้าหาบุคคลดังกล่าวด้วยบางสิ่งเช่น:

ฉันมีข้อเสนอแนะสำหรับวิธีที่คุณสามารถประหยัดเวลาที่น่าเบื่อสำหรับคุณและเงินสำหรับ บริษัท คุณสนใจไหม?

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

แม้ว่าคุณจะมี gazillions ของข้อเสนอแนะเพียงแค่เลือกหนึ่งหรือสองและแสดงให้เห็นว่ามันจะเป็นการเปลี่ยนแปลงที่ดีกว่า

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

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

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

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

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

หากบุคคลนี้มีความรู้เกี่ยวกับโดเมนที่คุณต้องการ / ต้องการให้พวกเขามีเอกสารความรู้นั้น

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

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

ทรัพยากรอย่างรวดเร็วในข้อเสนอแนะสามารถเช่นถูกพบในhttp://managementhelp.org/communicationsskills/feedback.htm (แม้ว่าจะมี plethoria ของชนิดของสิ่งนี้ในเว็บ)

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

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

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

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

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

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

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

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

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

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

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

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

Chain of Command เป็นวิธีที่ปลอดภัยที่สุดที่จะไปเพราะเขาได้ฟังเจ้านายของเขาและไม่ต้องชอบเขา ให้เจ้านายเป็นคนเลวนั่นคือสิ่งที่เขามีอยู่

หากคุณไม่สามารถขายเจ้านายได้หรือเขาเป็นหัวหน้าคุณก็จัดการกับข้อบกพร่องของเขาได้ แต่นำตัวอย่างในรหัสของคุณ

คุณทำไม่ได้

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

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