การจัดการมาตรฐานการเข้ารหัสในที่ทำงาน (ไม่ใช่เจ้านาย)

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

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

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

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

ขอบคุณทุกท่านที่สละเวลา

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

หมายเหตุ 2:บางคนติดตามสองตัวอย่างที่ฉันให้ไว้ข้างต้น ฉันเป็นมากกว่าหัวใจของเรื่องนี้ มันแสดงให้เห็นตัวเองด้วยตัวอย่างมากมาย: การตั้งชื่อการประชุมฟังก์ชั่นขนาดใหญ่ที่ควรจะแตกสลายบางสิ่งบางอย่างไปใน util หรือบริการบางสิ่งบางอย่างควรจะคงที่หรือฉีดถ้าเราทุกคนใช้รุ่นที่แตกต่างกันของการพึ่งพา อินเทอร์เฟซใช้สำหรับกรณีนี้ควรตั้งค่าการทดสอบหน่วยอย่างไรควรทดสอบหน่วยใด (เฉพาะ Java) เราควรใช้คำอธิบายประกอบหรือการกำหนดค่าภายนอก ฉันสามารถไปต่อ

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

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

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

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

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

นี่คือบิตที่สำคัญเมื่อพยายามส่งเสริมมาตรฐาน: ตรวจสอบให้แน่ใจว่าโฟกัสไม่ได้อยู่ที่การค้นหาวิธีที่ดีที่สุดในการทำสิ่งต่าง ๆ แต่ให้ค้นหาวิธีที่สอดคล้องกันในการทำสิ่งต่าง ๆ มากเท่าที่บางคนอาจไม่เห็นด้วยไม่มีรูปแบบวงเล็บปีกกาที่แท้จริงไม่มีรูปแบบการแสดงความคิดเห็นที่แท้จริง ฯลฯ สิ่งที่ทำให้การอ่านโค้ดง่ายกว่า

คุณสามารถแสดงหลักฐานบางอย่างของเวลาที่คุณเสียไปเนื่องจากปัญหาที่เกิดขึ้นได้หรือไม่?

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

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

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

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

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

เกี่ยวกับมาตรฐานการเข้ารหัส: ฉันจะปีนขึ้นไปบนกระดานกับคนอื่นเกือบทุกคนในการบอกว่ามาตรฐานการเข้ารหัสเป็น "สิ่งที่ดี" (เทียบกับมาตรฐาน)

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

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

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

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

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

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

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

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

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

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

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

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

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

หลีกเลี่ยงการดิ้นรนของอำนาจอย่างแน่นอน ไม่มีอะไรเลวร้ายไปกว่า Hitler ตัวเล็ก ๆ ในทีมของคุณที่พยายามบังคับให้ทุกคนทำตามความต้องการของเขา และน่าเสียดายที่คนที่จะอาสาเขียนมาตรฐานการเข้ารหัสของคุณ :-(

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

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

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

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

ข้อขัดแย้งเมื่อฉันรวมเพราะมีคนใช้ IDE ของพวกเขาเพื่อจัดรูปแบบอัตโนมัติและพวกเขาใช้อักขระที่แตกต่างเพื่อเยื้องกว่าที่ฉันทำ

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

ทางเลือกคือใส่ฟอร์แมตเตอร์ล่วงหน้าที่จะฟอร์แมตโค้ดทั้งหมดเป็นสไตล์มาตรฐานอีกครั้งก่อนเช็คอิน หากคุณมีทีม devs ที่จัดรูปแบบเป็นเรื่องใหม่แน่นอนนี่เป็นตัวเลือกที่ดี - SCM จะเห็นรูปแบบเดียวกันเสมอดังนั้น deltas จะเล็กและรวมเข้าด้วยกัน

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

จากปัญหาเฉพาะของคุณทางออกที่ดีที่สุดของคุณอาจเริ่มจากคำแนะนำของ Joel และนำโดยตัวอย่าง รวบรวมโปรแกรมเมอร์ 1 หรือ 2 คนที่สนใจเรื่องนี้รับข้อตกลงและคุณจะมีอำนาจที่จะกำหนดคนขี้เกียจ

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

อย่าลองสิ่งนี้!

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

หากคุณไม่ได้รับการติดต่อจากเพื่อนร่วมงาน (!!) คุณอาจต้องจบด้วยรหัสมาตรฐาน

เห็นได้ชัดว่านี่เป็นกลยุทธ์ที่มีความเสี่ยงสูง ... :-)