เป็นเรื่องดีไหมที่จะตรวจสอบโปรแกรมกับผู้อาวุโสและหัวหน้างานแม้ว่ามันจะใช้ได้ดีหรือไม่?

ใน บริษัท ของฉันก่อนส่งมอบโครงการใด ๆ เจ้านายของฉันขอให้ผู้อาวุโสของฉันตรวจสอบโปรแกรมที่ฉันหรือสมาชิกในทีมอื่นเขียน

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

พวกเขากล่าวว่าการตรวจสอบช่วยในการเพิ่มประสิทธิภาพของโปรแกรมและการดำเนินการค้นหา แต่เราสามารถต้องการเพิ่มประสิทธิภาพมากกว่าการทำงานจริงของโปรแกรม

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

รหัสที่ดีคืออย่างน้อย:

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

(ข้อกำหนดบางประการเหล่านี้มีการทับซ้อนกัน แต่จริง ๆ แล้วควรพิจารณาทีละรายการ ... )

การตรวจสอบโค้ดมีจุดประสงค์นอกเหนือจากส่วน "ทำงาน" ซึ่งสามารถทำได้ผ่านการทดสอบอัตโนมัติ

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

ในทางบวกมากขึ้นเซสชั่นอาจเป็นโอกาสที่จะแบ่งปันการปฏิบัติที่ดี / การออกแบบ

ฉันตีความคำถามของคุณว่า"รหัสการทำงานของฉันจะถูกสังหารในการตรวจสอบไปยังจุดที่ไม่ได้รวบรวมอีกต่อไปหรือไม่" .

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

คุณบอกว่ามันใช้งานได้ ทำการทดสอบเพื่อยืนยันสิ่งนี้ การทดสอบผ่านโมดูลไม่ได้หมายความว่าไม่ควรสัมผัสโมดูลอีกครั้ง

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

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

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

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

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

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