ควรบังคับใช้มาตรฐาน / รูปแบบการเข้ารหัสโดยเซิร์ฟเวอร์รวมอย่างต่อเนื่องที่ใช้เครื่องมือวิเคราะห์แบบคงที่ (เช่น PMD, StyleCop / FxCop) และการสร้างล้มเหลวหากไม่ปฏิบัติตามมาตรฐาน? กฎประเภทใดที่ไม่ควรใช้ในการสร้างล้มเหลว
ควรบังคับใช้มาตรฐาน / รูปแบบการเข้ารหัสโดยเซิร์ฟเวอร์รวมอย่างต่อเนื่องที่ใช้เครื่องมือวิเคราะห์แบบคงที่ (เช่น PMD, StyleCop / FxCop) และการสร้างล้มเหลวหากไม่ปฏิบัติตามมาตรฐาน? กฎประเภทใดที่ไม่ควรใช้ในการสร้างล้มเหลว
คำตอบ:
ควรมีมาตรฐานการเข้ารหัสด้วยเหตุผล ... และควรตรวจสอบการไม่ปฏิบัติตาม
อย่างไรก็ตามการละเมิดไม่ควรถือเป็นข้อผิดพลาด - เช่นเดียวกับการละเมิดไม่รวบรวมทั้งหมด ที่ที่คุณวาดเส้นจะต้องเป็น บริษัท และการตัดสินใจของเครื่องมือ
ตัวอย่างเช่น MISRA กำหนดกฎของมันเป็นสิ่งที่จำเป็นและคำแนะนำ ... ฉันอยากจะแนะนำว่าคำแนะนำจะช่วยให้การสร้างดำเนินการต่อไป
มันไม่ได้ไม่เคยได้ยินมาก่อนและคุณจะรู้ว่ามันจะได้ผลสำหรับคุณโดยการลองใช้เท่านั้น มีขั้นตอนบางอย่างที่คุณสามารถทำได้ก่อนหน้านั้น
ก่อนอื่นทีมควรตัดสินใจเกี่ยวกับมาตรฐานร่วมกัน เครื่องมือเช่น ReSharper ควรใช้เพื่อบอกนักพัฒนาว่าพวกเขาจะไม่ปฏิบัติตามมาตรฐาน การตรวจสอบจากเพื่อนในทุกงานจะช่วยได้มากขึ้น
หลังจากดำเนินการตามขั้นตอนเหล่านั้นแล้วอาจถือได้ว่านำการตรวจสอบมาตรฐานการเข้ารหัสไปใช้กับเซิร์ฟเวอร์ CI อย่างไรก็ตามควรพิจารณาว่าควรสร้างตัวแบ่งเพื่อไม่ปฏิบัติตามมาตรฐานการเข้ารหัส ความเสี่ยงคือคุณจะมีงานสร้างที่เสียหายจำนวนมากซึ่งอาจหมายถึงความหมายของงานสร้างที่เสียหาย
แทนที่จะทำให้บิลด์หยุดทำงานคุณสามารถรันเครื่องมือและให้พวกเขาสร้างรายงาน หากการเข้ารหัสการละเมิดมาตรฐานดูเหมือนจะเพิ่มขึ้นคุณสามารถรวมทีมและเข้าใจว่าทำไมมันถึงเกิดขึ้น
ควรบังคับใช้มาตรฐาน / รูปแบบการเข้ารหัสโดยเซิร์ฟเวอร์รวมอย่างต่อเนื่องที่ใช้เครื่องมือวิเคราะห์แบบคงที่ (เช่น PMD, StyleCop / FxCop) และการสร้างล้มเหลวหากไม่ปฏิบัติตามมาตรฐาน?
การตรวจสอบการรวมระบบอย่างต่อเนื่องนั้นจำเป็นต้องรวดเร็วมาก ความล่าช้าที่สำคัญใด ๆ จะหมายถึงโปรแกรมเมอร์ของคุณกำลังจะยอมรับและสูญเสียการติดตามกระบวนการคิดของพวกเขาในขณะที่รอผลลัพธ์ ทำให้มันยาวขึ้นและพวกเขาจะทำและรับกาแฟสักถ้วยหรือแชทกับเพื่อนออฟฟิศของพวกเขาเกี่ยวกับการทำงานที่ผิดพลาดล่าสุดของทีมกีฬาบางคน ความล่าช้าเหล่านั้นจะต่อต้านมาก บางสิ่งที่ดีที่สุดคือการสร้างตอนกลางคืนหรือทบทวนรหัส
กฎประเภทใดที่ไม่ควรใช้ในการสร้างล้มเหลว
คนที่เป็นอัตนัยเริ่มต้นด้วย คุณจะบังคับใช้กฎ "รหัสจะต้องเป็นเอกสารที่จัดทำเองหรือมีความคิดเห็นดี" อย่างไร กฎ "ไม่มีหมายเลขมายากล" หรือไม่ สิ่งเหล่านี้เป็นสิ่งที่ดีที่สุดสำหรับการทบทวนโค้ด
หมวดอื่นคือการละเมิดกฎที่ได้รับการผ่อนผันแล้ว เมื่อพิจารณาจากพื้นฐานของโค้ดที่มีขนาดใหญ่ย่อมมีโค้ดบางอันที่ละเมิดมาตรฐานเป็นสิ่งที่ถูกต้อง
เป็นส่วนหนึ่งของแผนปรับปรุงคุณภาพซอฟต์แวร์เมื่อเร็ว ๆ นี้เราได้เขียนรหัสชุดข้อมูลเพื่อรวมเข้ากับกระบวนการสร้างของเรา
เราสร้างจำนวนมากเนื่องจากเป็นแอปพลิเคชัน PHP ไม่มีการรวบรวมจริงดังนั้นการสร้างจึงเป็นการทดสอบหน่วย / การวิเคราะห์แบบคงที่ / นักวิ่งและเราสามารถที่จะใช้เวลาสักสองสามรอบในการนี้
เรามีปัญหาคุณภาพของรหัสและรหัสดั้งเดิมที่มีปัญหามากมาย
การเริ่มต้นบนพื้นฐานที่ว่าหากไม่ล้มเหลวการส่งมอบจะถูกเพิกเฉยเราเริ่มยืนยันกับมาตรฐานการเข้ารหัสที่ 'ต้องการ' ของเรา
การบำรุงรักษาหยุดชะงักแม้แต่การแก้ไขที่ง่ายที่สุดสำหรับองค์ประกอบแบบดั้งเดิมนั้นผู้พัฒนาจำเป็นต้องทำการฟอร์แมตแหล่งที่มาจำนวนมากอีกครั้งและตัวสร้างถูกทำลายบ่อยกว่าไม่ ไม่จำเป็นต้องบอกว่าเราเปลี่ยนข้อผิดพลาดเป็นคำเตือนและตอนนี้พวกเขาจะถูกเพิกเฉยและไม่มีประโยชน์ 'ส่วนใหญ่'
ดังนั้นฉันจะพูดแบบนี้ (เรียนรู้จากประสบการณ์ที่ยาก)
ตรวจสอบให้แน่ใจว่ามาตรฐานของฐานรหัสของคุณอยู่ใกล้กับมาตรฐานที่คุณบังคับใช้ซึ่งคุณไม่ต้องการให้ dev's ทำการฟอร์แมตวอลุ่มของรหัสทันที หรือ .. คุณพร้อมและคาดหวังว่าจะเพิ่มความพยายาม
ในฐานะทีมเล็ก ๆ ที่มีความต้องการในการจัดส่งจำนวนมากเราไม่สามารถที่จะเปลี่ยนทีมเป็นปัจจัยการดำเนินงานที่ยิ่งใหญ่อีกครั้ง ตอนนี้มาตรฐานการเข้ารหัสของเราส่วนใหญ่จัดการโดยการตรวจสอบด้วยตนเองและมรดกจะถูกเขียนใหม่เป็นส่วนหนึ่งของแผนการปรับปรุงอย่างต่อเนื่อง
เมื่อฉันบอกว่าคำเตือนส่วนใหญ่ไร้ประโยชน์ตอนนี้เราใช้มันเพื่อบันทึกสถิติที่ทำให้เราสามารถวัดค่า kpi ที่ควรจะปรับปรุงต่อไป
เมื่อเราบังคับใช้รหัส sniffs อีกครั้งเราจะเริ่มสว่างและแนะนำ sniffs สองสามครั้งจนกว่าเราจะมีการบังคับใช้มาตรฐาน
มันจะขึ้นอยู่กับคุณเป้าหมายสูงสุดและกลยุทธ์
การบังคับใช้มาตรฐานที่กล่าวถึงดีทั้งหมดในเซิร์ฟเวอร์ CI อาจดูมีกำไรมาก อย่างไรก็ตามมันอาจไม่เป็นประโยชน์สำหรับทีมพัฒนาขนาดใหญ่ (มากกว่า 6 นักพัฒนา) หากทำในแต่ละการส่งมอบให้กับเซิร์ฟเวอร์ การรอเซิร์ฟเวอร์ของคุณเพื่อตอบสนองหลังจากส่งข้อมูลแล้วไม่ควรรอนาน มันอาจทำให้เกิดการหยุดทำงาน
อย่างไรก็ตามมันถูกต้องตามกฎหมายทั้งหมดในการบล็อกการคอมมิชชันถ้ารหัส (ชุดการเปลี่ยนแปลงจริง) มีปัญหาการพึ่งพาหรือไม่คอมไพล์ อย่างไรก็ตามโค้ดที่ล้มเหลวเนื่องจากเลย์เอาต์ของรหัสและการตั้งชื่อบางอย่างอาจจะรุนแรงเกินไปและไม่มีข้อ จำกัด ที่สำคัญสำหรับเซิร์ฟเวอร์ CI ที่ยอมรับกฎ
แต่มีแนวโน้มที่จะเป็นกฎที่มีประโยชน์มากหากนำไปใช้ในช่วงเย็น
นอกจากนี้เครื่องมือการแฟคตอริ่งใหม่สามารถช่วยในการนำไปใช้และเรียนรู้มาตรฐานเช่นการใช้Resharper หรือ JustCodeโดยนักพัฒนา