เมื่อใดที่ต้องทำการตรวจสอบโค้ดเมื่อทำการรวมอย่างต่อเนื่อง


33

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

ดังนั้นคำถามคือเมื่อไหร่ที่เราจะตรวจสอบรหัส?

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

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


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

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

มันแตกต่างกันไป แต่สถานที่ส่วนใหญ่ต้องการที่จะทำการตรวจสอบรหัสในสาขาเอกชนก่อนที่จะรวมเป็นหนึ่งในสาขาหลัก
โปรแกรมเมอร์บางคนเพื่อน

คำตอบ:


12

IMO คุณควรตรวจสอบรหัสก่อนที่จะเผยแพร่ไปยังการฉีดเพื่อให้การฉีดมีรหัสคุณภาพสูงสุดเท่านั้น

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

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

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

(การเปิดเผยอย่างเต็มรูปแบบ: ฉันเคยทำงานให้กับ SmartBear ผู้ทำ Code Collaborator ซึ่งเป็นเครื่องมือตรวจสอบรหัส)


4
Codereview-by-email เป็นวิธีปฏิบัติที่ไม่ดี (แม้ว่าจะดีกว่าไม่มีอะไรเป็นที่ยอมรับ) เนื่องจากเป็นการยากที่จะบอกเมื่อการตรวจสอบเสร็จสิ้น ได้รับเครื่องมือรหัสตรวจสอบจริงเช่น Gerrit หรือ reviewboard และใช้งานได้และหยุดการส่งอีเมลแพทช์รอบ :)
pjz

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

2
+1 สำหรับคำแนะนำที่ควรมีการตรวจทานหลังจากการทดสอบอัตโนมัติได้รับการดำเนินการ
William Payne

1
Jordan: เครื่องมือ codereview จริง (gerrit และอื่น ๆ ) ให้มากกว่าความแตกต่าง - ให้คุณอ่านบริบททั้งหมดเพื่อให้คุณสามารถทราบได้ว่าการเปลี่ยนแปลงรหัสมีผลกระทบอย่างไร ถ้าจำเป็นคุณสามารถทำได้ดาวน์โหลดโปรแกรมปะแก้แล้วสร้าง แต่เนื่องจากทุกอย่างต้องผ่าน CI อยู่แล้วก็สันนิษฐานว่ามีข้อผิดพลาดที่สามารถถูกจับได้โดยระบบอัตโนมัติดังนั้นความเข้มข้นจะขึ้นอยู่กับการบำรุงรักษาและขอบกรณีที่ระบบอัตโนมัติหรือ การทดสอบตามปกติอาจไม่ทัน
pjz

1
ไม่ใช่หนึ่งในจุดของ CI ที่จะซิงค์ก่อนและมักจะมีการฉีดยา วิธีการของคุณจะทำให้การซิงค์ล่าช้าซึ่งมีข้อเสียมากมาย
ยาโคบ R

11

ตั้งค่าโปรแกรมมิงคู่?

รหัสทั้งหมดจะได้รับการตรวจสอบตามที่มันถูกพิมพ์โดยไม่ต้องขยายกระบวนการหรือแนะนำขั้นตอนอื่น


7

นี่คือสารสกัดจากผู้จัดส่งอย่างต่อเนื่อง:

Jez Humble เขียนเป็น:

ฉันกำลังเขียนโพสต์บล็อกในหัวข้อนี้ คำตอบสั้น ๆ คือ:

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

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

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

ขอบคุณ

Jez

ลิงค์เดิมคือ: https://groups.google.com/forum/#!msg/continuousdelivery/LIJ1nva9Oas/y3sAaMtibGAJ


5

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

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

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

ดังนั้นเราจึงมีการตรวจสอบโค้ดสองรายการหนึ่งรายการอัตโนมัติและ "มนุษย์" หนึ่งรายการและเราพยายามหลีกเลี่ยงการส่งรหัสที่ยังไม่ผ่านการตรวจสอบในสาขา HEAD ตอนนี้ ... บางครั้งมันเกิดขึ้นได้จากหลายสาเหตุเรายังไม่สมบูรณ์ แต่เราพยายามรักษาสมดุลระหว่างคุณภาพและราคา (เวลา!)

@pjz ให้คำตอบที่ดีเช่นกันและเขากล่าวถึงเครื่องมือตรวจสอบโค้ด I'never ใช้ใด ๆ ดังนั้นผมจึงไม่สามารถพูดอะไรเกี่ยวกับเรื่องนั้น ... แม้ว่าฉันได้รับการล่อลวงในอดีตที่ผ่านมาการทำงานกับเบ้าหลอมตั้งแต่ที่เรากำลังใช้จิระ


ความคิดที่น่าสนใจที่ความคิดเห็นควรจะกำหนดไว้สำหรับโดยเฉพาะอย่างยิ่งเวลา / วัน ...
วิลเลียมเพน

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

4

ฉันคิดว่าแนวคิดหลักที่จะช่วยคือเรื่องของ "การจัดฉาก"

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

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

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

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



2

เราใช้git flowสำหรับที่เก็บข้อมูลของเราและเราทำการตรวจสอบโค้ดของเราเมื่อมันมาถึงการรวมเข้ากับสาขาการพัฒนา

สิ่งใดในการพัฒนาเสร็จสมบูรณ์ปรับใช้และตรวจสอบรหัส

นอกจากนี้เรายังมี CI สำหรับการพัฒนาและสาขาหลักของเรา


2

ฉันคิดว่าคุณต้องมี DVCS (เช่น mercurial, git) เพื่อทำสิ่งนี้ตามธรรมชาติ ด้วย CVCS คุณจะต้องมีสาขาและหวังว่าจะมีเทพเจ้าใดก็ตามที่คุณไม่มีนรกผสม

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

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

ป้อนคำอธิบายรูปภาพที่นี่

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

ป้อนคำอธิบายรูปภาพที่นี่

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

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

PS: เครดิตสำหรับภาพไปที่git-scm.com


1
คนที่ใช้ GitHub ใช้การร้องขอแบบดึงเพื่อทำบทวิจารณ์โค้ดและดูเหมือนว่าจะทำงานได้ดีตามScott Chacon , Zach Holmanและคนอื่น ๆ
Spoike

1

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

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


1

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

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

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

-2

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

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

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

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

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