Sửa lỗi ngoài khơi

Nếu một nhà tuyển dụng tiềm năng nói với bạn rằng họ "sửa lỗi bên ngoài vì các nhà phát triển ghét sửa lỗi", bạn sẽ nghĩ gì? Điều gì có thể là mối quan tâm của bạn?

Sửa lỗi của chúng ta thực sự làm cho chúng ta trở thành một nhà phát triển tốt hơn . Và đó là một khoảnh khắc khá thú vị đối với tôi. Đặc biệt là khi chúng được báo cáo độc đáo.

Nếu họ không muốn sửa lỗi, vấn đề nằm ở chỗ khác.

Tôi nghi ngờ vấn đề là làm thế nào các lỗi được quản lý cảm nhận hoặc tệ hơn, bởi các quyết định thiết kế tồi và / hoặc không (đơn vị) kiểm tra, gây ra lỗi sửa lỗi đau đớn.

Sửa lỗi bên ngoài có thể sẽ làm cho điều tồi tệ hơn.

Các nhà phát triển có thể bị cám dỗ để làm giảm chất lượng. Ai quan tâm? Một số kẻ ở nước ngoài đang ở đó để dọn dẹp mớ hỗn độn của họ.

Cho đến khi những kẻ ngoài khơi thay thế những kẻ trên bờ.

Rời đi , chạy đi ... nhanh và không bao giờ nhìn lại ...

Tôi đã làm việc cho một công ty như vậy, họ nghĩ rằng họ thông minh,

• này, chúng tôi có tất cả các lỗi nhưng người cao niên của chúng tôi phàn nàn rằng họ dành quá nhiều thời gian để sửa lỗi.

• hãy mở một văn phòng ở nước ngoài và để những người khác giải quyết việc này.

Đối với một người quản lý có vẻ như là một kế hoạch thực sự tốt và các nhà phát triển cuối cùng đã được giải phóng để giải quyết nhiệm vụ thú vị hơn là tạo ra thứ tốt nhất tiếp theo !!

ho ... nhưng đợi đã ...

Sau hai năm, họ đã đi từ một nhóm 5 nhà phát triển trong văn phòng chính của họ, người đã xử lý tất cả cho một nhóm 2 người tạo ra công cụ mới và một nhóm 30 người tìm và sửa lỗi.

bạn biết những gì ... nhóm sửa lỗi đang gặp khó khăn, họ không thể theo kịp.

điều này làm cho "người cao niên" hoàn toàn không thể vượt qua vì những sai lầm của chính họ. Tệ nhất vẫn còn, bởi vì tất cả đã xảy ra cho đến nay, ban quản lý cũng không nhận ra và chất lượng mã đã được xử lý RẤT nhanh chóng từ mức chất lượng đã quá tệ.

Khi tôi rời đi, họ đã mở thêm hai văn phòng cho người sửa lỗi và họ vẫn không thể theo kịp các nhà phát triển chỉ tạo ra chúng. họ thực sự nghĩ rằng đó là vì những người mới không đủ thông minh ...

vì vậy, từ bây giờ, nếu một công ty nói rằng họ đã thuê ngoài sửa lỗi cho một văn phòng ở nước ngoài tin tưởng tôi .... tôi chạy ... nhanh.

Đây là phương pháp quản lý Túi giấy .

Đứng trên đường sắt, đợi một chuyến tàu đến, khi bạn nhìn thấy nó, đặt một cái túi giấy trên đầu và ... POOF .. chuyến tàu đã biến mất !!. Ma thuật !

Việc công ty trả tiền cho người khác để dọn dẹp mớ hỗn độn của tôi nghe có vẻ là một ý tưởng hay trừ khi tôi dự kiến ​​sẽ lấy mã 'sạch' của họ và thêm các tính năng mới. Và nếu họ làm hỏng nó đến mức họ không thể sửa nó, bạn sẽ gỡ lỗi.

Không được bồi thường thỏa đáng vì họ phải thuê thêm các nhà phát triển là điều không mong muốn.

Phải dành một lượng thời gian không cân xứng để giáo dục các nhà phát triển khác khi bạn có thể tự sửa nó là phản tác dụng.

Một phần trong tôi cảm thấy như những người tạo ra vấn đề nên là người khắc phục chúng hoặc không có động cơ để tránh tạo ra lỗi ngay từ đầu.

Là các nhà phát triển không quan tâm đến việc học hỏi từ những sai lầm của họ? Bạn có thể sửa lỗi mà không có kiến ​​thức tên miền cụ thể và đối tác gia công có kiến ​​thức này không? Phần sửa lỗi là phần dễ nhất hầu hết thời gian, phần phân tích mất thời gian. Từ quan điểm của tôi đó là một quyết định ngu ngốc.

Nếu một nhà tuyển dụng tiềm năng nói với bạn rằng họ "sửa lỗi bên ngoài vì các nhà phát triển ghét sửa lỗi", bạn sẽ nghĩ gì? Điều gì có thể là mối quan tâm của bạn?

Tôi sẽ chạy thật xa, thật xa, thật xa. Một nhà phát triển luôn luôn, luôn luôn, luôn có trách nhiệm sửa các lỗi của mình. Ăn thức ăn cho chó là một nguyên lý cơ bản của kỹ thuật tốt.

Hơn nữa, sửa lỗi cũng quan trọng, có lẽ còn hơn cả phát triển. Ý tôi là, phát triển là viết mã, kiểm tra và sửa lỗi / sửa lỗi.

Những gì tôi nhận được từ công ty này là họ đang coi sửa lỗi là một nhiệm vụ hạng hai. Điều đó tự nó khá đáng lo ngại và tôi đánh giá cao chất lượng công việc của họ (và ergo, môi trường làm việc của họ.) Đáng lo ngại hơn là họ ủy thác những gì cho họ là công việc hạng hai cho công nhân ở nước ngoài. Điều đó đáng lo ngại hơn. Rõ ràng có sự phân tầng xã hội được ghi nhận trong quá trình kỹ thuật của họ.

Một khiếm khuyết luôn là nguyên nhân dẫn đến sự thay đổi và thông thường lỗi là trách nhiệm của bất kỳ ai giới thiệu thay đổi. Ai tốt hơn người khởi tạo để hiểu bản chất của lỗi và độ phân giải của nó?

Nếu nó được ủy quyền trên toàn thế giới, làm thế nào để đảm bảo rằng tác giả gốc có sẵn cho các kỹ sư bị bỏ rơi?

Anh ta thậm chí sẽ có mặt, để lại kỹ sư thiếu sót, người không có gì ngoài việc tồn đọng các lỗi và thời hạn, nhưng không có sự hỗ trợ từ Metropole ? Loại sửa lỗi nào mà một người có thể hy vọng thực hiện? Ai sửa lỗi của mình? Và điều gì ngăn cản các nhà phát triển của Metropole học hỏi thông qua sửa lỗi sau khi chết?

Có lỗ đít trong tất cả các lĩnh vực. Điều này đặc biệt đúng trong phần mềm. Vì đó là điều không thể tránh khỏi, lựa chọn duy nhất của bạn là làm việc với những kẻ khốn nạn biết nhiều hơn bạn hoặc đang làm việc đúng đắn. Công ty này dường như không phù hợp với mô tả đó.

Tóm lại, chạy đi.

Họ có thực sự mong đợi một loạt các nhà phát triển cơ sở ngoài khơi có thể sửa chữa một loạt các mã nhà phát triển cao cấp không? Nó giống như có một y tá kiểm tra lại tất cả các nhà thần kinh học làm việc và làm lại nó ở nơi anh ta làm điều sai lầm. Ý TƯỞNG!

Tôi sẽ quan tâm đến việc nhân viên của họ thực sự biết mã họ đang phát triển như thế nào.
Tôi cũng sẽ tự hỏi lý do có đủ lỗi để biện minh cho các chi phí gia tăng mà điều này mang lại. Tôi cũng sẽ lo lắng về tương lai lâu dài của công ty, có rất nhiều bài viết trên web tuyên bố các công ty này, sử dụng cùng một mã cho nhiều dự án ngay cả trong cùng một ngành.

Sửa mã bị hỏng là một phần của quá trình viết mã, nó cho phép bạn hiểu rõ hơn về những gì bạn đã làm sai 6 tháng trước, vì vậy bạn không mắc lỗi tương tự, nếu một số nhà phát triển khác sửa lỗi của bạn, làm thế nào để bạn ngăn chặn điều đó lỗi từ xảy ra nhiều lần?

Điều này nghe có vẻ mơ hồ giống như chủ nhân trước đây của tôi, ngoại trừ bit "chủ nhân tương lai". Họ đã mất các nhà phát triển để tiêu hao và mất quá nhiều để hỗ trợ các sản phẩm hiện có trong khi thêm các tính năng mới theo yêu cầu của các thay đổi trong luật và quy định (60% doanh thu của văn phòng đến từ một sản phẩm dựa trên VB6, và MS đã tuyên bố rằng thời gian chạy của VB6 sẽ không được phân phối trong bất kỳ hệ điều hành nào trong tương lai, vì vậy nó sẽ giống như khi Vista ra mắt - một cuộc tranh giành điên rồ để sửa chữa mọi thứ). Các cường quốc muốn sớm đưa công ty ra công chúng, vì vậy họ đang bỏ đói mọi người để có được nguồn lực để làm cho bảng cân đối kế toán tốt hơn - vì vậy thuê ngoài khơi là cách duy nhất để đến gần thị trường.

Dựa trên kinh nghiệm của tôi, những gì trích dẫn nói là nhà tuyển dụng tiềm năng của bạn rẻ.

Nó phụ thuộc vào ý nghĩa của chúng bằng cách "sửa lỗi". Nếu đây là sửa lỗi trong chu kỳ dev / test thì nó rất kỳ quặc, đây là công việc dành cho các nhà phát triển ban đầu. Mặt khác, nếu họ có nghĩa là họ đã thuê ngoài bảo trì một sản phẩm được phát hành thì điều này không phải là bất thường và không phải là điều tôi lo lắng.

Kinh nghiệm của tôi là việc đưa vào một nhóm bên ngoài sau khi thực tế sẽ đốt cháy nhiều thời gian như việc sửa các lỗi của riêng bạn - chúng cần được đưa lên để tăng tốc và đưa vào quá trình phát triển. Và sau đó giữ tốc độ liên tục. Phối hợp khó hơn viết mã.

Nếu tôi sẽ làm việc trên một cơ sở mã, tôi muốn một số đảm bảo rằng mọi người có đặc quyền cam kết đều có năng lực hợp lý. Điều này bao gồm khá nhiều người ở Ấn Độ, nói, nhưng không phải là những người thường bị coi thường.

Hơn nữa, hầu hết các lỗi của tôi đều nằm trong các phần mã phức tạp hơn và đó là những lỗi mà lập trình viên nước ngoài ít có khả năng hiểu được trước khi áp dụng sửa lỗi.

Chính sách này thực sự tồn tại trong tiềm thức ở một số công ty. Tôi làm việc cho một người đăng việc; Bản thân tôi và các đồng nghiệp của tôi là những lập trình viên thành thạo hơn những người tại chỗ, họ yêu cầu chúng tôi dạy họ cách sử dụng các công cụ, v.v., nhưng mặt khác là chúng tôi sẽ phát hiện ra các vấn đề trong mã của họ nhanh hơn họ.

Nói chung, các lập trình viên của khách hàng có vị trí thực tế trong cùng tòa nhà với ít nhất một số người dùng, vì vậy họ có nhiều khả năng có được bối cảnh không đến được khắp các bán cầu. Chúng tôi thấy nó hoạt động tốt, phần còn thiếu đối với tôi là họ không xem xét mã của chúng tôi nên khi hợp đồng kết thúc, họ có thể có một số bất ngờ hoặc câu hỏi, không phải do bất kỳ thực hành kém chất lượng nào của chúng tôi mà chỉ là những vấn đề thông thường bạn gặp phải khi tiếp quản dự án của người khác.

Trong mọi trường hợp, tôi mừng vì trong trường hợp của chúng tôi, đó không phải là một chính sách chính thức, vì vậy tôi nghĩ rằng nó sẽ làm xói mòn các lập trình viên tại chỗ để ít hơn BA.