คุณจะตรวจสอบคุณภาพของรหัสผู้ว่าจ้างที่มีศักยภาพได้อย่างไรก่อนที่คุณจะเข้ารับตำแหน่ง [ปิด]

จากประสบการณ์ของฉันก่อนที่คุณจะเริ่มทำงานกับ บริษัท คุณไม่มีโอกาสได้ดู code-base (ฉันถามและด้วยเหตุผลของการรักษาความลับทุกคนมักจะบอกว่าไม่ฉันคิดว่ามันยุติธรรม) ดังนั้นระหว่างการสัมภาษณ์ คุณคิดว่าเป็นคำถามที่สำคัญที่สุดในการขอให้ตรวจสอบว่ารหัสอยู่ในสถานะใด (หลังจากทั้งหมดถ้าเป็นสุนัขคุณจะต้องอยู่ในกลุ่มผู้โชคร้ายที่ต้องเดินทุกวัน)?

UPDATE:

รายการตรวจสอบ: ถาม;

• สิ่งที่พวกเขาคิดเกี่ยวกับ codebase และเมื่อคุณทำอย่างนั้นให้ใส่ใจกับการแสดงออกทางสีหน้าและเวลาที่พวกเขาต้องตอบ [อานนท์]
• ระดับ CMM ของ บริษัท คืออะไร [DPD] (และถ้าคุณได้ยินระดับ 5 ให้ใช้วิธีอื่น [Doug T])
• วงจรชีวิตใดที่พวกเขาใช้ [DPD] (และถ้าคุณได้ยิน "Agile" นั่นคือเมื่อคุณเริ่มถามคำถามเจาะเพื่อลองคิดดูว่าโดย "Agile" พวกเขาหมายถึง "Agile หรือ" Cowboy coding "[Carson63000]
• เครื่องมือใดที่พวกเขาใช้เพื่อประเมินคุณภาพโค้ด [DPD]
• เครื่องมืออะไรที่พวกเขาใช้สำหรับการพัฒนา [DPD] (ค้นหาเครื่องมือ refactoring และเซิร์ฟเวอร์บิลด์ต่อเนื่อง)
• ระบบที่ใช้ซอร์สโค้ด (การควบคุมเวอร์ชัน) คืออะไรและการติดตามที่ดีคือการถามว่าทำไมจึงใช้ [Zachary K]
• ขั้นตอนการทดสอบของพวกเขาเป็นอย่างไร? [Karl Bielefeldt] (มองโดยเฉพาะอย่างยิ่งสำหรับทีมที่ใช้กรอบการเยาะเย้ยและให้ความสำคัญกับการทดสอบหน่วยอัตโนมัติอย่างละเอียดผ่านกรอบการทำงานที่กำหนดเช่น NUnit / JUnit อย่าถูกเลื่อนออกไปโดยทีมที่ไม่ได้ใช้การทดสอบขับเคลื่อนการพัฒนา TDD ระวังหากพวกเขาไม่พิจารณาการทดสอบว่าเป็นส่วนสำคัญและเป็นรากฐานสำคัญของการพัฒนาซอฟต์แวร์ที่มั่นคงมองหาทีมที่มีผู้ทดสอบที่ทุ่มเท)
• การมอบหมายประเภทใดให้นักพัฒนาใหม่? เพื่อนักพัฒนาที่มีประสบการณ์? [Karl Bielefeldt]
• มีคนทำงานในโครงการกี่คน [Karl Bielefeldt]
• อนุญาตให้ทำการเปลี่ยนใหม่หรือไม่ ได้รับการสนับสนุน? [Karl Bielefeldt]
• กระบวนการที่เกี่ยวข้องกับคุณภาพหรือการเปลี่ยนแปลงสถาปัตยกรรมใดที่อยู่ระหว่างการพิจารณาหรือเพิ่งทำไปเมื่อเร็ว ๆ นี้ [Karl Bielefeldt]
• บุคคลมีอิสระในการปกครองตนเองมากน้อยแค่ไหนในโมดูล [Karl Bielefeldt]
• คุณจะพัฒนาโครงการใหม่ (การพัฒนากรีนฟิลด์) หรือโครงการดั้งเดิม (การพัฒนาบราวน์ฟิลด์) หรือไม่? (การพัฒนากรีนฟิลด์เป็นเรื่องสนุกมากขึ้นและมีปัญหาน้อยลงเนื่องจากคุณไม่ได้ทำความเข้าใจกับความผิดพลาดของคนอื่น)
• อัตราการลาออกของพนักงานสูงในองค์กรหรือในทีมหรือไม่? (ซึ่งมักจะบ่งบอกถึงคุณภาพของรหัสที่ต่ำกว่า) [M.Sameer]
• ปัญหาการเขียนโปรแกรมบางอย่างของคุณเอง; แต่หลีกเลี่ยงการดูเหมือนกระตุก [สปาร์ก]
• นักพัฒนาทำงานร่วมกันได้อย่างไรและมีการแบ่งปันความรู้ระหว่างทีมอย่างไร (สิ่งนี้ควรตรงกับบุคลิกของคุณฉันจะบอกว่าการผสมผสานระหว่างงานเดี่ยวและงานคู่น่าจะดีที่สุดโดยมีอัตราส่วนที่ตรงกับความต้องการทางสังคมของคุณ)
• วิธีปิดฐานข้อมูลของพวกเขาคือแบบฟอร์มปกติที่ 3 (3NF) และถ้ามันเบี่ยงเบนที่ไหนและทำไม (หากพวกเขาพูดว่า "3NF ???" ออกไปถ้าไม่และอาจมีเหตุผลที่ดีสำหรับสิ่งนั้นไม่ให้ค้นหาสิ่งที่พวกเขาเป็น)

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

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

จากนั้นใช้ความรู้ของคุณเกี่ยวกับท่าทางที่ไม่ใช่คำพูดของวัฒนธรรมของคุณเพื่อตีความสิ่งที่พวกเขาพูดจริง ๆ สำหรับ บริษัท ในอเมริกาเหนือสิ่งต่อไปนี้ควรถูกต้อง:

• ยักขนาดเล็กและการตอบสนองอย่างรวดเร็วของ "มันอาจจะดีกว่า": มันอาจจะค่อนข้างดี
• หยุดหายใจนาน ๆ อาจสูดเสียงหัวเราะเล็กน้อย: มันไม่เป็นที่น่าพอใจและคนที่คุณสัมภาษณ์ไม่สบายใจที่จะบอกคุณว่า
• ดวงตาที่รีด, การตอบสนองอย่างรวดเร็วของ "มันแย่": อาจจะดี, อาจจะแย่ แต่มีเกมการเมืองเกิดขึ้น ถ้าคุณไม่พร้อมที่จะเล่นเกมนั้นหรือเป็นคนเงียบ ๆ ให้อยู่ห่าง ๆ
• คิ้วที่ยกหรือหดตัว: พวกเขาไม่เข้าใจคำถามและ codebase เกือบจะเน่าเปื่อย

แน่นอนถ้าคุณมีปัญหากับการสื่อสารระหว่างบุคคลนี่อาจไม่เหมาะกับคุณ

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

นี่คือสิ่งที่คุณสามารถขอให้ค้นหา

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

1. ถามพวกเขาว่าพวกเขาใช้การควบคุมแหล่งที่มา
   • ไม่มีการควบคุมแหล่งที่มา? -> รหัสมีแนวโน้มมากที่สุด
2. ถามพวกเขาว่าทำรีวิวโค้ดบ่อยแค่ไหน
   • ไม่มีรีวิวรหัส? -> รหัสอาจเป็นที่สงสัย (แต่ไม่จำเป็นต้องเป็นเช่นนั้นโดยเฉพาะหากเป็นทีมเล็ก ๆ ที่ประกอบด้วยนักพัฒนาที่เหมาะสม)
3. ถามพวกเขาว่าพวกเขาทดสอบและปรับใช้อย่างไรก่อนที่จะเข้าสู่การผลิต?
   • ไม่มีสภาพแวดล้อมการทดสอบ? การปรับใช้โดยตรงไปสู่การผลิต? -> รหัสมีแนวโน้มมากที่สุด
4. ถามพวกเขาว่าพวกเขาจะบูรณาการอย่างต่อเนื่อง (.ie. ทำงานสร้างด้วยฮัดสัน)
   • ไม่มีการรวมอย่างต่อเนื่อง? -> รหัสอาจสงสัย แต่ไม่จำเป็นต้องเป็นเช่นนั้น
5. (เกี่ยวข้องกับ # 3) ถามพวกเขาว่าสภาพแวดล้อมการทดสอบนั้นแยกจากสภาพแวดล้อมการพัฒนาของคุณหรือไม่
   • การทดสอบคือ dev หรือไม่ -> ไม่ได้เป็นสัญญาณที่ดีไม่เว้นเสียแต่ว่ามันจะเป็นกล่องเงินสด แต่ราคาจะแพงแค่ไหน?
6. ถามพวกเขาหากพวกเขาตรวจสอบรายการการกระทำก่อนที่จะปรับใช้ในการผลิต
   • ยังไม่ได้ตรวจสอบการกระทำก่อนการปรับใช้การผลิต? -> juju ไม่ดี
7. ถามพวกเขาว่าต้องใช้ขั้นตอนกี่ขั้นตอนสำหรับพวกเขาในการสร้าง
   • มากกว่า 3? -> juju ไม่ดีโดยทั่วไป
8. พวกเขาจะใช้ (หรือคาดเดา) รหัสตัวชี้วัดเช่นความซับซ้อนของวงจรหรือ LCOM (การวัดการทำงานร่วมกันในชั้นเรียน)
   • ใช่? -> อาจเป็นสัญญาณที่ดีเกี่ยวกับคุณภาพของรหัส
   • ไม่ แต่พวกเขาเข้าใจแนวคิด (อย่างน้อยก็ความซับซ้อนของวัฏจักร)? -> ยากที่จะพูด
   • พวกเขาคิดว่าวงจรความซับซ้อนเป็นจานแปลกใหม่หรือยาโป๊จาก Timbuktu (ในคำอื่น ๆ พวกเขาไม่รู้ว่ามันคืออะไร)? -> juju ไม่ดีที่เป็นไปได้
   • พวกเขาคิดว่านั่นเป็นเรื่องที่ไม่เกี่ยวข้อง (หรือพฤติกรรมอื่น ๆ ของการเรียงลำดับ)? -> วิ่งหนี
9. ถามพวกเขาว่าพวกเขาติดตามข้อบกพร่องได้อย่างไร
   • พวกเขาติดตาม # ของข้อบกพร่องเทียบกับตัวชี้วัดบางอย่าง (.ie. ต่อโครงการจำนวนโมดูลที่เปลี่ยนแปลงหรือจำนวนคำขอ / คำขอเปลี่ยนแปลงบางสิ่ง!) -> สัญญาณที่ดีเกี่ยวกับรหัส (และกระบวนการซอฟต์แวร์)
   • พวกเขาทำอย่างใดอย่างหนึ่งข้างต้นและพยายามคาดการณ์จำนวนข้อบกพร่องที่เป็นไปได้ที่อาจพบในโครงการ (หรือต่อเนื่อง) ในอนาคตตามเมตริกที่คาดไว้ (จำนวนคำขอการเปลี่ยนแปลงขนาดโครงการ ฯลฯ ) -> เครื่องหมายที่ดีมาก
   • พวกเขาติดตามข้อบกพร่องเท่านั้นสำหรับการแก้ไขข้อบกพร่อง? -> ยากที่จะบอก
   • ไม่มีการติดตามที่สอดคล้องกัน? -> วิ่งหนี

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

เมื่อคุณถามคำถามเหล่านี้ให้ดำเนินการด้วยความระมัดระวัง ศึกษาพวกเขาและเลือกไม่กี่คนในช่วงเวลาของการสัมภาษณ์

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

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

• btw ฉันเชื่ออย่างเต็มที่ว่าเป็นสิ่งจำเป็นสำหรับนักพัฒนาซอฟต์แวร์ที่จะต้องทำงานอย่างน้อยหนึ่งครั้งด้วยโค้ดที่เกินความหวัง (หรือใกล้เกินความหวัง) บางประเภท คุณเอาตัวรอดจากสิ่งนั้นและทำงานให้ดีนั่นเป็นบทเรียนที่มีค่า

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

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

สิ่งเหล่านี้เป็นสิ่งที่คุณต้องพิจารณาเมื่อ / ถ้าคุณเลือกถามผู้สัมภาษณ์เกี่ยวกับคุณภาพของรหัสและกระบวนการซอฟต์แวร์ของพวกเขา

แทนที่จะเป็นคุณภาพของรหัสที่แท้จริงฉันควรมองหา บริษัท ที่เข้าใจถึงความสำคัญของคุณภาพของรหัส

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

ในทางกลับกันสมมติว่า บริษัท B มีฐานรหัสที่ไม่ดี แต่ฝ่ายบริหารเข้าใจว่าคุณภาพของรหัสทำให้เกิดข้อบกพร่องและความล่าช้าทั้งหมดพวกเขาเห็นความต้องการการเปลี่ยนแปลงและพวกเขายินดีที่จะทำอะไรบางอย่าง (เช่นขนาดใหญ่ refactoring หรือแม้แต่เขียนใหม่) บริษัท นั้นจะปรับปรุงฐานของรหัสและคุณสามารถช่วยพวกเขาทำให้เกิดขึ้น

ฉันรู้ว่าฉันต้องการทำงานที่ไหน

มีโอกาส 99.9% ที่คุณจะไม่สามารถเห็นรหัสได้ก่อนที่จะเริ่ม (เว้นแต่พวกเขาจะออกผลิตภัณฑ์ซอฟต์แวร์ฟรีแน่นอน)

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

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

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

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

ดังนั้นคำถามที่ฉันจะขอให้ประเมินคุณภาพของรหัสคือ:

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

ตามที่ @DPD และ @Zachary กล่าวว่ากระบวนการและ SDLC เป็นปัจจัยที่สำคัญมาก แต่ฉันต้องการเพิ่มปัจจัยอื่น ๆ ที่ตามประสบการณ์ของฉันมีผลกระทบอย่างมีนัยสำคัญต่อคุณภาพของรหัส:

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

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

ทัศนคติของฉันคือสิ่งนี้รหัสคือรหัสถ้าไม่ดีก็เป็นความท้าทายที่จะทำให้ดีขึ้น ถ้ามันดีก็ดีมันเป็นการท้าทายที่ยากยิ่งกว่าที่จะทำให้ดีขึ้น!

สิ่งสำคัญที่สุดสำหรับฉันคือฉันต้องการทำงานกับ บริษัท และคนที่ฉันมีโอกาสมีปฏิสัมพันธ์ด้วยหรือไม่ รหัสสามารถเปลี่ยนแปลงได้คนไม่สามารถ ...

เล็กน้อยติดตลกผมพูดให้สัมภาษณ์กับฉัน

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

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

สิ่งที่ดีคือคุณสามารถมีปัญหาที่ยากที่จะวัดได้

ฉันใช้ปัญหาที่ยากมากเป็นคำถามสัมภาษณ์ครั้งสุดท้ายเพื่อแยกผู้เชี่ยวชาญออกจากสิ่งที่ดีงาม

ความเกี่ยวข้องกับคำถามของ OP คือทุกคนที่ทำการสัมภาษณ์ทางกายภาพจะได้เห็นโค้ดบางส่วน (ไม่ใช่สิ่งใดที่มีเนื้อหาที่เป็นความลับของ บริษัท )

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

แน่นอนว่าคำตอบที่ "เป็นความลับของ บริษัท " คือมาตรฐานคือทั้งหมดม้าตัวเมีย
หลักฐานของฉัน: ที่นายจ้างก่อนหน้าของฉันส่วนที่ไม่เป็นความลับของผลิตภัณฑ์ทางทหารคือตัวอย่างรหัสสำหรับคำถามสัมภาษณ์ [โชคดีไม่ได้รับการจำแนกประเภท]

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

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

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

มีหลายสิ่งที่มีแนวโน้มที่จะเพิ่มคุณภาพของรหัส (แน่นอนไม่มีการรับประกัน)

• การวิเคราะห์แบบสแตติก (ใน. NET นี่คือสิ่งต่าง ๆ เช่น fxcop / stylecop)
• ชุดย่อย (หรือชุดเต็ม) ของชุดทดสอบ - หน่วย / การรวม / การถดถอย / คู่มือ ฯลฯ
• Buddy build (ทีม dev อีกทีมสร้างการเปลี่ยนแปลงเพื่อดูว่ามีปัญหาใด ๆ กับเครื่อง / ผู้ใช้หรือไม่ - บางครั้งก็ใช้สติอย่างรวดเร็วเช่นกัน)
• ตรวจสอบรหัส

สิ่งเหล่านี้สามารถช่วยปรับปรุงไม่เพียง แต่ความแข็งแกร่งของรหัส แต่คุณภาพของรหัส

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

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

นี่เป็นงานที่ยากเพราะมีวิธีการเข้ารหัสที่แตกต่างกันมากมายซึ่งคุณจะไม่สามารถคาดการณ์ทั้งหมดได้

คุณทำไม่ได้โชคไม่ดี ไม่มี บริษัท ไหนที่จะอนุญาตให้คุณเห็นรหัสของพวกเขา (แต่พวกเขาจะขอให้คุณเห็นรหัสของคุณ ... ) และมีโอกาสถ้าคุณถามพวกเขาเกี่ยวกับสภาพแวดล้อมที่คุณจะถูกโกหก ("การควบคุมเวอร์ชัน? เราใช้ .. uhh .. ความคิดย่อย .. บางสิ่งบางอย่าง ") หรือเข้าใจผิดเกี่ยวกับคุณภาพ (" เรากำลังใช้. NET 4 ที่ใหม่ล่าสุดและยิ่งใหญ่ที่สุด "เท่านั้นที่จะพบว่าในขณะที่พวกเขากำลังใช้. NET 4 พวกเขา ' กำลังเขียนเช่น. NET 1.1)

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