คุณจะบอกคนที่กำลังเขียนโค้ดไม่ดีได้อย่างไร [ปิด]

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

แนะนำคำถามเพื่อให้พวกเขาตระหนักว่าสิ่งที่พวกเขากำลังทำนั้นผิด ตัวอย่างเช่นถามคำถามประเภทนี้:

ทำไมคุณถึงตัดสินใจสร้างตัวแปรระดับโลก

คุณให้ชื่อนั้นทำไม

นั่นดูน่าสนใจ. ฉันมักจะทำแบบนี้เพราะ [ใส่เหตุผลที่ว่าทำไมคุณถึงดีกว่า]

วิธีนี้ใช้งานได้หรือไม่ ฉันมักจะ [แทรกวิธีที่คุณจะทำให้พวกเขาดูโง่]

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

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

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

เริ่มทำการตรวจสอบโค้ดหรือเขียนโปรแกรมคู่

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

ในฐานะที่เป็น @JesperE: กล่าวว่ามุ่งเน้นไปที่รหัสไม่ใช่รหัส

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

Globals : คุณคิดว่าเราจะอยากมีมากกว่าหนึ่งอย่างไหม? คุณคิดว่าเราจะต้องการควบคุมการเข้าถึงสิ่งนี้หรือไม่?

สถานะที่ไม่แน่นอน : คุณคิดว่าเราต้องการจัดการกับสิ่งนี้จากหัวข้ออื่นหรือไม่?

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

ฟังก์ชั่นที่ยาวนาน : สมองของฉันไม่ใหญ่พอที่จะเก็บทั้งหมดนี้ในครั้งเดียว เราจะทำชิ้นเล็ก ๆ ที่ฉันสามารถจัดการได้อย่างไร

ชื่อที่ไม่ดี : ฉันสับสนง่ายพอเมื่ออ่านโค้ดที่ชัดเจน เมื่อชื่อทำให้เข้าใจผิดไม่มีความหวังสำหรับฉัน

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

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

คุณต้องอธิบายว่าทำไมวิธีการของคุณจะดีกว่า

อธิบายว่าทำไมฟังก์ชั่นจึงดีกว่าการตัดและวาง

อธิบายว่าทำไมอาร์เรย์จึงดีกว่า $ foo1, $ foo2, $ foo3

อธิบายว่าทำไมตัวแปรโลกถึงอันตรายและตัวแปรท้องถิ่นจะทำให้ชีวิตง่ายขึ้น

เพียงแค่ตีพิมพ์มาตรฐานการเข้ารหัสและการพูดว่า "ทำสิ่งนี้" นั้นไม่มีค่าเพราะไม่ได้อธิบายถึงโปรแกรมเมอร์ว่าทำไมมันถึงดี

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

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

อีกทางเลือกหนึ่งคือการนำหนังสือทางเทคนิคเข้ามาในสำนักงาน (Code Complete, Effective C ++, Pragmatic Programmer ... ) และเสนอที่จะให้ยืมกับผู้อื่น ("เฮ้ฉันเสร็จแล้วกับเรื่องนี้ทุกคนอยากจะยืมมัน?" )

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

แนะนำทางเลือกที่ดีกว่าในแบบที่ไม่คาดคั้น

"เฮ้ฉันคิดว่าวิธีนี้จะใช้ได้เหมือนกันพวกคุณคิดอย่างไร?" [ท่าทางไปยังโค้ดที่ดีขึ้นอย่างเห็นได้ชัดบนหน้าจอของคุณ]

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

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

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

ตามตัวอย่าง แสดงให้พวกเขาเห็นวิธีที่ถูกต้อง

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

แนวคิดมาตรฐานรหัสเป็นแนวคิดที่ดี

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

มีคำแนะนำที่ดีจริงๆในหนังสือ "The Psychology of Computer Programming" ของ Gerry Weinberg - ความคิดทั้งหมดของเขาเกี่ยวกับ "การเขียนโปรแกรม egoless" คือทั้งหมดเกี่ยวกับวิธีที่จะช่วยให้ผู้คนยอมรับการวิจารณ์รหัสของพวกเขาแตกต่างจากการวิจารณ์ตัวเอง

แนวทางปฏิบัติในการตั้งชื่อไม่ดี: อภัยไม่ได้เสมอ

และใช่ไม่คิดเสมอว่าวิธีการของคุณดีกว่า ... มันอาจเป็นเรื่องยาก แต่ต้องรักษาความเป็นกลาง

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

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

เริ่มวิกิบนเครือข่ายของคุณโดยใช้ซอฟต์แวร์วิกิ

เริ่มต้นหมวดหมู่บนไซต์ของคุณที่เรียกว่า "แนวทางปฏิบัติที่ดีที่สุด" หรือ "มาตรฐานการเข้ารหัส" หรือบางอย่าง

ชี้ให้ทุกคนดู อนุญาตสำหรับข้อเสนอแนะ

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

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

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

หากคุณไม่มีรูปแบบการเข้ารหัสตอนนี้เป็นเวลาที่ดีที่จะเข้ามาแทนที่ สิ่งที่ต้องการคำตอบสำหรับคำถามนี้อาจเป็นประโยชน์: /programming/4121/team-coding-styles

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

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

ฉันรักรหัสและไม่เคยมีหลักสูตรใด ๆ ในชีวิตของฉันเกี่ยวกับอะไรที่เกี่ยวข้องกับสารสนเทศฉันเริ่มแย่มากและเริ่มเรียนรู้จากตัวอย่าง แต่สิ่งที่ฉันจำได้และจำไว้เสมอในใจตั้งแต่ฉันอ่านหนังสือ"Gang Of Four"คือ :

"ทุกคนสามารถเขียนโค้ดที่เครื่องเข้าใจได้ แต่ไม่ใช่ทุกคนสามารถเขียนโค้ดที่มนุษย์เข้าใจได้"

ด้วยสิ่งนี้ในใจมีหลายสิ่งที่ต้องทำในรหัส;)

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

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

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

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

ความอดทน วิวัฒนาการไม่ใช่การปฏิวัติ

โชคดี.

ฉันสวมเสื้อคลุมและเปิดวิธีการโสคราตีส

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

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

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

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

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

คนที่เขียนโค้ดไม่ดีเป็นเพียงอาการที่ไม่รู้ (ซึ่งแตกต่างจากความโง่) นี่คือเคล็ดลับในการจัดการกับคนเหล่านั้น

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

แทนที่จะให้พวกเขาเขียนโค้ดให้พวกเขาเก็บรักษารหัสไว้

จนกว่าพวกเขาจะต้องรักษากองนึ่งสปาเก็ตตี้ของพวกเขาไว้พวกเขาจะไม่เข้าใจว่าพวกเขากำลังเขียนรหัสแย่แค่ไหน

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

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

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

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

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

1. สนทนา
2. แสดงให้พวกเขาทำไม
3. อย่าแม้แต่จะคิดว่าคุณพูดถูกเสมอ .. บางครั้งพวกเขาก็จะสอนสิ่งใหม่ให้คุณ

นั่นคือสิ่งที่ฉันจะทำถ้าฉันเป็นคุณ: D

อาจจะช้าไปหน่อยหลังจากเอฟเฟกต์ แต่นั่นเป็นสิ่งที่มาตรฐานการเข้ารหัสที่ตกลงกันไว้เป็นสิ่งที่ดี

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

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

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

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

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

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

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

หาก # 2 เกิดขึ้นหรือ # 1 ไม่ส่งผลให้มีการปรับปรุงอย่างเพียงพอจากมุมมองของคุณและมันกำลังส่งผลกระทบต่อโครงการและ / หรือกระทบกระเทือนต่อคุณมากพออาจถึงเวลาที่จะเริ่มต้นแคมเปญเพื่อสร้าง / บังคับใช้มาตรฐานภายใน ทีมงาน. ที่ต้องมีการจัดการซื้อ แต่มีประสิทธิภาพมากที่สุดเมื่อบ้าจี้จากรากหญ้า

ขอให้โชคดี ฉันรู้สึกถึงความเจ็บปวดของพี่ชายของคุณ