การแก้ไขบั๊กนอกชายฝั่ง


11

หากนายจ้างที่คาดหวังบอกคุณว่าพวกเขา "การแก้ไขข้อผิดพลาดจากภายนอกเนื่องจากผู้พัฒนาเกลียดการแก้ไขข้อบกพร่อง" คุณคิดอย่างไร? คุณมีข้อกังวลอะไร


1
นักพัฒนาเกลียดการแก้ไขข้อบกพร่อง? ฉันคิดว่าพวกเขาเกลียดการหาวิธีที่เชื่อถือได้ในการทำซ้ำข้อผิดพลาดซึ่งเป็นสิ่งที่ผู้ทดสอบใช้ หากคุณจ้างการแก้ไขข้อผิดพลาดคุณอาจจ้างทีมพัฒนาทั้งหมด ไม่มีใครเข้าใจรหัสเช่นเดียวกับคนที่เขียนมันเอง
Rob

1
ฟังดูเหมือนความคิดที่แย่มาก
Andres F.

1
@AndresF +1 นี้จะสร้างสภาพแวดล้อมที่ devs เพียงแค่โยนอึที่ผนังและหวังว่ามันจะติด ไม่ใช่ปัญหาของพวกเขาหากไม่เป็นเช่นนั้นใช่ไหม
MrFox

คำตอบ:


25

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

หากพวกเขาไม่ชอบที่จะแก้ไขข้อบกพร่องปัญหาอยู่ที่อื่น

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

การแก้ไขข้อผิดพลาดในการเอาท์ซอร์สอาจทำให้เรื่องแย่ลง

นักพัฒนาอาจถูกล่อลวงให้ลดคุณภาพ ใครสน? มีชาวต่างชาติบางคนที่ไปช่วยทำความสะอาด

จนกระทั่งพวกนอกชายฝั่งเข้ามาแทนที่พวกฝั่ง


lol คุณชอบที่จะทำให้ตกใจออกจากคน dontcha
Aditya P

@Aditya: ไม่มีอะไรน่ากลัวนี่คือสิ่งที่เกิดขึ้นกับนายจ้างคนสุดท้ายของฉัน พวกต่างประเทศมีข้อผิดพลาดมากพอที่จะแก้ไขได้ตลอดเวลาและผู้จัดการของพวกเขา (แก้ไขเขา) เริ่มให้การอบรม จนถึงจุดหนึ่งพวกเขาก็ดีพอที่จะเริ่ม refactors ง่าย ๆ ทำความสะอาด ฯลฯ ในเวลาเฉลี่ยในสำนักงานใหญ่ไม่มีอะไรเปลี่ยนแปลง ฉันสามารถเห็นได้อย่างง่ายดายว่าภายในปีหน้าคนต่างชาติจะทำงานส่วนใหญ่และสำนักงานใหญ่ ... อืม ... แย่เกินไปที่พวกเขาไม่เห็นรถไฟกำลังจะมา ;-P
Newtopian

15

ลา , วิ่งหนีไปอย่างรวดเร็ว ... และไม่เคยมองย้อนกลับไป ...

ฉันทำงานให้กับ บริษัท ดังกล่าวพวกเขาคิดว่าพวกเขาฉลาด

  • เฮ้พวกเรามีบั๊กทั้งหมด แต่ผู้อาวุโสของเราบ่นว่าพวกเขาใช้เวลามากเกินไปในการแก้ไขบั๊ก

  • มาเปิดสำนักงานในต่างประเทศกันเถอะ

สำหรับผู้จัดการที่ฟังดูเหมือนแผนการที่ดีจริงๆและในที่สุด devs ก็มีอิสระในการจัดการงานที่น่าสนใจมากขึ้นในการสร้างสิ่งที่ดีที่สุดต่อไป !!

โฮ ... แต่เดี๋ยวก่อน ...

หลังจากสองปีพวกเขาย้ายจากทีม 5 devs ในสำนักงานใหญ่ของพวกเขาที่จัดการมันทั้งหมดให้กับทีม 2 ที่สร้างสิ่งใหม่และทีม 30 ที่ค้นหาและแก้ไขข้อบกพร่อง

คุณรู้ไหมว่า ... ทีมแก้ไขข้อบกพร่องกำลังดิ้นรนพวกเขาไม่สามารถติดตามได้

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

เมื่อฉันออกไปพวกเขาก็เปิดสำนักงานเพิ่มอีกสองแห่งเพื่อแก้ไขข้อผิดพลาดและพวกเขาก็ไม่สามารถติดตาม dev ที่สร้างขึ้นได้ พวกเขาคิดว่าเป็นเพราะคนใหม่ไม่ฉลาดพอ ...

ใช่จากนี้ถ้า บริษัท บอกว่าพวกเขาเอาต์ซอร์ซบั๊กของพวกเขาไปที่สำนักงานในต่างประเทศเชื่อใจฉัน .... ฉันวิ่งเร็ว ...

นี่คือวิธีการจัดการถุงกระดาษ

ยืนบนรถไฟรอรถไฟที่จะมาเมื่อคุณเห็นมันวางถุงกระดาษบนหัวของคุณและ ... POOF .. รถไฟหายไป !! มายากล !


9

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

ไม่ได้รับการชดเชยอย่างเพียงพอเพราะพวกเขาต้องจ้างนักพัฒนาเพิ่มเติมไม่พึงประสงค์

ต้องใช้เวลาในการให้ความรู้กับผู้พัฒนารายอื่นอย่างไม่สมส่วนเมื่อคุณสามารถแก้ไขได้ด้วยตัวคุณเองว่าเป็นการต่อต้าน

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


6

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


6

หากนายจ้างที่คาดหวังบอกคุณว่าพวกเขา "การแก้ไขข้อผิดพลาดจากภายนอกเนื่องจากผู้พัฒนาเกลียดการแก้ไขข้อบกพร่อง" คุณคิดอย่างไร? คุณมีข้อกังวลอะไร

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

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

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

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

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

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

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

ในระยะสั้นวิ่งหนี


2
"นอกจากนี้การแก้ไขข้อผิดพลาดก็มีความสำคัญมากกว่าการพัฒนา" ฉันรู้ว่าคุณหมายถึงที่นั่น แต่ฉันจะไปไกลเท่าที่จะพูด: ฉันไม่สามารถหยั่งรู้ถึงขั้วสองขั้วใด ๆ การแก้ไขข้อผิดพลาดเป็นลักษณะพื้นฐานที่แท้จริงของการพัฒนา
Dan Ray

1
@Dan - ใช่คำสั่งของคุณถูกต้องมากขึ้น ไม่มีขั้วคู่นี้
luis.espinal

4

พวกเขาคาดหวังว่านักพัฒนารุ่นน้องนอกชายฝั่งจะสามารถแก้ไขรหัสนักพัฒนาอาวุโสได้หรือไม่ มันเหมือนกับการให้พยาบาลตรวจสอบนักประสาทวิทยาทุกคนทำงานและทำซ้ำในที่ ๆ เขาทำผิดพลาด BAD IDEA!


3

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

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


3

มันฟังดูคลุมเครือเหมือนนายจ้างคนก่อนของฉันยกเว้นบิต "ผู้คาดหวัง" พวกเขาสูญเสียนักพัฒนาไปสู่การขัดสีและสูญเสียมากเกินไปที่จะสนับสนุนผลิตภัณฑ์ที่มีอยู่ในขณะที่เพิ่มคุณสมบัติใหม่ที่ต้องการโดยการเปลี่ยนแปลงในกฎหมายและข้อบังคับ (60% ของรายได้ของสำนักงานมาจากผลิตภัณฑ์ที่ใช้ VB6 และ MS ระบุว่า VB6 runtimes จะไม่ถูกแจกจ่ายในระบบปฏิบัติการใด ๆ ในอนาคตดังนั้นจะเป็นเช่นนั้นเมื่อ Vista ออกมาซึ่งเป็นช่วงชิงความบ้าคลั่งในการแก้ไขสิ่งต่าง ๆ ) อำนาจที่ต้องการนำ บริษัท ออกสู่สาธารณะในไม่ช้าดังนั้นพวกเขาจึงต้องการทรัพยากรเพื่อทำให้งบดุลดูดีกว่าที่เป็นอยู่ดังนั้นการจ้างงานนอกชายฝั่งจึงเป็นวิธีเดียวที่จะได้อยู่ใกล้ตลาด

จากประสบการณ์ของฉันสิ่งที่พูดว่าเป็นนายจ้างในอนาคตของคุณราคาถูก


+1 สำหรับการมีงานที่แย่ที่สุดเท่าที่เคยมีมา ดูเหมือนว่าพวกเขาจะไม่ใช้รายได้นั้นกลับเข้ามาในโครงการมากพอ
Ramhound

ยกเว้นบิต "ผู้ที่จะเป็นพนักงานจ้าง" บิต <LOL
Greg B

ฉันสังเกตเห็นวลี "นายจ้างก่อนหน้า" ขอแสดงความยินดี
David Thornley

@Ramhound, David, Greg, เป็นสถานที่ที่ดีขึ้นเมื่อฉันเริ่มฉันออกจากสถานที่ในปลายเดือนธันวาคม (ไม่นานหลังจากครบรอบ 5 ปีของฉัน) ไม่มีใครได้รับการว่าจ้างมาตั้งแต่ฉันได้รับการว่าจ้างและในช่วง 2 ปีที่ผ่านมามีนักพัฒนา 6 คนที่ลาออก คนที่ออกเดินทางครั้งล่าสุดนั้นอยู่ที่นั่น 11 ปี
Tangurena

3

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


จุดดีไม่มีใครมองเห็นมุมนั้น
เกร็ก B

@Greg & Steve - ฉันไม่เชื่อว่ามันจะซื่อสัตย์ หากพวกเขากำลังแก้ไขข้อผิดพลาดในการบอกว่าเป็นรุ่นที่วางจำหน่ายแล้วการแก้ไขเหล่านั้นจะรวมเข้ากับการสร้างแบบทดสอบได้อย่างไรถ้านักพัฒนาไม่ได้เขียนข้อผิดพลาดแก้ไขตัวเอง
Ramhound

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

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

2

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


1

ถ้าฉันจะทำงานกับ codebase ฉันต้องการความมั่นใจว่าทุกคนที่มีสิทธิ์ในการกระทำนั้นมีความสามารถพอสมควร ซึ่งรวมถึงบางคนในอินเดียพูด แต่ไม่ใช่คนที่มักจะแตกต่าง

ยิ่งไปกว่านั้นข้อผิดพลาดส่วนใหญ่ของฉันอยู่ในส่วนของโค้ดที่ซับซ้อนกว่าและข้อผิดพลาดเหล่านี้เป็นโปรแกรมเมอร์นอกชายฝั่งที่มีโอกาสน้อยที่จะเข้าใจก่อนที่จะใช้การแก้ไขข้อบกพร่อง


1

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

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

ในกรณีใด ๆ ฉันดีใจที่ในกรณีของเรามันไม่ได้เป็นนโยบายอย่างเป็นทางการเช่นนี้ฉันคิดว่ามันจะกัดเซาะโปรแกรมเมอร์ในสถานที่ให้เป็นน้อยกว่า BAs

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