วิธีจัดการกับโค้ด 'เกือบจะดี' จากนักพัฒนารุ่นเยาว์ [ปิด]

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

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

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

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

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

รหัสความจำจะอ่านบ่อยกว่าที่เขียน ดังนั้นสิ่งที่ดูเหมือน "เล็กน้อย" อาจมีความสำคัญจริง ๆ (เช่นชื่อตัวแปร)

อย่างไรก็ตามหากคุณพบว่าตัวเองแสดงความคิดเห็นซึ่งน่าเบื่อลองพิจารณาดู:

• กระบวนการ CI ของคุณควรจับสิ่งเหล่านี้หรือไม่
• คุณมี "คู่มือนักพัฒนา" ที่ชัดเจนในการอ้างอิง (หรือมีเอกสารทุกอย่างอยู่ในหัวของคุณ) หรือไม่?
• ความคิดเห็นเหล่านี้มีส่วนทำให้คุณภาพรหัสจริงหรือไม่

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

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

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

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

เก็บการวิจารณ์ในรหัสแทนที่จะเป็นนักเขียน

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

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

ภาษากาย

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

ให้ข้อเสนอแนะในเชิงบวกอย่างซื่อสัตย์

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

ผู้ชายคนนี้เปิดรับการวิจารณ์และยินดีที่จะเรียนรู้ แต่ฉันมีข้อสงสัยว่าฉันควรผลักดันบางสิ่ง

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

นั่นจะหมายถึงรหัสน้อยลงสำหรับคุณในการตรวจสอบในอนาคตและอาจทำให้ทีมของคุณมีเป้าหมายในการจ้างงาน

นอกจากนี้หากคุณระงับคุณไม่ได้ช่วย แต่สนับสนุน

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

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

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

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

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

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

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

ดังนั้นคุณจะไม่พูดว่า "ฉันปฏิเสธงานของคุณเพราะมันไม่ดีพอ" คุณพูดว่า (a) "ฉันยอมรับงานของคุณเพราะมันดีพอ" จากนั้น (b) "แต่ฉันต้องการให้ดีขึ้น"

คำถามที่เปิดกว้างสวย แต่ที่นี่เป็นความคิดที่สอง

1. ความเห็นจากเพื่อน (โดยผู้พัฒนารุ่นเยาว์)

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

2. ข้อเสนอแนะก่อน / รีวิวงาน

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

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

นอกจากนี้ถ้าคุณอนุญาตให้มีการละเมิดไม่กี่มาตรฐานที่นี่และมีแล้วพวกเขาจะเป็นแบบอย่างที่ไม่ดี - เห็นหน้าต่างแตกทฤษฎี นอกจากนี้ยังเป็นการง่ายกว่ามากที่จะจำตามมาตรฐานหากมีการใช้กับ codebase แล้ว ดังนั้นจริงๆทุกคนชนะรวมถึงนักพัฒนารุ่นน้อง

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

พิจารณาการใช้เวิร์กโฟลว์การตรวจสอบโค้ดโดยที่นักพัฒนาโพสต์ข้อเสนอที่เสนอไปยังเครื่องมือเช่น Github Pull Requests หรือ Phabricator Diffusion และรับ peer-off sign-off ก่อนที่จะเชื่อมโยงการเปลี่ยนแปลงไปยังสาขาหลักที่ใช้ร่วมกัน

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

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

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

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

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

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

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

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

ฉันกำลังติดต่อกับนักพัฒนารุ่นน้องที่ทำงานจากระยะไกลจากโรงงานเข้ารหัส

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

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

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

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

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

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

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

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

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

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