ช่วยโปรแกรมเมอร์ผู้น้อยให้ผ่านข้อบกพร่องของพวกเขา? [ปิด]

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

ฉันไม่ได้หมายถึงทักษะระหว่างบุคคลเช่น 'การฟังคำแนะนำ' ฉันหมายถึงเรื่องทางเทคนิคเช่น (ถ้ามี):

• 'คุณไม่เคยทำ SQL ใช่ไหม'

• 'คุณไม่เคยเขียนการทดสอบหน่วยหรือไม่'

• 'คุณไม่รู้ว่าจะใช้คำสั่ง Unix ได้อย่างไร'

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

ไม่ทราบว่าการควบคุมเวอร์ชันเป็นหรือวิธีการใช้อย่างถูกต้อง

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

ไม่ได้ถามคำถามมากพอ

ฉันรู้ว่าพวกเขาเป็นรุ่นน้องฉันคาดหวังว่าพวกเขาจะทำผิดพลาดและไม่รู้อะไรเลย ราชวงศ์ f ** k จำนวนมากสามารถหลีกเลี่ยงได้โดยเพียงแค่ถามคำถามแทนที่จะคิดอะไรบางอย่าง สุจริตฉันไม่สามารถรบกวนได้มากพอ

ฉันมีตันของคำถามที่เมื่อผมเริ่มออก - ขอให้พวกเขาบันทึกตูดของฉันอยู่กับจำนวนของโอกาส เฮ้ฉันยังมีคำถามอีกมากมาย ... ฉันแค่อยากจะคิดว่ามันเป็นคำถามที่ดีกว่าตอนนี้

คัดลอกวางและทดลองใช้และข้อผิดพลาดแทนที่จะพยายามทำความเข้าใจพื้นฐานที่สำคัญ

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

การเก็บรหัส "ร่างแรก" ไว้

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

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

เชื่อว่าคุณเป็นคนแรกที่ประสบสถานการณ์

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

แก้ไข :

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

คิดว่าพวกเขารู้ทุกอย่าง

ฉันมี jr นักศึกษาฝึกงานที่พยายามแก้ไขทุกสิ่งด้วย javascript พยายามอธิบายแนวคิดหลายอย่าง แต่เขาคิดเสมอว่าเขาทำได้ดีกว่า ตอนนี้เขาเลิกและฉันกลับไปทำงานโปรแกรมหลักที่เขาสร้างขึ้นมาเพื่อพิมพ์งานโดยใช้ HTML แทนที่จะเป็นเทคโนโลยีที่พร้อมสำหรับการพิมพ์เช่น PDF ไม่ต้องพูดถึงปัญหาสำคัญอื่น ๆ

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

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

ไม่ต้องการที่จะเพิ่มพูนความรู้ - ใช้เส้นทางของการต่อต้านน้อยที่สุดแทน

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

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

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

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

ไม่เข้าใจ OOP น่าเศร้าที่มันเป็นเรื่องธรรมดามากกว่าที่พวกเราส่วนใหญ่อาจตระหนัก

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

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

• การดมกลิ่น: การล่วงละเมิดทางมรดก - ภัยของการสืบทอด
• แนวคิดเรื่อง "องค์ประกอบของความโปรดปรานเหนือมรดก" นี้มาจากไหน? - ภัยของการหลีกเลี่ยงการสืบทอด

ไม่รู้ว่าคุณไม่รู้อะไรและไม่รู้ว่าคุณรู้ทุกสิ่ง

(และลูกพี่ลูกน้องที่ใกล้ชิดไม่ต้องการถาม)

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

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

นี่คือคำถามสัมภาษณ์ที่ฉันใช้ว่าโปรแกรมเมอร์รุ่นเยาว์เกือบทั้งหมดคิดถึงสิ่งสำคัญ:

เขียนรหัสที่คำนวณหมายเลขNth Fibonacci

พวกเขามักจะเขียนให้ชัดเจนที่สุด แต่ไม่มีประสิทธิภาพมากที่สุด

int Fib(int n)
{
    if (n == 0) return 0;
    if (n == 1) return 1;
    return Fib(n-2) + Fib(n-1);
}

เมื่อถูกถามให้แสดงความคิดเห็นเกี่ยวกับความซับซ้อนของอัลกอริทึมฉันมักจะได้รับ "มันแย่กว่า O (N) ... เอ่อ ... O (N logN)" จริงๆแล้วมันแย่กว่านั้นมาก

ทำการเยื้องรหัสข้างหลัง!

แน่นอนว่ามันไม่ "ปกติ" มากนัก ฉันไม่เคยเชื่อเลยว่ามันจะเป็นไปได้ แต่สิ่งที่นักพัฒนาทั่วไปจะชอบเขียน

try {
    switch(action){
        case case1:
            ...
            break;
        case case2:
            ...
            break;
        default:
            break;
    }
}
catch(Exception e) {
    e.printStackTrace();
}

เธอจะเขียนเหมือน (พระเจ้ามันก็ดูเหมือนเป็นไปไม่ได้สำหรับฉัน!)

            try {
        switch(action){
    case case1:
...
break;
    case case2:
...
break;
    default:
break;
        }
            }

น่าผิดหวังใช่ไหม