หากนายจ้างที่คาดหวังบอกคุณว่าพวกเขา "การแก้ไขข้อผิดพลาดจากภายนอกเนื่องจากผู้พัฒนาเกลียดการแก้ไขข้อบกพร่อง" คุณคิดอย่างไร? คุณมีข้อกังวลอะไร
หากนายจ้างที่คาดหวังบอกคุณว่าพวกเขา "การแก้ไขข้อผิดพลาดจากภายนอกเนื่องจากผู้พัฒนาเกลียดการแก้ไขข้อบกพร่อง" คุณคิดอย่างไร? คุณมีข้อกังวลอะไร
คำตอบ:
แก้ไขข้อบกพร่องของเราเองจริงทำให้เราเป็นนักพัฒนาที่ดีขึ้น และมันเป็นช่วงเวลาที่สนุกสำหรับฉัน โดยเฉพาะอย่างยิ่งเมื่อมีการรายงานอย่างดี
หากพวกเขาไม่ชอบที่จะแก้ไขข้อบกพร่องปัญหาอยู่ที่อื่น
ฉันสงสัยว่าปัญหาคือการรับรู้ข้อบกพร่องของฝ่ายจัดการหรือแย่ลงโดยการตัดสินใจออกแบบที่ไม่ดีและ / หรือไม่มีการทดสอบ (หน่วย) ทำให้เกิดการแก้ไขข้อผิดพลาดที่เจ็บปวด
การแก้ไขข้อผิดพลาดในการเอาท์ซอร์สอาจทำให้เรื่องแย่ลง
นักพัฒนาอาจถูกล่อลวงให้ลดคุณภาพ ใครสน? มีชาวต่างชาติบางคนที่ไปช่วยทำความสะอาด
จนกระทั่งพวกนอกชายฝั่งเข้ามาแทนที่พวกฝั่ง
ลา , วิ่งหนีไปอย่างรวดเร็ว ... และไม่เคยมองย้อนกลับไป ...
ฉันทำงานให้กับ บริษัท ดังกล่าวพวกเขาคิดว่าพวกเขาฉลาด
เฮ้พวกเรามีบั๊กทั้งหมด แต่ผู้อาวุโสของเราบ่นว่าพวกเขาใช้เวลามากเกินไปในการแก้ไขบั๊ก
มาเปิดสำนักงานในต่างประเทศกันเถอะ
สำหรับผู้จัดการที่ฟังดูเหมือนแผนการที่ดีจริงๆและในที่สุด devs ก็มีอิสระในการจัดการงานที่น่าสนใจมากขึ้นในการสร้างสิ่งที่ดีที่สุดต่อไป !!
โฮ ... แต่เดี๋ยวก่อน ...
หลังจากสองปีพวกเขาย้ายจากทีม 5 devs ในสำนักงานใหญ่ของพวกเขาที่จัดการมันทั้งหมดให้กับทีม 2 ที่สร้างสิ่งใหม่และทีม 30 ที่ค้นหาและแก้ไขข้อบกพร่อง
คุณรู้ไหมว่า ... ทีมแก้ไขข้อบกพร่องกำลังดิ้นรนพวกเขาไม่สามารถติดตามได้
สิ่งนี้ทำให้ "ผู้อาวุโส" ไม่สามารถนับได้อย่างสมบูรณ์สำหรับความผิดพลาดของตนเอง ยังเลวร้ายที่สุดเพราะมันเกิดขึ้นจนผู้บริหารไม่ได้ตระหนักถึงและคุณภาพของรหัสได้อย่างรวดเร็วมากจากระดับคุณภาพสุดซึ้งแล้ว
เมื่อฉันออกไปพวกเขาก็เปิดสำนักงานเพิ่มอีกสองแห่งเพื่อแก้ไขข้อผิดพลาดและพวกเขาก็ไม่สามารถติดตาม dev ที่สร้างขึ้นได้ พวกเขาคิดว่าเป็นเพราะคนใหม่ไม่ฉลาดพอ ...
ใช่จากนี้ถ้า บริษัท บอกว่าพวกเขาเอาต์ซอร์ซบั๊กของพวกเขาไปที่สำนักงานในต่างประเทศเชื่อใจฉัน .... ฉันวิ่งเร็ว ...
นี่คือวิธีการจัดการถุงกระดาษ
ยืนบนรถไฟรอรถไฟที่จะมาเมื่อคุณเห็นมันวางถุงกระดาษบนหัวของคุณและ ... POOF .. รถไฟหายไป !! มายากล !
การให้ บริษัท จ่ายเงินให้คนอื่นเพื่อทำความสะอาดความยุ่งเหยิงของฉันดูเหมือนเป็นความคิดที่ดียกเว้นเมื่อฉันคาดว่าจะใช้รหัส 'สะอาด' และเพิ่มคุณสมบัติใหม่ และหากพวกเขาทำให้มันเมาจนไม่สามารถแก้ไขได้คุณจะทำการดีบั๊กการดีบั๊ก
ไม่ได้รับการชดเชยอย่างเพียงพอเพราะพวกเขาต้องจ้างนักพัฒนาเพิ่มเติมไม่พึงประสงค์
ต้องใช้เวลาในการให้ความรู้กับผู้พัฒนารายอื่นอย่างไม่สมส่วนเมื่อคุณสามารถแก้ไขได้ด้วยตัวคุณเองว่าเป็นการต่อต้าน
ส่วนหนึ่งของฉันรู้สึกเหมือนผู้ที่สร้างปัญหาควรเป็นคนที่แก้ไขปัญหาได้หรือไม่มีแรงจูงใจที่จะหลีกเลี่ยงการสร้างข้อบกพร่องในตอนแรก
นักพัฒนาซอฟต์แวร์ไม่สนใจที่จะเรียนรู้จากความผิดพลาดหรือไม่? คุณสามารถแก้ไขข้อบกพร่องโดยไม่มีความรู้เกี่ยวกับโดเมนที่เฉพาะเจาะจงและพันธมิตรเอาต์ซอร์ซมีความรู้นี้หรือไม่? ส่วนการแก้ไขเป็นส่วนที่ง่ายที่สุดส่วนการวิเคราะห์ที่ใช้เวลา จากมุมมองของฉันมันเป็นการตัดสินใจที่โง่
หากนายจ้างที่คาดหวังบอกคุณว่าพวกเขา "การแก้ไขข้อผิดพลาดจากภายนอกเนื่องจากผู้พัฒนาเกลียดการแก้ไขข้อบกพร่อง" คุณคิดอย่างไร? คุณมีข้อกังวลอะไร
ฉันจะวิ่งไกล, ไกล, ไกลออกไป นักพัฒนาอยู่เสมอรับผิดชอบในการแก้ไขข้อบกพร่องของตัวเองอยู่เสมอ การกินอาหารสุนัขเป็นพื้นฐานของวิศวกรรมที่ดี
นอกจากนี้การแก้ไขข้อผิดพลาดก็มีความสำคัญมากกว่าการพัฒนา ฉันหมายถึงการพัฒนาคือการเขียนโค้ดการทดสอบและการดีบัก / แก้ไข
สิ่งที่ฉันได้รับจาก บริษัท นี้คือพวกเขากำลังทำการแก้ไขบั๊กเป็นงานที่สอง ตัวของฉันเองนั้นค่อนข้างน่ารำคาญและฉันก็จะตั้งคำถามกับคุณภาพการทำงานของพวกเขา (และดังนั้น, สภาพแวดล้อมในการทำงานของพวกเขา) ที่น่ารำคาญกว่าคือพวกเขามอบหมายให้พวกเขาทำงานในระดับที่สอง มันรบกวนมากกว่านี้ เห็นได้ชัดว่ามีการแบ่งชั้นทางสังคมประดิษฐานอยู่ในกระบวนการวิศวกรรมของพวกเขา
ข้อบกพร่องมักเกิดจากการเปลี่ยนแปลงที่รูทเสมอและโดยปกติแล้วบั๊กจะเป็นความรับผิดชอบของใครก็ตามที่แนะนำการเปลี่ยนแปลง มีใครดีไปกว่าผู้ริเริ่มที่จะเข้าใจธรรมชาติของข้อบกพร่องและความละเอียดของมัน?
หากได้รับการแต่งตั้งจากทั่วโลกจะมั่นใจได้อย่างไรว่าผู้แต่งดั้งเดิมสามารถใช้ได้กับวิศวกรที่ไม่คุ้นเคย
เขาจะพร้อมใช้งานหรือไม่ปล่อยวิศวกรที่ไม่ได้ทำอะไรเลยนอกจากงานในมือของแมลงและกำหนดส่ง แต่ไม่ได้รับการสนับสนุนจากMetropole ? บุคคลประเภทใดที่สามารถแก้ไขข้อบกพร่องได้หวังว่าจะแสดง ใครแก้ไขข้อบกพร่องของเขา และอะไรทำให้นักพัฒนาของ Metropole ไม่สามารถเรียนรู้ผ่านการแก้ไขบั๊กที่เกิดขึ้นภายหลังได้
มี assholes ในทุกสาขา โดยเฉพาะในซอฟต์แวร์ เนื่องจากเป็นสิ่งที่หลีกเลี่ยงไม่ได้ตัวเลือกเดียวของคุณคือการทำงานกับ assholes ที่รู้มากกว่าคุณหรือกำลังทำสิ่งที่ถูกต้อง บริษัท นี้ดูเหมือนจะไม่เหมาะกับคำอธิบายนั้น
ในระยะสั้นวิ่งหนี
พวกเขาคาดหวังว่านักพัฒนารุ่นน้องนอกชายฝั่งจะสามารถแก้ไขรหัสนักพัฒนาอาวุโสได้หรือไม่ มันเหมือนกับการให้พยาบาลตรวจสอบนักประสาทวิทยาทุกคนทำงานและทำซ้ำในที่ ๆ เขาทำผิดพลาด BAD IDEA!
ฉันจะกังวลว่าพนักงานของพวกเขารู้รหัสที่พวกเขากำลังพัฒนาได้ดีเพียงใด
ฉันยังสงสัยว่าเหตุผลที่มีข้อบกพร่องมากพอที่จะพิสูจน์ค่าใช้จ่ายเพิ่มเติมที่เกิดขึ้น ฉันยังกังวลเกี่ยวกับอนาคตระยะยาวของ บริษัท มีบทความมากมายบนเว็บที่อ้างสิทธิ์ บริษัท เหล่านี้ใช้รหัสเดียวกันสำหรับหลาย ๆ โครงการแม้แต่ในอุตสาหกรรมเดียวกัน
การแก้ไขรหัสที่เสียหายเป็นส่วนหนึ่งของกระบวนการเขียนรหัสซึ่งจะช่วยให้คุณเข้าใจสิ่งที่คุณทำผิดไป 6 เดือนที่ผ่านมาดังนั้นคุณจึงไม่ทำผิดพลาดเหมือนเดิมถ้านักพัฒนาคนอื่นแก้ไขข้อผิดพลาดของคุณอย่างไร ข้อผิดพลาดเกิดขึ้นอีกครั้งและอีกครั้ง?
มันฟังดูคลุมเครือเหมือนนายจ้างคนก่อนของฉันยกเว้นบิต "ผู้คาดหวัง" พวกเขาสูญเสียนักพัฒนาไปสู่การขัดสีและสูญเสียมากเกินไปที่จะสนับสนุนผลิตภัณฑ์ที่มีอยู่ในขณะที่เพิ่มคุณสมบัติใหม่ที่ต้องการโดยการเปลี่ยนแปลงในกฎหมายและข้อบังคับ (60% ของรายได้ของสำนักงานมาจากผลิตภัณฑ์ที่ใช้ VB6 และ MS ระบุว่า VB6 runtimes จะไม่ถูกแจกจ่ายในระบบปฏิบัติการใด ๆ ในอนาคตดังนั้นจะเป็นเช่นนั้นเมื่อ Vista ออกมาซึ่งเป็นช่วงชิงความบ้าคลั่งในการแก้ไขสิ่งต่าง ๆ ) อำนาจที่ต้องการนำ บริษัท ออกสู่สาธารณะในไม่ช้าดังนั้นพวกเขาจึงต้องการทรัพยากรเพื่อทำให้งบดุลดูดีกว่าที่เป็นอยู่ดังนั้นการจ้างงานนอกชายฝั่งจึงเป็นวิธีเดียวที่จะได้อยู่ใกล้ตลาด
จากประสบการณ์ของฉันสิ่งที่พูดว่าเป็นนายจ้างในอนาคตของคุณราคาถูก
มันขึ้นอยู่กับสิ่งที่พวกเขาหมายถึงโดย "แก้ไขข้อบกพร่อง" หากนี่คือการแก้ไขข้อบกพร่องในระหว่างรอบ dev / ทดสอบแล้วมันแปลกมากนี่คืองานสำหรับนักพัฒนาเดิม ในทางกลับกันถ้าหากพวกเขาหมายความว่าพวกเขามีการบำรุงรักษาผลิตภัณฑ์ที่วางจำหน่ายเอาต์ซอร์ซแล้วนี่ไม่ใช่เรื่องผิดปกติและไม่ใช่สิ่งที่ฉันกังวล
ประสบการณ์ของฉันคือการพาทีมภายนอกหลังจากความจริงจะเผาผลาญเวลามากพอ ๆ กับการแก้ไขบั๊กของคุณเอง - พวกเขาต้องเร่งความเร็วและนำเข้าสู่กระบวนการพัฒนา และจากนั้นก็ให้เร่งความเร็วอย่างต่อเนื่อง การประสานงานยากกว่าการเขียนรหัส
ถ้าฉันจะทำงานกับ codebase ฉันต้องการความมั่นใจว่าทุกคนที่มีสิทธิ์ในการกระทำนั้นมีความสามารถพอสมควร ซึ่งรวมถึงบางคนในอินเดียพูด แต่ไม่ใช่คนที่มักจะแตกต่าง
ยิ่งไปกว่านั้นข้อผิดพลาดส่วนใหญ่ของฉันอยู่ในส่วนของโค้ดที่ซับซ้อนกว่าและข้อผิดพลาดเหล่านี้เป็นโปรแกรมเมอร์นอกชายฝั่งที่มีโอกาสน้อยที่จะเข้าใจก่อนที่จะใช้การแก้ไขข้อบกพร่อง
นโยบายนี้มีอยู่จริงในบาง บริษัท ฉันทำงานให้ผู้รับจ้าง ตัวฉันและเพื่อนร่วมงานของฉันเป็นโปรแกรมเมอร์ที่มีความเชี่ยวชาญมากกว่าคนในสถานที่พวกเขาขอให้เราสอนพวกเขาถึงวิธีการใช้เครื่องมือ ฯลฯ แต่อีกด้านหนึ่งคือเราจะพบปัญหาในรหัสของพวกเขาเร็วกว่าที่พวกเขาทำ
โดยทั่วไปโปรแกรมเมอร์ของลูกค้านั้นตั้งอยู่ในอาคารเดียวกันกับผู้ใช้บางคนดังนั้นพวกเขาจึงมีแนวโน้มที่จะได้รับบริบทที่ไม่สามารถเข้าถึงข้ามซีกโลกได้ เราพบว่ามันใช้งานได้ดีส่วนที่ขาดหายไปสำหรับฉันคือพวกเขาไม่ได้ตรวจสอบรหัสของเราดังนั้นเมื่อสัญญาเสร็จสิ้นพวกเขาอาจมีความประหลาดใจหรือคำถามไม่ใช่เพราะการปฏิบัติที่ต่ำในส่วนของเราจำเป็น แต่เป็นปัญหาปกติที่คุณมีเมื่อ เข้ายึดครองโครงการของคนอื่น
ในกรณีใด ๆ ฉันดีใจที่ในกรณีของเรามันไม่ได้เป็นนโยบายอย่างเป็นทางการเช่นนี้ฉันคิดว่ามันจะกัดเซาะโปรแกรมเมอร์ในสถานที่ให้เป็นน้อยกว่า BAs