Đối phó với đồng nghiệp khi phát triển, cần lời khuyên [đóng]

Tôi đã phát triển kiến ​​trúc dự án hiện tại của chúng tôi và bắt đầu tự phát triển nó (đạt được một cái gì đó như, revision 40) .

Chúng tôi đang phát triển một khung định tuyến tàu điện ngầm đơn giản và thiết kế của tôi dường như được thực hiện rất tốt - một số mô hình chính, khung nhìn tương ứng, logic chính và cấu trúc dữ liệu được mô hình hóa "như chúng nên" và tách biệt hoàn toàn với kết xuất, phần thuật toán cũng được triển khai ngoài các mô hình chính và có một số điểm giao nhau nhỏ.

Tôi sẽ gọi thiết kế đó có thể mở rộng, có thể tùy chỉnh, dễ thực hiện, tương tác chủ yếu dựa trên "tương tác hộp đen" và, tốt, rất đẹp.

Bây giờ, những gì đã được thực hiện:

• Tôi đã bắt đầu một số triển khai các giao diện tương ứng, chuyển một số thư viện thuận tiện và viết sơ khai thực hiện cho một số phần ứng dụng.
• Tôi đã có tài liệu mô tả phong cách mã hóa và các ví dụ về cách sử dụng kiểu mã hóa đó (mã viết riêng của tôi).
• Tôi buộc phải sử dụng các C++kỹ thuật phát triển hiện đại ít nhiều , bao gồm cả no-deletemã (được bao bọc thông qua con trỏ thông minh) và v.v.
• Tôi đã ghi lại mục đích của việc triển khai giao diện cụ thể và cách sử dụng chúng.
• Các thử nghiệm đơn vị (chủ yếu là các thử nghiệm tích hợp, vì không có nhiều mã "thực tế") và một bộ mô phỏng cho tất cả các trừu tượng cốt lõi.

Tôi đã vắng mặt 12 ngày .

Hiện tại chúng tôi có gì (dự án được phát triển bởi 4 thành viên khác trong nhóm):

• 3 phong cách mã hóa khác nhau trên tất cả các dự án (tôi đoán, hai trong số họ đã đồng ý sử dụng cùng một phong cách :) , cùng áp dụng cho việc đặt tên của trừu tượng của chúng tôi (ví dụ CommonPathData.h, SubwaySchemeStructures.h) , mà về cơ bản tiêu đề tuyên bố một số cấu trúc dữ liệu.
• Tuyệt đối thiếu tài liệu cho các bộ phận thực hiện gần đây.
• Những gì tôi có thể gọi gần đây single-purpose-abstractionbây giờ xử lý ít nhất 2 loại sự kiện khác nhau, có sự liên kết chặt chẽ với các bộ phận khác, v.v.
• Một nửa số giao diện được sử dụng hiện có chứa các biến thành viên (sic!).
• Sử dụng con trỏ thô hầu như ở khắp mọi nơi.
• Các bài kiểm tra đơn vị bị vô hiệu hóa, vì " (Rev.57) They are unnecessary for this project".
• ... (Đó có lẽ không phải là tất cả) .

Lịch sử cam kết cho thấy thiết kế của tôi được hiểu là quá mức cần thiết và mọi người bắt đầu kết hợp nó với xe đạp cá nhân và bánh xe được thực hiện lại và sau đó gặp vấn đề trong việc tích hợp các đoạn mã.

Bây giờ - dự án vẫn chỉ thực hiện một lượng nhỏ những gì nó phải làm, chúng tôi có vấn đề tích hợp nghiêm trọng, tôi giả sử một số rò rỉ bộ nhớ.

Có bất cứ điều gì có thể làm trong trường hợp này?

Tôi nhận ra rằng tất cả những nỗ lực của tôi không có lợi ích gì, nhưng thời hạn là khá sớm và chúng tôi phải làm một cái gì đó. Có ai đó có một tình huống tương tự?

Về cơ bản tôi đã nghĩ rằng một điều tốt (tốt, tôi đã làm mọi thứ có thể) bắt đầu cho dự án có thể sẽ dẫn đến một điều gì đó tốt đẹp, tuy nhiên, tôi hiểu rằng tôi đã sai.

Tái cấu trúc không thương tiếc để thoát ra khỏi mớ hỗn độn!

Lấy phong cách mã hóa chiếm phần lớn phong cách có thể sử dụng và sử dụng nó cho dự án này.

Điều tồi tệ nhất là, bạn phải quay trở lại phiên bản 40 và các lập trình viên của bạn đã có một khóa đào tạo 12 ngày, điều đó giúp họ hiểu rõ hơn về chủ đề này.

Nếu các lập trình viên của bạn có nhiều thứ để tìm hiểu về mã hóa sạch, thì mười hai ngày là ít nhất trong số các độ trễ mà bạn sẽ có.

Diễn giải câu hỏi của bạn - "Tôi đã ra đi trong một vài tuần và không đồng ý với những gì nhóm của tôi đã làm khi tôi đi, làm thế nào để tôi làm cho họ làm những gì tôi muốn khi tôi không ở đây?"

Tôi nói với bạn rằng đây không phải là vấn đề kỹ thuật, đó là vấn đề quản lý. Việc của tôi (Xin hãy tha thứ cho tôi nếu tôi sai) là bạn ra lệnh cho giải pháp kỹ thuật cho một đội quân tay sai, vì một số lý do không thể hoặc không đồng ý hoặc không hiểu giải pháp của bạn.

Nếu 12 ngày là tất cả những gì cần thiết để gây ra nhiều thiệt hại cho thiết kế của bạn, thì phải có một lý do. Là thiết kế dễ vỡ? Nó qua thiết kế? hoặc nhóm đã làm điều đó bất chấp? Thời hạn và giao hàng của bạn như thế nào? Chặt? họ chỉ đang cố gắng để gặp một người?

Một trường hợp tôi đã thấy điều này dẫn đầu về kỹ thuật vượt xa trò chơi mà nhà phát triển trung bình (tôi) không thể theo kịp. Nhà lãnh đạo kỹ thuật đã thất bại trong việc thiết kế mã khả thi về mặt thương mại, vì ông là người duy nhất có thể duy trì nó. Nếu một nhà phát triển grad không thể duy trì nó, thì nó quá phức tạp đối với thế giới thương mại. Tất cả các trường hợp khác, đó chỉ là thiếu kỹ năng quản lý con người về phía quản lý.

Các động lực đội bị phá vỡ. Bạn có thể (như được đề xuất bởi người khác) dành thời gian tái cấu trúc mớ hỗn độn và phải làm lại tất cả vào lần tới khi bạn nghỉ phép. Bạn có thể cần nâng cao kỹ năng cho các thành viên trong nhóm của mình, nhưng tôi tin rằng bạn cần khắc phục tính năng động của nhóm trước, vì họ dường như có đủ kỹ năng để hoàn thành công việc, bất kể bạn tin điều đó xấu đến mức nào.

Đôi.

Những gì bạn đang mô tả là rất nhiều việc làm đúng, về mặt kỹ thuật, độc tấu . Có, bạn đã cố gắng ghi lại, cố gắng áp đặt các tiêu chuẩn - nhưng bạn (dường như) không thể giao tiếp.

Vâng, nhóm của bạn vừa liên lạc với bạn, khá vang dội. Họ nói, "Này, Yippie - bạn không giao tiếp!" Hình thức giao tiếp mạnh mẽ nhất mà tôi biết là ghép nối. Đôi. Cho đến khi họ có được nó, hoặc cho đến khi họ thuyết phục bạn làm điều đó khác đi.

Như Brooks đã nói với chúng tôi trong 30 năm qua, tính toàn vẹn về mặt khái niệm là phần quan trọng nhất của bất kỳ dự án nào. Đối với bất kỳ hệ thống con không hoàn chỉnh và đầy đủ, cần có chính xác một người, chịu trách nhiệm thiết kế và có thẩm quyền chỉ đạo thực hiện. Đã xảy ra lỗi với phần này trong dự án của bạn. Dù đó là gì đi nữa, giải pháp duy nhất là quay trở lại mã trong kho lưu trữ tồn tại trước khi điều đó xảy ra. Mất 12 ngày không là gì so với chi phí duy trì thiết kế bị hỏng. Tôi cũng sẽ nghĩ ra những cách để loại bỏ những người liên quan đến vấn đề này khỏi công việc tiếp theo trong dự án, vì họ tỏ ra không đủ năng lực.

Một điều tôi nên làm cho người mới bắt đầu là có được một công cụ đánh giá mã tốt, sử dụng nó để đánh dấu mã xấu và ghi lại lý do tại sao nó xấu và (về mặt khái niệm) cách thực hiện. Bây giờ, đối với những gì tôi hiểu có rất nhiều điều tồi tệ đã được thực hiện và do đó, sẽ có rất nhiều công việc để xem xét; giả sử bạn là người duy nhất thấy có gì đó không đúng với mã, việc tự mình xem xét mọi thứ là không khả thi. Nhưng bạn có thể đánh dấu các vi phạm tồi tệ nhất và biến chúng thành các mục trong hệ thống theo dõi vấn đề của bạn, được chỉ định cho người đã viết mã tương ứng.

Ưu đãi tốt nhất để viết mã chất lượng là biết rằng nếu bạn không, nó sẽ ám ảnh bạn trong tương lai. Đồng nghiệp của bạn dường như không quan tâm đến điều đó, vì vậy loại thuốc tốt nhất là làm cho họ tự cấu trúc lại các phần sai và học.

Đã có thời gian, bạn có thể xem lại các phần khác của mã có vấn đề và một lần nữa gán lại cho tác giả gốc (xấu). Sau một thời gian, họ sẽ nhận ra lợi ích của việc làm tốt công việc lần đầu tiên.

Tôi cho rằng bạn không coi việc khôi phục lại phiên bản gốc của mình là một tùy chọn - nói cách khác, mặc dù mã xấu mà đồng nghiệp của bạn đã viết họ đã thêm một số chức năng và giá trị ròng của phiên bản hiện tại cao hơn phiên bản gốc. Tôi cũng giả định rằng ngay cả khi đó không phải là trường hợp, bạn không có vốn chính trị để thực hiện việc khôi phục đó và khiến họ viết lại mã (vì rất ít người trên hành tinh có vốn như vậy). Những điều này và nhiều điều nữa là sự phức tạp của việc phán đoán một tình huống mà tôi không gặp phải, nhưng tôi hy vọng hai xu của tôi đã giúp ích.

Một điều tôi chưa thấy đề cập đến nhưng gần đây tôi đã làm việc là các vấn đề về "silo dành cho nhà phát triển" và "mua vào".

Khi bắt đầu dự án hiện tại của tôi, tôi đã tự mình thiết kế một thư viện cốt lõi. (Giống như bạn đã hoàn thành đến vòng 40). Sau đó, khi tôi đã hoàn thành nó, tôi đã trình bày với các thành viên còn lại và nói với mọi người rằng họ có thể bắt đầu sử dụng nó. Điều đã xảy ra trong những tháng tiếp theo là mọi người tiếp tục thực hiện những thứ tương tự đã có trong thư viện này ở những nơi khác. CTO (người chủ động mã hóa) chỉ ra rằng không bao giờ có sự mua lại từ phần còn lại của nhóm trên các giao diện kiến ​​trúc / thiết kế / công cộng của thư viện.

Chà, chúng ta vừa trải qua một bản viết lại chính của thư viện đó đã cải thiện thiết kế tổng thể để phù hợp hơn với những gì chúng ta đang làm, nhưng một lần nữa, một nhà phát triển đã lấy thư viện làm dự án duy nhất của họ, làm việc trong vài tuần và sau đó chỉ cần trình bày nó "Voila! Đây rồi! Nó không đẹp sao?"

Bây giờ tôi phải sử dụng phiên bản mới và vấn đề tương tự cũng xảy ra - tôi ghét cách anh ấy làm điều đó. Và anh ấy đã bỏ đi những thứ cần thiết bởi vì anh ấy đã không hợp tác với bất kỳ ai khác trong khi anh ấy đang làm việc với nó. Vì vậy, một lần nữa, tôi bắt đầu thực hiện những thứ tương tự ở những nơi khác và cách để làm việc cho những gì tôi cần làm.

Câu chuyện dài - Nếu bạn muốn chất lượng mã tăng và nhất quán, tôi khuyên bạn nên kéo cả nhóm cùng nhau thiết lập các tiêu chuẩn, kiểu dáng, v.v. Ngoài ra, bất cứ ai cũng sẽ xây dựng một phần nền tảng hoặc cốt lõi của bạn ứng dụng, tôi sẽ đề nghị rằng người chịu trách nhiệm lãnh đạo cả nhóm thiết kế các lớp, v.v ... để cuối ngày, cả nhóm phải mua vào kiến ​​trúc ứng dụng tổng thể. Ngoài ra, nếu họ biết cách mã của thành viên nhóm khác hoạt động, họ sẽ ít có khả năng thực hiện lại mã theo cách phù hợp với họ.

Bạn có phải là nhà phát triển cao cấp (hoặc một trong những nhà phát triển cao cấp) trong nhóm này không? Nếu vậy có vẻ như bạn cần tổ chức một số hội thảo đào tạo về thực hành tốt nhất. Bạn có lẽ nên hoàn nguyên phần lớn công việc đã hoàn thành, tổ chức một cuộc họp với nhóm của bạn và giải thích đúng cách để thực hiện các chức năng cần thiết theo cách duy trì thiết kế hiện có.

Cho rằng bạn đang phải đối mặt với thời hạn chặt chẽ, bạn có thể phải gửi mã như hiện tại và tái cấu trúc (viết lại?) Sau khi phát hành.

Có vẻ như bạn cần xác định và thực thi một số thực hành mã phổ biến. Bạn có một quy trình xem xét mã tại chỗ trong công việc của bạn? Nếu không, âm thanh như bây giờ là thời gian để thực hiện một. Nhân tiện, đánh giá mã là một cách tuyệt vời để dạy các nhà phát triển mới hơn thực hành tốt nhất.

CHỈNH SỬA:

Tôi đã gặp một tình huống tương tự gần đây. Quản lý tại công ty của tôi khẳng định chúng tôi sử dụng các nhà phát triển hợp đồng để viết nhiều ứng dụng của chúng tôi. Mã họ sản xuất là khủng khiếp (để đặt nó một cách tử tế), nhưng chúng tôi buộc phải sử dụng nó. Tính đến hôm nay, tôi đã viết lại 80% mã mà các nhà thầu đã viết cho chúng tôi. Nó chứa đầy lỗi và không thể mở rộng với các tính năng mới. Vài tháng nữa, nhóm của tôi sẽ viết lại tất cả, khiến cho số tiền đầu tư vào phát triển hợp đồng trở nên lãng phí.

Mã xấu thực sự tốn tiền, đó là điều bạn có thể muốn nói với người quản lý của mình, vì có lẽ bạn sẽ cần sự giúp đỡ của họ để thực hiện và thực thi các tiêu chuẩn mã hóa.

Bạn đã nỗ lực, nhưng thực tế là không ai chịu trách nhiệm . "Nhưng tôi thích phong cách mã hóa của tôi", không có chuyện gì. Tôi muốn làm việc trên các dự án cá nhân của mình cả ngày và vẫn được trả tiền.

Hy vọng rằng, bạn có thể trình bày điều này với các cường quốc và cho họ thấy những gì có thể đã được thực hiện trái ngược với Wild West Show đã diễn ra trong hai tuần. Có vẻ như bạn sẽ phải lấy thứ gì đó ra khỏi cửa, nhưng tiếp tục theo dõi vấn đề thiếu kiểm soát và nhất quán.

Tập trung vào số ít đã đi với kế hoạch của bạn và làm bất cứ điều gì bạn có thể để họ giúp họ sửa chữa mớ hỗn độn này và đưa họ vào nhóm của bạn trong các dự án trong tương lai. Bạn có thể phải từ chối phần còn lại nếu họ không thể kết hợp được với nhau.