ควรบังคับใช้มาตรฐานการเข้ารหัสโดยเซิร์ฟเวอร์รวมอย่างต่อเนื่องหรือไม่


14

ควรบังคับใช้มาตรฐาน / รูปแบบการเข้ารหัสโดยเซิร์ฟเวอร์รวมอย่างต่อเนื่องที่ใช้เครื่องมือวิเคราะห์แบบคงที่ (เช่น PMD, StyleCop / FxCop) และการสร้างล้มเหลวหากไม่ปฏิบัติตามมาตรฐาน? กฎประเภทใดที่ไม่ควรใช้ในการสร้างล้มเหลว

คำตอบ:


11

ควรมีมาตรฐานการเข้ารหัสด้วยเหตุผล ... และควรตรวจสอบการไม่ปฏิบัติตาม

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

ตัวอย่างเช่น MISRA กำหนดกฎของมันเป็นสิ่งที่จำเป็นและคำแนะนำ ... ฉันอยากจะแนะนำว่าคำแนะนำจะช่วยให้การสร้างดำเนินการต่อไป


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

1
@Giorgio - ฉันเห็นด้วย (ส่วนใหญ่) แต่พบว่าการมีแนวคิดเสรีเกินกว่าที่จะยับยั้งคำเตือนอาจเป็นสูตรสำหรับการซ่อนปัญหาที่แท้จริง ... ดังนั้นคำเตือนที่ไม่สนใจควรถูกตรวจสอบเป็นระยะ
Andrew

5

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

ก่อนอื่นทีมควรตัดสินใจเกี่ยวกับมาตรฐานร่วมกัน เครื่องมือเช่น ReSharper ควรใช้เพื่อบอกนักพัฒนาว่าพวกเขาจะไม่ปฏิบัติตามมาตรฐาน การตรวจสอบจากเพื่อนในทุกงานจะช่วยได้มากขึ้น

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

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


2

ควรบังคับใช้มาตรฐาน / รูปแบบการเข้ารหัสโดยเซิร์ฟเวอร์รวมอย่างต่อเนื่องที่ใช้เครื่องมือวิเคราะห์แบบคงที่ (เช่น PMD, StyleCop / FxCop) และการสร้างล้มเหลวหากไม่ปฏิบัติตามมาตรฐาน?

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

กฎประเภทใดที่ไม่ควรใช้ในการสร้างล้มเหลว

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

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


2

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

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

เรามีปัญหาคุณภาพของรหัสและรหัสดั้งเดิมที่มีปัญหามากมาย

การเริ่มต้นบนพื้นฐานที่ว่าหากไม่ล้มเหลวการส่งมอบจะถูกเพิกเฉยเราเริ่มยืนยันกับมาตรฐานการเข้ารหัสที่ 'ต้องการ' ของเรา

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

ดังนั้นฉันจะพูดแบบนี้ (เรียนรู้จากประสบการณ์ที่ยาก)

ตรวจสอบให้แน่ใจว่ามาตรฐานของฐานรหัสของคุณอยู่ใกล้กับมาตรฐานที่คุณบังคับใช้ซึ่งคุณไม่ต้องการให้ dev's ทำการฟอร์แมตวอลุ่มของรหัสทันที หรือ .. คุณพร้อมและคาดหวังว่าจะเพิ่มความพยายาม

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

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

เมื่อเราบังคับใช้รหัส sniffs อีกครั้งเราจะเริ่มสว่างและแนะนำ sniffs สองสามครั้งจนกว่าเราจะมีการบังคับใช้มาตรฐาน


เผง ถ้ามันไม่ทำลายการสร้างมันก็ไร้ประโยชน์สำหรับการได้รับการปฏิบัติตามมาตรฐาน
Andy

1

มันจะขึ้นอยู่กับคุณเป้าหมายสูงสุดและกลยุทธ์

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

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

แต่มีแนวโน้มที่จะเป็นกฎที่มีประโยชน์มากหากนำไปใช้ในช่วงเย็น

นอกจากนี้เครื่องมือการแฟคตอริ่งใหม่สามารถช่วยในการนำไปใช้และเรียนรู้มาตรฐานเช่นการใช้Resharper หรือ JustCodeโดยนักพัฒนา


ฉันไม่เห็นด้วย. มันจะไม่เป็นมาตรฐานหากไม่ได้บังคับใช้โดย build server โดยเฉพาะในทีมขนาดใหญ่ นอกจากนี้ไม่ควรมีใครกำลังรอการสร้างเซิร์ฟเวอร์ตรวจสอบเหมือนกันว่ามันควรจะทำงานโดย devs ก่อนที่พวกเขาจะกระทำ
Andy
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.