Xử lý đồng nghiệp cổ của tôi

Tôi là một lập trình viên khá trẻ và tôi làm việc tại một bộ phận CNTT của công ty cỡ trung bình. Tôi có một đồng nghiệp, và anh ấy là một lập trình viên Visual Basic 6 thực sự giỏi. Và tôi có nghĩa là thực sự tốt. Thành thật. Anh ta có thể cung cấp các ứng dụng hoạt động, chứa rất ít lỗi, trong thời gian tôi cần lấy tách cà phê đầu tiên và khởi động máy. Anh ấy chỉ là tốt.

Điều đó là, chúng tôi đang làm việc với một nhóm, và phong cách làm việc của anh ấy hoàn toàn lỗi thời. Anh ta không tin vào phần mềm phiên bản (nếu bạn chỉ chắc chắn rằng mã của mình là chính xác, bạn không cần tất cả những thứ vô nghĩa đó). Không tin vào việc triển khai (Tôi có thể cung cấp một tệp thực thi đang hoạt động. Cách triển khai là để các sysadins tìm ra). Không tin vào sự trừu tượng. . 'Hoặc' yeah, chắc chắn bạn có thể sử dụng thư viện đó để làm điều đó cho bạn, nhưng theo cách đó bạn không thực sự hiểu chuyện gì đang xảy ra ') và chắc chắn không tin vào OOP. (chúng tôi làm việc trong VB.net)

Anh ấy rất giỏi trong những gì anh ấy làm, anh ấy có thể cung cấp các ứng dụng nhanh hơn tôi có thể. Nhưng nó chỉ không hoạt động trong một nhóm. Thành viên khác trong nhóm của chúng tôi im lặng và không muốn nói ra, mặc dù anh ấy có xu hướng đồng ý. Người quản lý của chúng tôi nghĩ rằng tôi đưa ra các điểm hợp lệ, nhưng không phải là một lập trình viên.

Tôi có một thời gian thực sự khó khăn để duy trì các chương trình anh ấy đã viết, và nó không tạo ra một bầu không khí nhóm tốt. Bạn nghĩ điều gì là tốt nhất cho tôi để làm gì?

Điều này nghe có vẻ như một trong những người "Anh ấy là một người tốt nhưng ..." nơi bạn biết sự thật đang đến. Và sự thật có vẻ như anh ta không phải là một kỹ sư giỏi. Phần mềm tốt không chỉ là về tốc độ làm việc và phát triển. Đó cũng là về những điều khác mà bạn đã đề cập - khả năng duy trì, khả năng tương thích, trừu tượng hóa (cho hiệu quả trong tương lai), v.v.

Vì vậy, điều đó đang được nói, có vẻ như bạn có một nhà phát triển vấn đề trong tay của bạn. Điều tồi tệ hơn với bạn là anh ấy đã được chứng minh và có thể theo cách của anh ấy. vậy, bạn có thể làm gì?

• Làm việc xung quanh anh ta.
• Phấn đấu để sản xuất các dự án của bạn theo một lịch trình chặt chẽ như anh ấy làm.
• Và nếu bạn không thể, tạo ra một kết quả tốt hơn .
• Theo thời gian những khái niệm đã được chứng minh mà anh ta gạt bỏ sẽ bắt đầu trả giá cho bạn.

Mặt khác, nếu bạn buộc phải làm việc theo cách của mình, hãy rời đi.

Đừng cố gắng thay đổi đồng nghiệp của bạn. Bạn đang mô tả anh ta như một người có thể cung cấp phần mềm làm việc. Có lẽ đã quá muộn để tích hợp nó vào đội.

Vì vậy, bạn có hai lựa chọn:

• Thích nghi với chính mình. Có lẽ với thời gian bạn sẽ có thể thuyết phục anh ta về tiện ích của một hệ thống kiểm soát nguồn? Bạn sẽ phải tăng vòng tròn ảnh hưởng của bạn . Anh ấy càng chống lại sự thay đổi, bạn sẽ càng cần nhiều thời gian hơn.

• Loại bỏ bản thân khỏi team. Bạn có rất nhiều điểm để biện minh cho điều này. Có lẽ bạn nên để nó duy trì các ứng dụng của riêng mình và cống hiến hết mình cho những thứ mới.

• Loại bỏ bản thân khỏi company. Đôi khi, đây là giải pháp duy nhất.

Nếu tôi là bạn, tôi sẽ thiết lập hệ thống kiểm soát nguồn của riêng mình ngay bây giờ. Bắt đầu sử dụng nó cho mọi thứ bạn viết mã và quản lý nó để các thành viên khác trong nhóm của bạn có tài khoản và có thể truy cập nó. Các đồng nghiệp khác của bạn có thể sẽ nhiệt tình sử dụng nó.

Đồng nghiệp của bạn, những người không tin vào những thực hành như vậy có thể không dễ thuyết phục. Tuy nhiên, bất kỳ mã nào mà bạn buộc phải làm việc với nó được viết bởi anh ta nên đi vào kiểm soát phiên bản để bạn có thể làm việc với nó. Khi anh ấy cần quyền truy cập vào các thay đổi của bạn, hãy gửi cho anh ấy một bước đơn giản từng bước hướng dẫn về cách kéo mã của bạn khỏi kho lưu trữ.

Bạn không cần phải hiếu chiến hoặc vượt lên trên anh ấy để khiến anh ấy tham gia vào các quy trình hiện đại hơn. Đôi khi chỉ cần đi theo cách riêng của bạn và trở thành một nhà lãnh đạo bằng hành động có hiệu quả hơn là cố gắng thuyết phục ai đó bằng lời nói. Bước chân em bé. Nếu anh ta bắt đầu phản ứng nhanh hơn với kiểm soát phiên bản, hãy bắt đầu tái cấu trúc các chương trình con và thêm các bài kiểm tra đơn vị để bảo vệ chống lại các thay đổi. Tự động hóa các bài kiểm tra và cho anh ấy thấy làm thế nào anh ấy có thể truy cập kết quả ngay khi anh ấy thực hiện đăng ký.

Rất nhiều lần mọi người chỉ kháng cự vì họ không thích thay đổi. Nhưng nếu những thay đổi được trình bày cho họ theo cách dần dần và theo cách giúp họ dễ dàng theo dõi, thường thì họ sẽ thấy lợi ích rất nhanh.

Trên tất cả, làm cho tất cả đơn giản nhất có thể cho anh ta (Keep It Simple St ngu). Cho phép anh ta bắt đầu làm theo những thực hành này theo các điều khoản của riêng mình. Nhưng đừng để nó kéo bạn xuống.

Tôi sẽ thành thật, bạn không vẽ một bức tranh đẹp về anh ấy. Phương pháp cổ xưa, phần mềm khó bảo trì, cứng đầu với cách làm việc mới, chống lại sự trừu tượng, v.v.

Từ những gì bạn đã nói, nếu anh ta sản xuất phần mềm không có lỗi phần lớn FASTER hơn bạn mà không sử dụng các thư viện có thể tái sử dụng và các mẫu thiết kế nhằm phát triển ứng dụng nhanh thì nó nói nhiều hơn về bản thân bạn, hơn anh ta ...

..about anh ấy..yeh, tìm cách KHÔNG làm việc với anh ấy và KHÔNG được liên kết với công việc của anh ấy. Có vẻ như anh ta có một thái độ ích kỷ điển hình đối với công việc của mình. Bạn không thể làm việc với một người như vậy, bạn chỉ có thể quan sát họ làm việc và dọn dẹp sau khi họ (giống như bạn hiện tại).

Tôi đã thấy điều này trước đây ,

Và tôi gần như sẵn sàng đặt cược: Kiểu anh chàng này chỉ xuất hiện "nhanh" bởi vì anh ta có một bộ "mẫu" đã thử và thử nghiệm trong đầu. 99% ứng dụng Line of Business là CRUD , những thứ cơ bản.

Anh ta có thể sử dụng một tấn Copy & Paste từ mã hiện có của mình (không có gì sai với điều đó).

Nhưng..

Khoảnh khắc anh gặp bất cứ thứ gì phức tạp từ xa, nó rơi xuống, tại sao? bởi vì nó không còn phù hợp với bất kỳ "mẫu" cơ bản nào.

Một thử thách nhỏ ...

Tôi sẽ tạo một dự án ở bên cạnh, một dự án phức tạp thực sự được hưởng lợi từ OOP và sử dụng lại mã.

Sau đó cho anh ta xem dự án đó và yêu cầu anh ta thực hiện tính năng này cho tính năng.

Sau đó tôi muốn đặt mã rằng mã của anh ta gần như chắc chắn sẽ lớn hơn gấp 10 lần và xấu hơn gấp 10 lần nếu anh ta thực hiện theo cách của mình.

Nhìn vào điều này từ phía doanh nghiệp.

Bạn mất nhiều thời gian hơn để sản xuất mã buggier. Bạn tạo ra doanh thu ít hơn do đó bạn hút.

Nếu theo thời gian, bạn có thể đảo ngược điều này thì bạn có thể đảo ngược điều này.

Nhưng có lẽ, chỉ có thể, lập trình viên cổ xưa này thực sự có thể dạy cho bạn một vài điều về việc sản xuất mã một cách nhanh chóng mà không có lỗi? Có lẽ kỹ thuật của anh ấy không quá cũ như bạn nghĩ?

Tôi thấy nghi ngờ rằng ai đó có thể tạo ra mã tuyệt vời như vậy mà không có một số thực tiễn rất tốt. Bạn có thể học những thực hành đó và áp dụng chúng vào "những thực tiễn tốt nhất" và những điều hợp thời trang mà bạn hiểu.

Nếu người quản lý của bạn không phải là một lập trình viên hãy thử và đưa nó vào những điều mà anh ta sẽ hiểu.

• Chúng ta nên sử dụng sourecontrol vì nếu không, chúng ta có thể gặp vấn đề lớn khi phục hồi

• Tôi mất x thời gian lâu hơn vì anh ta từ chối tuân theo một số quy trình khá cơ bản.

Mặt khác, đảm bảo bạn không bị cuốn vào sự hoàn hảo, nghĩa là đây là cách tốt nhất chúng ta phải tuân theo. Có khả năng đồng nghiệp của bạn có rất nhiều điều để thêm vào, bạn có thể phải đẩy anh ta đi đúng hướng từ từ.

Có vẻ như đồng nghiệp của bạn chưa bao giờ phát triển trong một nhóm. Đó là loại đối tác độc tấu guru không cho phép một nhóm năng động. Vì vậy, hãy nói với cấp trên của bạn về nó và cố gắng thảo luận về pro và nhược điểm với fevor đối tác của bạn làm điều đó. Nếu bạn có thể làm điều đó một cách tuyệt vời hơn, nhưng nếu anh ta từ chối, hãy đi lên trong bộ chỉ huy

Nói chuyện với người quản lý của bạn, đơn giản và đơn giản như bạn đã làm ở đây. Có tiềm năng phát triển ở đây - nếu đồng nghiệp của bạn giỏi như bạn nói thì anh ta không nên thuyết phục anh ta để khiến anh ta bắt đầu chuyển đổi sang sử dụng kiểm soát nguồn và .Net với các khái niệm OO thích hợp.

Tôi sẽ nói chuyện với những người khác để có được bức tranh rộng hơn về cách mọi thứ nhìn vào nơi bạn đang ở. Có lẽ có một số sự tách biệt ở đó để mã của anh ta không phải trộn quá nhiều với những người khác vì có khả năng phân tách anh ta vào khu vực của anh ta theo một cách mà điều này có thể được xử lý mặc dù điều này là cao hơn như giám đốc hoặc CIO để thực hiện chứ không phải là một nhà phát triển.

Bạn có thể muốn nói chuyện với anh ta để xem anh ta đã xây dựng loại hệ thống lớn nào vì có một số hệ thống doanh nghiệp lớn có xu hướng nhiều khối xây dựng nơi mã spaghetti có thể chạy vào vùng đất, "Ồ, đó là lý do tại sao OOP có thể tốt!" mặc dù điều này đôi khi xảy ra trong trường hợp nó tỏ ra khá hữu ích để xem làm thế nào điều này có thể là một điều hữu ích cần có trong hộp công cụ của một người.

Sự thờ ơ có thể là một nghi phạm khác để xem liệu đó có phải là lý do tại sao anh ta từ chối một số điều mà tôi cho là gần với cơ bản về cách tôi có xu hướng thiết kế mã nhưng sau đó có lẽ tôi đã sử dụng quá nhiều công cụ hỗ trợ Kool.

Thách thức anh ấy (một cách tốt) để chứng minh bạn khác, cho anh ấy thấy khía cạnh tuyệt vời của các công cụ và thực hành. Đừng bảo trợ.

Ví dụ, có lẽ anh ta không tin vào phiên bản như một sự trợ giúp, nhưng chỉ cho anh ta cách phân nhánh / hợp nhất và cách anh ta có thể làm việc trên một số tính năng thử nghiệm mà không cần phải có một tập tin.

Về OOP, hãy cho anh ấy thấy một số mẫu thiết kế thú vị / phức tạp, chẳng hạn như mẫu lệnh, mẫu nhiệm vụ và cách nó có thể giúp anh ấy tiết kiệm thời gian quý báu, và tất cả nhóm của bạn.

Nếu bạn không khiến anh ta quan tâm đến một chút ... anh ta có thể là một trường hợp bị mất, nhưng một lần nữa, bạn có các công cụ cho nhóm của mình và bạn vượt trội hơn anh ta. Hãy thử sử dụng một phần mềm lưu trữ hiển thị / email cam kết thông điệp mà người quản lý của bạn có thể nhìn thấy, điều đó sẽ mang lại sự minh bạch cho người quản lý của bạn và loại bỏ đồng nghiệp của bạn ra khỏi hình ảnh (bitbucket.org có kho lưu trữ riêng tư miễn phí với không gian không giới hạn, nếu bạn sử dụng đồng bóng).

Cuối cùng, đừng cố gắng thuyết phục bằng lời nói nhưng bằng những hành động không thể bác bỏ, đó là cách tốt nhất để đối phó với những người cứng đầu IMHO (tâm lý ngược đôi khi cũng hoạt động, lol).

tốt, các kỹ thuật bạn đề cập rõ ràng là tốt, nhưng bạn cũng cần tự hỏi liệu bạn có đang đẩy chúng như ý thức hệ hay không. Tôi thấy rằng các lập trình viên trẻ hơn thường có xu hướng truyền giáo một chút về những gì họ nhặt được ở trường đại học. hãy nhớ rằng những kỹ thuật này là tốt vì kết quả: kiểm soát phiên bản cho phép phát triển đồng thời, theo dõi rõ ràng hơn về các giai đoạn thiết kế, phát triển, thử nghiệm, sửa lỗi. nếu các dự án của bạn thực sự là ngắn hạn, rất nhiều trong số đó đơn giản là không phù hợp, và sẽ khiến bạn trở nên kém nhanh nhẹn hơn. nó đơn giản không phải là trường hợp thực hành tốt nhất có nghĩa là sử dụng mọi thực hành tốt nhất có thể. sự trừu tượng, ví dụ, chắc chắn có thể là một trách nhiệm hơn là một viện trợ, ít nhất là một số lần. kiểm soát phiên bản có ý nghĩa nhất khi bạn có các mốc thời gian phát triển mở rộng, mã phức tạp, nhiều lập trình viên - có một loại sức mạnh tổng hợp, rất khó để có được lực kéo với từng phần.

Tôi nghĩ rằng nơi bắt đầu là để mắt đến việc tái sử dụng tiềm năng - khi các dự án đi qua, nghĩ về những điểm tương đồng hoặc các khuôn khổ chung hơn. cố gắng thoát ra trước các dự án sẽ là một bước đi mạnh mẽ và có thể cho phép bạn làm việc với nhiều kỹ thuật hơn ...

Bạn nên yêu cầu người giám sát của bạn thực hiện một bài thuyết trình cho MỌI NGƯỜI về lý do tại sao phần mềm "phiên bản" lại tốt. Đừng độc thân đồng nghiệp của bạn ra ngoài.

Bản thân tôi là một người hoài nghi về phần mềm kiểm soát nguồn, bởi vì tôi thấy mọi người lạm dụng nó mọi lúc - như một cách để tránh công việc.

Các đồng nghiệp của tôi đang hợp nhất một cách chắc chắn, liên tục giẫm lên các ngón chân của nhau. Nhưng một bài giảng thân thiện tốt về lợi ích của nó sẽ là một điều tốt đẹp và sẽ thúc đẩy các cuộc thảo luận.