รับเลี้ยงระบบบูรณาการอย่างต่อเนื่องของคุณ

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

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

ฉันรู้ว่าหลาย ๆ ทีมที่เป็นผู้ใหญ่ใช้การผสมผสานอย่างต่อเนื่อง แต่ไม่มีเนื้อหาสาระเกี่ยวกับแนวทางปฏิบัติที่ดี

ปัญหาของฉันชี้ให้เห็นว่าการรวมกลุ่มอย่างต่อเนื่องของเราไม่ได้เป็นผู้ใหญ่มากหรือเป็นเพียงส่วนหนึ่งของงานหรือไม่

แนวทางปฏิบัติที่ดีในการปฏิบัติตามคืออะไร? อะไรคือลักษณะของการบูรณาการอย่างต่อเนื่องเป็นผู้ใหญ่ ?

ปรับปรุง

แทนที่จะตอบความคิดเห็นฉันจะทำการอัปเดตแทน เรามีคำสั่งเดียวที่เรียบง่ายที่ทำสิ่งที่เซิร์ฟเวอร์การสร้างจะทำเมื่อสร้างแอป มันจะรวบรวมเรียกใช้หน่วย / การรวมและการทดสอบตาม UI อย่างรวดเร็ว

การอ่านคำตอบของทุกคนรู้สึกว่าเราอาจมีปัญหาสองอย่าง

1. CI Server ไม่บ่นดังพอเมื่อการสร้างล้มเหลว
2. นักพัฒนาไม่รู้สึกว่าเป็นความรับผิดชอบของทุกคนในการทำให้แน่ใจว่าการกระทำของพวกเขาประสบความสำเร็จ

สิ่งที่ทำให้ทีมของฉันลำบากยิ่งขึ้นคือเรามีทีมขนาดใหญ่ (นักพัฒนามากกว่า 10 คน) และเรามีสมาชิกในทีมนอกชายฝั่งสองคนที่กระทำเมื่อเราไม่ได้ทำงาน เนื่องจากทีมมีขนาดใหญ่และเรายอมรับว่าบ่อยครั้งเราต้องการกิจกรรมที่มีขนาดเล็กเราจึงมีกิจกรรมมากมายในหนึ่งวัน

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

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

ทีมของคุณมีสิ่งผิดปกติ:

เป็นผู้รับผิดชอบในการสร้างเซิร์ฟเวอร์จะไม่เหมือนกันในฐานะที่เป็นผู้รับผิดชอบในการสร้าง

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

• สร้างยากจน!
• เกิดอะไรขึ้นเมื่อสร้าง!
• สิ่งที่เปลี่ยนแปลงไปตั้งแต่งานสร้างครั้งล่าสุด!

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

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

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

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

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

กลยุทธ์ "สาขาทองคำ" ไม่ทำงานเว้นแต่จะมีผู้รักษาประตูสำหรับสาขาทองคำ

DVCS อย่าง Git อาจช่วยได้; แทนที่จะส่งมอบผู้พัฒนาสามารถส่งเซ็ตการแก้ไขเพื่อรวมเข้ากับเซิร์ฟเวอร์ CI จากนั้นเซิร์ฟเวอร์สามารถลองรวมเซ็ตการแก้ไขได้ หากการรวมสำเร็จการเซ็ตการแก้ไขจะถูกรวมเข้าด้วยกันและหากไม่ใช่การรวมจะถูกปฏิเสธ

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

ฉันทำให้ build ทั้งหมดมีอยู่ในตัวเองและให้เซิร์ฟเวอร์ CI เริ่มต้น build build โดยไม่มีการกำหนดค่า / ขั้นตอนภายนอก นักพัฒนาสามารถเรียกใช้การสร้างการเปิดตัวในประเทศก่อนที่จะเช็คอินซึ่งรวมถึงขั้นตอนทั้งหมดที่จะต้องดำเนินการโดย CI สร้างและห่างไกลความมั่นใจมากขึ้นว่าไม่มีอะไรที่จะทำลายเมื่อพวกเขาทำเช็คอิน

สิทธิประโยชน์เพิ่มเติมสำหรับวิธีการนี้รวมถึง:

• มันง่ายที่จะสลับไปมาระหว่างเซิร์ฟเวอร์ CI เพราะคุณไม่ได้ลงทุนเวลามากมายในการกำหนดค่าขั้นตอนที่ไม่เกี่ยวข้อง
• เครื่องมือแบบ build-time ทั้งหมดอยู่ภายใต้การควบคุมของแหล่งข้อมูลซึ่งหมายความว่านักพัฒนาทั้งหมดกำลังใช้ชุดเครื่องมือเดียวกันเพื่อสร้างระบบของคุณ
• นอกเหนือจากจุดข้างต้นมันง่ายที่จะเปลี่ยนเครื่องมือสร้างในลักษณะที่ควบคุม

PS แนวคิดการสร้างคนเลี้ยงทั้งหมดนั้นไร้สาระ แต่คนอื่น ๆ

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

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

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

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

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

บุคคลที่รับผิดชอบงานสร้างอาจมีหมวกพิเศษ อาจมีพิธีแจกมัน

โปรดทราบว่าอย่างที่Thorbjørnพูดว่าการรับผิดชอบต่อบิลด์นั้นไม่เหมือนกับการรับผิดชอบต่อบิลด์เซิร์ฟเวอร์ ความรับผิดชอบสำหรับเซิร์ฟเวอร์สามารถพักผ่อนอย่างถาวรกับสมาชิกในทีมที่มีโครงสร้างพื้นฐานอย่างน้อยหนึ่งคนขึ้นไปในขณะที่ความรับผิดชอบในการเคลื่อนย้ายบิลด์

ตอนนี้รายละเอียดของกระบวนการกันฉันจะเข้าร่วมขับร้องคนแสดงความกลัวที่นักพัฒนาตรวจสอบในโดยไม่ต้องเรียกใช้งานสร้างและทดสอบ ยอมรับไม่ได้!

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

ในฐานะที่โจนาธานคูพูดว่าคุณควรรับผิดชอบเซิร์ฟเวอร์การสร้างและสคริปต์การสร้าง มีสามเหตุผล:

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

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

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

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

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

Catlight ยังจะแสดงให้เห็นว่าใครทำลายสิ่งก่อสร้างก่อนสร้างแรงกดดันทางสังคมให้กับบุคคลนี้เนื่องจากทั้งทีมจะเห็นมันในการสร้างความล้มเหลวติดต่อกัน

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

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

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

สิ่งที่คู่ที่ควรทราบ:

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

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