จัดการกับเพื่อนร่วมงานที่ไม่มีรูปแบบการเข้ารหัสที่สอดคล้องกันหรือไม่

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

• ส่วนผสมของอนุสัญญาการตั้งชื่อและชื่อที่แตกต่างกัน ( underscore_styleและcamelCaseและUpperCamelและCAPSทั้งหมดใช้มากหรือน้อยโดยการสุ่มกับตัวแปรต่าง ๆ ในฟังก์ชั่นเดียวกัน)
• ระยะห่างที่แปลกประหลาดและไม่สอดคล้องกันเช่น Functioncall (arg1 ,arg2,arg3 );
• คำที่สะกดผิดจำนวนมากในความคิดเห็นและชื่อตัวแปร

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

คุณจะสนับสนุนให้บุคคลนี้ระมัดระวังและสอดคล้องกับรายละเอียดเหล่านี้มากขึ้นอย่างไร

เห็นด้วยกับข้อตกลงการเข้ารหัส

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

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

ฉันคิดว่าถ้าคุณแก้ไขสิ่งเหล่านี้ด้วยตัวเองอย่างที่ NimChimpsky แนะนำคุณจะต้องทำความสะอาดหลังจากบุคคลนี้ไปตลอดกาล

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

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

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

ฉันจะเปลี่ยนมันเองแล้วเพิ่มความคิดเห็นสุภาพในรหัส

นี่ถือว่ามีแนวทางสไตล์อยู่แล้วตามคำถามที่ระบุไว้:

เรามีระบบตรวจสอบรหัสที่ดี

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

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

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

โปรดทราบว่าฉันไม่ได้สนับสนุนการเขียนโค้ดสปาเก็ตตี้ / โคบาลที่นี่ในความเป็นจริงฉันได้เห็นโค้ดสปาเก็ตตี้ที่จัดรูปแบบเป็นอย่างดีบางส่วน (ฟังก์ชั่นที่ประกอบไปด้วยหน้าจอ 4-5 หน้าตัวแปรทั่วโลกกระจัดกระจาย ฯลฯ )

หนึ่งในเพื่อนร่วมงานของฉันเขียน html ในลักษณะที่ทำให้การตระเวนผิวหนังของฉัน ลองนึกภาพ html ของฉันที่ดีและมีโครงสร้างด้วยการเยื้องสองช่องว่างเจาะเป็นชิ้น ๆ ด้วยแท็กที่เพิ่มเข้าไปที่ส่วนท้ายของฉันซึ่งจบในบรรทัดเดียวกันหรือถัดไปเช่นเมาบางคนที่ต้องการเหวี่ยงแขนของคุณให้ยืนนิ่ง ๆ มีการเยื้องบรรทัดใหม่ไม่ค่อยมาก แต่ถ้าเป็นเช่นนั้นฉันแน่ใจว่ามีบางหลุมดำที่มีความวุ่นวายสูงในบางส่วนของกาแลคซีที่กระจายค่าอุณหภูมิที่ไม่ลงตัวในแบบที่ตัวเลขของมันสะท้อนจำนวนช่องว่างหรือแท็บที่ใช้ในการเยื้อง โดยผู้หญิงคนนี้ หากฉันโชคดีฉันจะเห็นแท็กอินพุตที่ปิดด้วย " </input>" ฝันร้ายรวมที่คุณสามารถเข้าใจได้

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

รหัสที่ฉันกำลังพูดถึงมักจะถูกต้องในทางเทคนิคโครงสร้างที่สมเหตุสมผลและอาจเป็นอัลกอริทึมที่สง่างาม ...

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

ฟังดูเหมือนคุณจะต้องตั้งค่าและยอมรับการประชุมสไตล์ หากคุณไม่มีคุณจะมีห้องสมุดที่มีการเว้นวรรค 3 รายการส่วนที่มี 4 รายการบางแห่งใช้ Camel Case และอื่น ๆ ที่ใช้ underscore_case

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

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

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

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

นี่คือสิ่งที่ควรให้สิ่งจูงใจบางอย่าง:

1. การตรวจสอบรหัสจะน่าเบื่อและนานเกินความจำเป็น
2. รหัสจะถูกปฏิเสธบ่อยขึ้น
3. ตารางจะไม่ถูกพบ

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

ฉันอยากจะแนะนำให้มีการแชทส่วนตัวและดูว่าคุณทั้งคู่สามารถหาสาเหตุ:

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

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

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

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

สำหรับสาเหตุที่ต้องทำแบบส่วนตัวนี่คือเหตุผลบางประการ:

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

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

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

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

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

http://code.google.com/p/kawala/wiki/BadCodeSnippetsRunner

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

หากคุณใช้ Eclipse ให้เปิดใช้งาน Save Actions สำหรับ Java Editors และบอกให้ทุกคนใช้งาน การแก้ไขปัญหาการจัดรูปแบบในการบันทึกทุกครั้ง แต่ไม่ได้แก้ไขตัวพิมพ์ใหญ่ที่ไม่ดี มันอาจจะมีประโยชน์มากทีเดียว!

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

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

แต่ฉันรู้ว่าบางคนสนใจสิ่งเหล่านั้นจริงๆ

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

มักจะถูกต้องทางเทคนิคโครงสร้างที่สมเหตุสมผลและอาจสง่างามแบบอัลกอริทึม

และหากพวกเขาทำไม่ได้อย่างน้อยคุณก็สามารถแสดงรหัสสวย ๆ ให้กับลูกค้าและขายมัน!

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

โซลูชันของฉันเมื่อจัดการกับแหล่งข้อมูลภายนอกที่ไม่ได้ให้ &% $ # เกี่ยวกับการจัดรูปแบบ (หรือข้อบกพร่องที่ป้องกันได้ง่ายสำหรับเรื่องนั้น) คือการให้เซิร์ฟเวอร์สร้างบังคับใช้สิ่งนี้ ฉันสร้างงานเซิร์ฟเวอร์ CI ที่รันทุกคืนที่ตรวจสอบรหัสรัน Jalopy และ findbugs จากนั้นตรวจสอบรหัสกลับมาอีกครั้งเมื่อทีมอื่นรู้ว่าการไม่ใช้ระเบียบรหัสมาตรฐานจะทำให้งานของพวกเขายากขึ้นพวกเขาเริ่มใช้งาน IDE เพื่อรักษารูปแบบมาตรฐาน