แล้วกฎการเข้ารหัสเหล่านั้นล่ะ?

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

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

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

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

บางครั้งแรงกดดันจากเพื่อนก็เป็นทางออกที่ดีที่สุดสำหรับสิ่งนี้

ที่ทำงานของฉันเราใช้โซลูชันทั้งสามต่อไปนี้:

1) ใช้ตัวตรวจสอบรูปแบบโค้ดเช่นCheckstyle ที่ยอดเยี่ยม(สำหรับ Java) หรือStyleCop (สำหรับ C #) เครื่องมือเหล่านี้ได้รับการกำหนดค่าอย่างง่ายดายซึ่งสามารถเน้นสไตล์การเข้ารหัส / การเบี่ยงเบนกฎโดยอัตโนมัติ มันทำให้ทุกคนเป็นบุคคลที่สามที่เป็นกลางในการกำหนดสิ่งที่และไม่เป็นที่ยอมรับ

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

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

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

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

พวกเขาเป็น "หัวแข็ง" โดยไม่ใช้วงเล็บหรือเป็นคำขอ "หัวแข็ง" หรือไม่

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

OO 101 : "Refactor เมื่อผลิตภัณฑ์ทำในสิ่งที่ต้องทำ" ไม่ก่อน

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

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

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

ฉันคิดว่าคุณกำลังพูดถึงปัญหาในระดับที่แตกต่างกันมาก:

วิธีทำให้คนที่หัวแข็งที่ไม่ชอบใช้วงเล็บในคำสั่ง if

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

หรือใช้สายเชื่อมต่อเดียวกันทุกที่ในรหัส

หากคุณหมายถึง Magic Constants นั่นคือปัญหาการบำรุงรักษา (รวมถึงความปลอดภัยที่อาจเกิดขึ้น) และ IMHO เช่นนี้นักพัฒนาที่มีประสบการณ์จะเข้าใจและยอมรับว่าเป็นสิ่งที่ไม่ดี

หรืออะไรก็ตามที่จะใช้กฎการเข้ารหัสโดยไม่ทำให้พวกเขาต่อต้านความคิด?

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

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

ทำให้พวกเขามีส่วนร่วมในการสร้างกฎ สิ่งนี้มักจะช่วยกระตุ้นให้ผู้คนติดตามพวกเขา

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

สตริงการเชื่อมต่อเดียวกันทุกที่? วิธีการแก้ปัญหาคือการ refactor จนกว่าคุณจะลบการทำซ้ำทั้งหมด ตัวคัดลอก - วางโค้ดควรไปที่คุกโปรแกรมเมอร์ (อย่าหัวเราะ! Steve Ballmer เป็นผู้คุม)

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

วิธีที่ฉันจะแก้มัน:

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

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