Tôi làm việc như một nhà phát triển iOS trong một công ty gia công nhỏ trong một nhóm gồm 4 người. Chúng tôi làm việc trong một dự án bắt đầu một vài năm trước khi tôi và hai nhà phát triển khác gia nhập công ty. Trước đó, dự án chủ yếu được thực hiện bởi một người.

Khi tôi bắt đầu làm việc với dự án thì đó là một mớ hỗn độn. Có rất nhiều sự lặp lại mã. Tôi đã thấy cùng 500 mã được xử lý với 20 tệp khác nhau với các biến thể nhỏ. Ngoài ra, nó không được tổ chức chính xác: tất cả mã tạo UI được trộn lẫn trong các bộ điều khiển xem cùng với logic.

Tôi đã cố gắng hết sức để cấu trúc lại mọi thứ ở đây và ở đó, loại bỏ các đoạn mã dư thừa, cải thiện cấu trúc tệp của dự án, v.v. Có vẻ như nhà phát triển trước đó không thực sự quan tâm đến tất cả những điều này hoặc không có kinh nghiệm. Đã có lúc tôi làm việc một mình trên một tính năng khá lớn trong một vài tháng. Do tính chất của tính năng này, tôi đã phải chạm vào rất nhiều mã trên toàn bộ ứng dụng, vì vậy tôi đã cố gắng thực hiện một số cải tiến.

Khi các nhà phát triển khác tham gia dự án, tôi nhận thấy rằng họ sử dụng một kiểu mã hóa khác (đôi khi là một kiểu hoàn toàn khác) và thường không sử dụng các tính năng ngôn ngữ hiện đại như bộ truy cập thuộc tính (điều này tương đối mới trong Objective-C). Đôi khi, họ sẽ phát minh ra xe đạp của riêng họ thay vì sử dụng các tính năng tương tự của khung hoặc chuyển các khái niệm từ các ngôn ngữ lập trình hoặc patters khác mà họ đã học vào cơ sở mã của chúng tôi. Thông thường, họ không thể đặt tên phương thức hoặc biến chính xác vì tiếng Anh không tốt (Objective-C là ngôn ngữ mà bạn đặt tên dài).

Đôi khi tôi nghĩ rằng nếu nó không dành cho IDE thì tôi nghĩ họ sẽ viết tất cả mã mà không có sự thụt lề hay định dạng nào cả.

Về cơ bản, tôi ghét mã họ viết. Nó được định dạng / tổ chức kém, và đôi khi hoàn toàn khác biệt với phần còn lại của dự án. Tôi cảm thấy rất khó chịu khi họ thêm spaghetti của họ vào tác phẩm nghệ thuật của tôi và nó ảnh hưởng đến tâm trạng của tôi trong công việc và năng suất của tôi.

Cảm giác ngày càng giống như họ không thể bận tâm để học hoặc không quan tâm: họ chỉ làm những gì được yêu cầu từ họ và về nhà. Tôi đã cố gắng cho họ một vài lời khuyên khi tôi có cơ hội (ví dụ như nhận xét PR của họ hoặc cam kết trên GitHub). Tôi đã từng yêu cầu phải tuân theo kiểu mã hóa và định dạng của phần lớn mã hiện có (đáng buồn là chúng ta không có tài liệu về kiểu mã hóa chính thức). Nhưng nó không hoạt động ...

Làm thế nào tôi có thể giải quyết tình huống này mà không chỉ tập trung vào 'văn hóa công ty tồi', 'sinh viên tốt nghiệp thiếu kinh nghiệm', v.v. và thực sự bắt đầu cải thiện tình hình.

Dạy và thực hành những gì bạn giảng.

Bạn biết công cụ này là quan trọng. Bạn biết nhược điểm khi nó không được thực hiện đúng.

Bây giờ thách thức là thuyết phục người khác. Điều này sẽ không được thực hiện thông qua một cuộc trò chuyện, cuộc họp, cuộc trò chuyện trên hành lang, mẹo hoặc trong Yêu cầu kéo.

Điều này cần:

• Công chúng thừa nhận bởi ban quản lý rằng những mục này rất quan trọng
• Linters để mọi người có thể cùng nhau, băm ra và đồng ý về phong cách và sau đó cho phép máy tính làm chính sách
• Dẫn đầu các nhà phát triển mua đầy đủ và sẵn sàng dạy cho người khác
• Các cuộc họp, trình diễn, ăn trưa và học hỏi, vv để dạy các phương pháp này
• Những người được đo lường về các mặt hàng chất lượng mà bạn đề cập trong quá trình đánh giá của họ
• Tiêu chuẩn tài liệu và công bố
• Yêu cầu kéo có nhiều người đánh giá
• Yêu cầu kéo không được hợp nhất cho đến khi chất lượng mã cao
• Ghép mã thường xuyên
• Đánh giá mã nhóm cho PR phức tạp

Trong từ nó đòi hỏi

Khả năng lãnh đạo

Tin tốt là tất cả các hoạt động này thường được công nhận là thông lệ tốt, vì vậy khi bạn đi quảng bá hoặc mua từ quản lý, bạn sẽ có cơ hội thành công và có thể bảo vệ việc làm đúng. Tuy nhiên, quản lý vẫn có thể không mua, đó là một chủ đề và câu hỏi khác.

Tôi đã viết rất nhiều về chủ đề này trên SoftwareEngineering.SE trong quá khứ và bản thân tôi cũng gặp tình huống tương tự. Do đó, tôi sẽ cố gắng đưa ra một vài gợi ý và nêu bật một vài vấn đề tôi đã lưu ý khi đọc câu hỏi của bạn.

Nhưng trước tiên, hãy nói về một khía cạnh quan trọng: vai trò của bạn trong công ty.

Vai trò của bạn

Bạn có thể có một nhiệm vụ rõ ràng từ ông chủ của bạn để tăng cường mọi thứ, và cũng là một vị trí trong hệ thống phân cấp nơi các nhà phát triển khác phải lắng nghe đơn đặt hàng của bạn . Hoặc bạn có thể là một trong số những người ngang hàng, có cùng vai trò và cùng thẩm quyền, lựa chọn của bạn chỉ là ... à ... một ý kiến .

Trong cả hai trường hợp, điều quan trọng là vị trí của bạn ít hơn trong hệ thống phân cấp và hơn thế nữa:

• Những nhà phát triển khác nghĩ gì về bạn. Nếu họ coi bạn là một kẻ phiền phức, hỏi họ những điều ngu ngốc, bạn sẽ không thể đi xa được. Tôi đã thấy nhiều trường hợp trong đó các nhà lãnh đạo kỹ thuật và quản lý dự án hoàn toàn không có ảnh hưởng gì đến nhóm, bởi vì nhóm biết (hoặc nghĩ) rằng những người lãnh đạo của nhóm này, không có nền tảng kỹ thuật cần thiết để đưa ra quyết định. Mặt khác, tôi đã thấy một số nhà phát triển thực sự được đồng nghiệp lắng nghe, bởi vì họ biết những nhà phát triển đó có kỹ năng và kinh nghiệm.

• Làm thế nào vững chắc là nhóm của bạn và những gì thúc đẩy họ. Hãy tưởng tượng một công ty nơi mọi nhà phát triển được trả tiền cho KLOC / tháng. Bạn có muốn nói gì về vấn đề phong cách với đồng nghiệp không? Có lẽ là không, bởi vì hiếm có người nào muốn được trả ít hơn. Nói chung, nếu đây không phải là một nhóm mà chỉ là một nhóm người làm việc trong cùng một dự án, bạn sẽ không thể cải thiện bất cứ điều gì.

Tùy thuộc vào điều đó, bạn có thể quyết định liệu có đáng để nỗ lực thực hiện bất kỳ thay đổi nào không. Nếu bạn không có tiếng nói và không có sự gắn kết nhóm, chỉ cần đi tìm một công việc khác. Nếu bạn được biết đến như một nhà phát triển tài năng, được kính trọng và có một cảm giác nhóm mạnh mẽ, bạn sẽ có thể cải thiện mọi thứ tương đối dễ dàng, ngay cả khi phải đối mặt với sự thù địch từ sếp hoặc các nhóm khác.

Trong mọi trường hợp, điều cần thiết là không gây áp lực cho đội của bạn. Làm việc với họ, không chống lại họ. Đừng ra lệnh cho họ, nhưng hãy hướng dẫn họ hướng tới mục tiêu.

Bây giờ, các gợi ý.

Phong cách

Tôi đã từng yêu cầu phải tuân theo kiểu mã hóa và định dạng của phần lớn mã hiện có (đáng buồn là chúng ta không có tài liệu về kiểu mã hóa chính thức). Nhưng nó không hoạt động ...

Tất nhiên là không, vì đây không phải là cách nên làm.

• Phong cách thật nhàm chán .

• Theo phong cách là nhàm chán .

• Viết tài liệu theo phong cách mã hóa thật nhàm chán ( và thật khó khăn ; thậm chí đừng thử làm nó trừ khi bạn đã làm việc với ngôn ngữ này hơn mười năm).

• Đọc tài liệu phong cách là nhàm chán .

• Xem lại mã cho các lỗi phong cách là nhàm chán .

• Trolling rằng phong cách của tôi tốt hơn phong cách của bạn là thú vị , đặc biệt là khi hoàn toàn không có lợi ích khách quan của phong cách này so với phong cách khác. Nghiêm túc mà nói, mọi người tỉnh táo đều biết rằng cách viết đúng if (x)là cách tôi viết, không phải if(x)hay if ( x )!

Vì thế:

• Đừng đánh giá phong cách. Đây là công việc của người kiểm tra phong cách. Những ứng dụng dễ thương đó có một vài lợi ích so với bộ não của bạn: chúng kiểm tra toàn bộ dự án trong vài phần nghìn giây, không phải hàng giờ hoặc hàng ngày và chúng không mắc lỗi và không bỏ sót lỗi kiểu.

• Đừng viết tiêu chuẩn phong cách của riêng bạn. Dù sao bạn cũng sẽ làm sai và đồng nghiệp sẽ troll bạn rằng bạn đã lựa chọn tồi.

• Đừng buộc các nhà phát triển sửa lỗi 2 000 kiểu.

• Thực hiện phong cách tự động trên cam kết. Mã có lỗi kiểu không có chỗ trong kiểm soát phiên bản.

• Làm điều đó từ khi bắt đầu dự án. Thiết lập điều khiển kiểu trong một dự án tồn tại là khó khăn đến không thể.

Để biết thêm về điều đó, đọc phần đầu tiên của câu trả lời này khác trên SE.SE .

Cũng thế:

• Đừng quá khắt khe. Ví dụ, viết jslintmã -compliant khá khó chịu, vì vậy nó nên được thực hiện riêng khi thực sự cần thiết (hoặc nếu tất cả các thành viên trong nhóm của bạn hài lòng khi sử dụng nó). Cũng vậy với các công cụ kiểm tra tĩnh; ví dụ, Phân tích mã của .NET ở mức tối đa có thể rất ngột ngạt và thất vọng, trong khi mang lại rất ít lợi ích; mặt khác, công cụ tương tự được đặt ở mức độ vừa phải, chứng tỏ là rất hữu ích.

Mã đánh giá

Bây giờ bạn không cần bận tâm về phong cách trong quá trình đánh giá mã, bạn có thể tập trung vào những thứ thú vị hơn: tăng cường (so với sửa lỗi) mã nguồn.

Những người khác nhau phản ứng khác nhau để đánh giá mã. Một số người coi đó là một cơ hội. Những người khác ghét nó. Một số lắng nghe mọi thứ bạn nói với họ, ghi chú và không thảo luận, ngay cả khi họ có thể đúng. Những người khác cố gắng tranh luận về mọi điểm. Tùy thuộc vào bạn để tìm cách đối phó với mọi nhà phát triển theo tính cách của cô ấy. Nó thường hữu ích để:

• Thực hiện đánh giá mã ở chế độ riêng tư, đặc biệt khi nhà phát triển là thiếu niên và viết mã thực sự xấu.

• Cho thấy rằng không có gì cá nhân: bạn đang xem xét mã, không phải kỹ năng của người đó.

• Hiển thị mục tiêu thực tế của một đánh giá mã. Mục tiêu không phải là cho thấy một nhà phát triển tồi tệ như thế nào. Mục tiêu là cung cấp cơ hội để cải thiện.

• Không bao giờ tranh luận. Bạn không ở đây để thuyết phục, nhưng để cung cấp chuyên môn của bạn.

• Đừng bao giờ cho rằng người được đánh giá là người duy nhất có thể học được điều gì đó từ đánh giá. Bạn cũng ở đây để học, cả bằng cách đọc mã và bằng cách hỏi giải thích về những phần bạn không hiểu.

Sau khi xem xét mã được thực hiện, hãy chắc chắn rằng người đó thực sự cải thiện mã của cô ấy. Tôi đã có một vài trường hợp các nhà phát triển nghĩ rằng việc xem xét mã kết thúc khi cuộc họp thực sự kết thúc. Họ rời đi và quay lại các tính năng mới của họ, cố gắng áp dụng những gì bạn đã chia sẻ với họ cho mã mới. Có một công cụ theo dõi phong nha để xem xét mã giúp.

Lưu ý rằng độc lập với vai trò cụ thể của bạn trong công ty và chuyên môn của bạn so với những người khác, mã của bạn cũng phải được xem xét. Bạn cũng không nên là người duy nhất xem xét mã của người khác.

Trong một dự án gần đây khi tôi làm lãnh đạo kỹ thuật, tôi đã có một thời gian khó khăn để giải thích với đồng nghiệp rằng vai trò của họ là thực hiện đánh giá mã của nhau, bao gồm cả mã của tôi. Nỗi sợ hãi của một thực tập sinh sắp xem lại mã của nhà lãnh đạo kỹ thuật của anh ta biến mất ngay khi anh ta tìm thấy những vấn đề đầu tiên trong mã số và ai trong chúng ta viết mã hoàn hảo?

Đào tạo

Đánh giá mã là một cơ hội tuyệt vời để dạy và học một số khía cạnh của lập trình và thiết kế phần mềm, nhưng những người khác yêu cầu đào tạo.

Nếu bạn có thể đào tạo đồng nghiệp của mình, hãy làm điều đó. Nếu quản lý của bạn thù địch với ý tưởng đào tạo, hãy làm điều đó một cách không chính thức. Tôi đã thực hiện các buổi đào tạo như vậy dưới hình thức các cuộc họp không chính thức, hoặc đôi khi là một cuộc thảo luận đơn giản, đôi khi bị gián đoạn bởi quản lý và theo đuổi sau đó.

Bên cạnh đào tạo trực tiếp, hãy đảm bảo bạn biết đủ các cuốn sách như Hoàn thành mã của McConnel và nói về những cuốn sách đó với đồng nghiệp của bạn. Đề nghị họ đọc mã nguồn của các dự án nguồn mở, cung cấp cho họ các ví dụ cụ thể về mã chất lượng cao. Và, rõ ràng, tự viết mã chất lượng cao.

Tập trung vào bối cảnh, không phải vào người

Làm thế nào tôi có thể giải quyết tình huống này mà không chỉ tập trung vào 'văn hóa công ty tồi', 'sinh viên tốt nghiệp thiếu kinh nghiệm', v.v.

Những sinh viên tốt nghiệp có một mục tiêu: có được kinh nghiệm, học hỏi công cụ, trở nên khéo léo hơn. Nếu, năm này qua năm khác, họ viết mã tào lao và không biết gì về lập trình, có lẽ vì nhóm của bạn hoặc công ty của bạn không cho họ cơ hội này.

Nếu bạn đang tập trung vào thực tế là nhóm của bạn có những sinh viên tốt nghiệp thiếu kinh nghiệm, điều này sẽ không có ích. Thay vào đó, hãy tập trung vào những gì bạn có thể làm cho họ và với họ. Đánh giá mã và đào tạo là hai trong số các kỹ thuật để cải thiện tình hình.

Văn hóa công ty xấu là một con thú khác nhau. Đôi khi, nó có thể được thay đổi. Đôi khi, nó không thể. Trong mọi trường hợp, hãy nhớ rằng bạn là một phần của công ty này, vì vậy bạn là một phần của văn hóa công ty. Nếu bạn không thể thay đổi nó và thấy nó vốn đã xấu, sớm hay muộn, bạn sẽ phải rời đi.

Lấy số liệu của bạn đúng

Làm thế nào chính xác để bạn đo mã ngay bây giờ? Bạn có đo số lần cam kết mỗi ngày cho mỗi nhà phát triển không? Hoặc KLOC mỗi tháng cho mỗi lập trình viên? Hoặc có thể bảo hiểm mã? Hoặc số lượng lỗi được tìm thấy và sửa chữa? Hoặc số lượng lỗi tiềm năng bị bắt bởi các bài kiểm tra hồi quy? Hoặc số lượng hoàn nguyên được thực hiện bởi máy chủ Triển khai liên tục?

Những điều bạn đo lường được, bởi vì các thành viên trong nhóm đang điều chỉnh công việc của họ với các yếu tố được đo lường. Ví dụ, trong một công ty nơi tôi phải làm việc vài năm trước, điều duy nhất được đo lường là thời gian một người ở văn phòng. Không cần phải nói rằng điều này không được khuyến khích để cung cấp mã tốt hơn, hoặc làm việc thông minh hơn, hoặc ... tốt, để làm việc.

Tìm ra sự củng cố tích cực và tiêu cực và điều chỉnh các yếu tố đo lường theo thời gian về cơ bản là đòn bẩy mà bạn có đối với các thành viên trong nhóm. Khi được thực hiện đúng cách, nó có thể đạt được kết quả mà sẽ không đạt được bằng cách phân cấp đơn giản.

Những điều làm phiền bạn, làm cho chúng có thể đo lường được. Đo lường chúng, và làm cho kết quả công khai. Sau đó làm việc cùng với các thành viên khác trong nhóm để cải thiện kết quả.

Ví dụ, hãy xem xét rằng các thành viên trong nhóm mắc quá nhiều lỗi chính tả trong tên của các lớp, thành viên lớp và các biến. Điều này thật khó chịu. Làm thế nào bạn có thể đo lường điều đó? Với trình phân tích cú pháp, bạn có thể trích xuất tất cả các từ trong mã và sử dụng trình kiểm tra chính tả, xác định tỷ lệ các từ có lỗi và lỗi chính tả, giả sử 16,7%.

Bước tiếp theo của bạn là đồng ý với nhóm của bạn về tỷ lệ mục tiêu. Nó có thể là 15% cho lần chạy nước rút tiếp theo, 10% cho lần tiếp theo, 5% trong sáu tuần và 0% trong hai tháng. Các số liệu đó được tính toán lại tự động trên mỗi cam kết và được hiển thị trên màn hình lớn trong văn phòng.

• Nếu bạn không đạt được tỷ lệ mục tiêu, nhóm của bạn có thể quyết định dành thêm thời gian để sửa lỗi chính tả. Hoặc nhóm của bạn có thể xem xét nó tốt hơn để tính tỷ lệ cho mỗi nhà phát triển và cũng hiển thị thông tin này trên màn hình lớn. Hoặc nhóm của bạn có thể thấy rằng mục tiêu quá lạc quan và bạn nên xem lại nó.

• Nếu bạn đạt được tỷ lệ mục tiêu, bước tiếp theo là đảm bảo số lượng lỗi và lỗi chính tả sẽ không tăng theo thời gian. Vì vậy, bạn có thể tạo một tác vụ bổ sung trong bản dựng của mình để kiểm tra lỗi chính tả và không xây dựng nếu tìm thấy ít nhất một lỗi. Bây giờ bạn đã thoát khỏi vấn đề này, màn hình lớn của bạn có thể được sử dụng lại để hiển thị số liệu thống kê mới có liên quan.

Phần kết luận

Tôi tin rằng mọi khía cạnh được đề cập trong câu hỏi của bạn đều có thể được giải quyết thông qua các kỹ thuật tôi đưa vào câu trả lời của mình:

• Khi các nhà phát triển khác tham gia dự án, tôi nhận thấy rằng họ sử dụng một kiểu mã hóa khác (đôi khi là một kiểu hoàn toàn khác)

  Bạn phải thực thi kiểu tự động trên cam kết.

• và thường không sử dụng các tính năng ngôn ngữ hiện đại như người truy cập thuộc tính (điều này tương đối mới trong Mục tiêu-C).

  Cả hai đánh giá mã và đào tạo đều ở đây để chuyển kiến ​​thức về ngôn ngữ của bạn.

• Đôi khi, họ sẽ phát minh ra xe đạp của riêng họ thay vì sử dụng các tính năng tương tự của khung

  Cả hai đánh giá mã và đào tạo đều ở đây để chuyển kiến ​​thức của bạn về khung.

• hoặc chuyển các khái niệm từ các ngôn ngữ lập trình hoặc patters khác mà họ đã học vào cơ sở mã của chúng tôi.

  Đây là một điều tuyệt vời. Có vẻ như một cơ hội để bạn học hỏi từ họ.

• Thông thường, họ không thể đặt tên phương thức hoặc biến chính xác vì tiếng Anh không tốt

  Đánh giá mã cũng nên tập trung vào việc đặt tên thích hợp. Một số IDE cũng có trình kiểm tra chính tả.

• Đôi khi tôi nghĩ rằng nếu nó không dành cho IDE thì tôi nghĩ họ sẽ viết tất cả mã mà không có sự thụt lề hay định dạng nào cả.

  Tất nhiên họ sẽ. Phong cách nhàm chán và nên được tự động hóa.

• Về cơ bản, tôi ghét mã họ viết.

  Hãy nhớ từ phần đánh giá mã: Mục tiêu không phải là cho thấy nhà phát triển tệ đến mức nào. Mục tiêu là cung cấp cơ hội để cải thiện.

• Nó được định dạng / tổ chức kém, và đôi khi hoàn toàn khác biệt với phần còn lại của dự án.

  Kiểm tra kiểu tự động .

• Tôi cảm thấy rất khó chịu khi họ thêm spaghetti của họ vào tác phẩm nghệ thuật của tôi

  Đợi đã, cái gì?! Tác phẩm nghệ thuật?! Đoán xem cái gì? Một số người (bao gồm bạn trong sáu tháng) có thể thấy mã của bạn không phải là một tác phẩm nghệ thuật. Trong khi đó, hãy hiểu rằng coi tác phẩm của bạn là một tác phẩm nghệ thuật và tác phẩm của họ như là tào lao sẽ không giúp được ai. Bao gồm cả bạn.

• Cảm giác ngày càng giống như họ không thể bận tâm để học hoặc không quan tâm: họ chỉ làm những gì được yêu cầu từ họ và về nhà.

  Tất nhiên họ sẽ làm những gì được yêu cầu từ họ. Hãy nhớ: bối cảnh, không phải người và có được số liệu của bạn đúng . Nếu bối cảnh đòi hỏi từ họ để trở nên tốt nhất ở những gì họ làm, họ sẽ làm điều đó. Nếu bối cảnh yêu cầu sản xuất càng nhiều KLOC mỗi tháng càng tốt và không có gì nữa, họ cũng sẽ làm điều đó.

Thực hiện các tiêu chuẩn mã hóa và tuân theo chúng, các mẫu thiết kế, thư viện đoạn mã mà người ta có thể sử dụng làm hướng dẫn, v.v.

Các tiêu chuẩn mã hóa có thể bao gồm từ việc quyết định xem nên sử dụng khoảng trắng hay tab, kiểu mẫu thiết kế nào để thử và sử dụng, quy ước đặt tên, v.v. Điều này sẽ đi một chặng đường dài ngay cả khi mọi người viết mã khác nhau.

Nếu bạn có thể, hãy thực hiện các tiêu chuẩn mã hóa và đánh giá mã - để bắt đầu xem xét mỗi lần đăng ký. Với một nhóm nhỏ, sẽ rất khó bán cho những người không hiểu rằng chi thêm gấp 2 hoặc 3 lần cho mã của bạn sẽ giúp bạn tiết kiệm 20 lần hoặc 30 lần cho thời gian phát triển chung, nhưng đó là một khái niệm khác đáng để mua -ở trên.

Tôi sẽ không cố gắng thực hiện mọi thứ ngay lập tức và tôi cũng cố gắng hết sức để khiến họ đạt được các tiêu chuẩn - không chỉ thụt mà còn cố gắng khiến họ nghĩ về những điều họ gặp phải trong mã của họ làm cho cuộc sống của họ dễ dàng hơn hoặc khó khăn hơn.

Cân nhắc việc có một cuộc họp một ngày một tuần để đánh giá về những gì đã xảy ra đúng hay sai cho mỗi người trong tuần đó - bạn cũng có thể cung cấp cơ hội cho mỗi người nói những gì người khác đã làm có ích nhất trong tuần đó - những thứ như thế . Bạn có thể xem sách XP / Agile để biết thêm ý tưởng như thế này. Là một nhóm nhỏ, một lần nữa, đây có thể là một khó bán.

Bạn đã đề cập đến vấn đề ngôn ngữ. Nếu những công nhân này là người địa phương (Nhà thầu tại chỗ hoặc thuê toàn thời gian) thì đó không phải là vấn đề quá lớn nhưng nếu họ là nhà thầu nước ngoài làm việc từ xa - hãy để tôi nói rằng theo kinh nghiệm cá nhân của tôi thì điều này sẽ không bao giờ sẽ được sửa chữa, hoặc đưa nó ra ngoài cho đến khi quản lý nhận ra rằng nó sẽ không hoạt động hoặc xem xét rời khỏi công ty. Đừng rơi vào tình huống bạn phải chịu trách nhiệm cho công việc của họ và đừng lãng phí thời gian để cố gắng khắc phục các hoạt động phát triển của nhóm. Nhiều khả năng công việc của bạn sẽ phát triển thành việc dành 100% thời gian của bạn để làm cho mã của họ hoạt động. Nhân tiện, nhiều nhà thầu nước ngoài là những lập trình viên tuyệt vời, tôi chỉ đề cập đến trường hợp công ty ký hợp đồng gửi cho bạn loại tài năng mà bạn mô tả.

Các triệu chứng mà bạn mô tả mạnh mẽ cho thấy thiếu sự gắn kết nhóm .

Trong tình huống như vậy, các tiêu chuẩn mã hóa, đào tạo, quy trình hoặc công cụ sẽ không phải là viên đạn bạc có thể cải thiện đáng kể chất lượng. Trước tiên, bạn phải phát triển tinh thần đồng đội, giao tiếp cởi mở và mang tính xây dựng và quyền sở hữu chung của sản phẩm.

Triệu chứng:

• "Họ chỉ làm những gì cần thiết và về nhà": âm thanh họ bị mất điều kiện. Họ không nhiệt tình hơn khi họ đến?
• "Họ" chống lại "chúng tôi" / "tôi" / "tôi": thiếu tin tưởng lẫn nhau?
• "Tôi đã đưa ra một số lời khuyên: Tôi đã nhận xét PR trên Git": giọng điệu của những lời chỉ trích bằng văn bản đôi khi bị hiểu sai là hung hăng hoặc kiêu ngạo mặc dù có ý định xây dựng. Tại sao không thảo luận trực tiếp?

Bạn là một nhóm nhỏ: sử dụng lợi thế này! Một số ý tưởng để bắt đầu:

• Đưa ra quyết định quan trọng tập thể. Thảo luận công khai bất đồng. "Thảo luận" không phải là áp đặt một quan điểm, mà là lắng nghe và cố gắng tìm ra điểm chung.
• Bạn đã cấu trúc lại các phần quan trọng của mã, để bạn có quyền sở hữu thực sự mạnh mẽ. Hãy để họ mua. Hãy để họ có một lời để nói.
• Và đối với các chủ đề rất nhạy cảm nhưng mang tính chủ quan cao như định dạng mã, chỉ cần thuê ngoài nhiệm vụ cho một máy in đẹp tự động sẽ định dạng lại theo tiêu chuẩn và không có cảm giác khi đăng ký.

Trích dẫn trong ngày:

Nếu bạn muốn đi nhanh, hãy đi một mình. Nếu bạn muốn đi xa, hãy đi cùng nhau

Câu hỏi của bạn có thể được trả lời bằng "Thay đổi công ty của bạn hoặc thay đổi công ty của bạn". Đối với những người không biết, điều này có nghĩa là bạn ở lại và chiến đấu để mang lại sự thay đổi mà bạn muốn thấy trong công ty của bạn hoặc thay đổi công ty bạn làm việc (ví dụ như rời khỏi và làm việc ở một nơi khác).

Phần thứ hai là đơn giản nhất. Bạn rời đi và tìm một công ty có chung giá trị bạn làm việc. Việc đầu tiên không đơn giản vì ... người.

Điều bạn cần làm là thay đổi con người. Nghĩ rằng chúng bị hỏng và bạn cần sửa chúng sẽ không hoạt động. Con người là những sinh vật tình cảm. Điều này có thể dễ dàng thoái hóa trong các cuộc chiến cá nhân. Vì thế...

Trước hết, bạn cần tìm hiểu tại sao tình hình lại diễn ra như vậy. Nói chuyện với mọi người. Tìm ra. Những gì bạn thấy bây giờ là kết quả của các quyết định được thực hiện trong suốt nhiều năm (hoặc có thể không đưa ra một số quyết định quan trọng vào đúng thời điểm). Đừng phán xét và đừng vội kết luận.

Đây có phải là do các nhà phát triển thiếu kinh nghiệm? Có phải nguyên nhân là do quản lý cố gắng giảm chi phí bằng cách thuê những sinh viên tốt nghiệp giá rẻ thay vì những nhà phát triển giàu kinh nghiệm và đắt tiền hơn? Đây có phải là về những người lười biếng và có ý định xấu hoặc những người bị đánh bại bởi một hệ thống bị hỏng? Thời hạn buộc bạn phải làm "những gì phải làm" để nó hoạt động hay mọi người chỉ lãng phí thời gian của họ và không quan tâm quá nhiều đến những gì họ đang làm? Vân vân.

Vấn đề với lĩnh vực phát triển phần mềm này là mọi người học hỏi trong công việc. Nếu họ làm việc trong một môi trường nhảm nhí, họ sẽ bỏ thói quen xấu. Và thói quen có xu hướng dính và khó lay chuyển. Sau đó, họ không biết rõ hơn vì đó là tất cả những gì họ biết. Không phải tất cả các nhà phát triển đều đam mê những gì họ làm để đầu tư thời gian vào việc cải thiện hoặc tìm cách cải thiện. Một số đã vào kinh doanh này vì nhiều lý do khác. Vì vậy, tìm hiểu tại sao mọi người là như thế nào.

Sau đó là quản lý. Là quản lý không biết tình hình hay chỉ là không quan tâm? Tìm ra. Bạn hoàn toàn cần có sự hỗ trợ của quản lý nếu bạn muốn cải thiện mọi thứ. Nếu một cái gì đó mất 3 tháng để xây dựng đột ngột mất 4 tháng vì bây giờ bạn cần viết bài kiểm tra, đánh giá mã, thảo luận tại bảng trắng với nhóm để quyết định các giải pháp tốt, chương trình ghép đôi, v.v. chắc chắn rằng quản lý sẽ nhận thấy sự khác biệt thời gian. Một cái gì đó thay đổi từ 3 đến 4 tháng là dễ dàng để quan sát và đo lường. Có một cơ sở mã vững chắc, một sản phẩm có thể bảo trì, kiến ​​trúc ổn định tốt, những thứ tạo nên cấu trúc sản phẩm tốt hơn không phải là quá dễ dàng để đo lường. Bao lâu thời gian thực hành tốt nhất mua cho bạn về lâu dài không thể được đo lường trước, thậm chí có thể không ngay cả sau khi thực tế. Mặt khác, trì hoãn một tháng là không có trí tuệ. Vì vậy, có hỗ trợ quản lý về điều này. Chuẩn bị để thực hiện một bán khó khăn.

Cũng nhìn vào bối cảnh của doanh nghiệp. Điều này có ảnh hưởng đến cách bạn làm việc không? Bạn có cơ hội phải được theo dõi bằng bất cứ giá nào, bao gồm cả việc hy sinh chất lượng mã hoặc thực tiễn tốt nhất không?

Hãy thay đổi quan điểm một lát.

Tôi cảm thấy rất khó chịu khi họ thêm spaghetti của họ vào tác phẩm nghệ thuật của tôi và nó ảnh hưởng đến tâm trạng của tôi trong công việc và năng suất của tôi.

Xin lỗi ... của bạn là gì? Nghệ thuật? Tôi biết hầu hết chúng ta ở đây để nhận được sự công nhận từ các đồng nghiệp của chúng tôi và bạn chỉ nhận được điều đó nếu bạn là một nhà phát triển giỏi, nhưng mã của bạn có được hiển thị trong một bảo tàng bên cạnh một bức tranh không? Liệu nó có phải gây ra cảm xúc trong những người nhìn vào nó? Nước mắt của niềm vui và hạnh phúc? Vâng, tôi mỉa mai và tôi cố tình phóng đại vì tôi muốn nói để giữ ý thức thực tế. Đừng để cảm xúc gắn liền với mã của bạn.

Tôi đã từng làm việc với một anh chàng vui vẻ ném cả đội, dự án và công ty xuống xe buýt chỉ để áp đặt "nghệ thuật" của mình lên mọi người. Ông là "người nắm giữ sự thật" và theo định nghĩa, mọi người chỉ thiếu kinh nghiệm, mù quáng, không muốn học hỏi, không quan tâm, hoặc chỉ đơn giản là ngu ngốc. Đừng trở thành anh chàng đó. Là một nhà phát triển phần mềm, công việc của bạn là viết mã tốt, mã được kiểm tra, mã có thể duy trì, mã làm tăng giá trị doanh nghiệp và có thể tiếp tục làm như vậy dưới những thay đổi liên tục trong tương lai. Và bạn phải làm tất cả những điều đó dưới sự ràng buộc về ngân sách và thời gian. Đó là những gì nó có nghĩa là một nhà phát triển phần mềm chuyên nghiệp. Trừ khi bạn là một phòng trưng bày nghệ thuật, nghệ thuật là xấu cho kinh doanh. Hãy thực dụng và giữ một cái nhìn cân bằng về mọi thứ. " Làm thế nào để bỏ qua mã xấu đồng nghiệp của tôi viết và chỉ tập trung vào công việc" đã đóng câu hỏi của bạn vì cách bạn đóng khung vấn đề.

Làm thế nào tôi có thể giải quyết tình huống này mà không chỉ tập trung vào 'văn hóa công ty tồi', 'sinh viên tốt nghiệp thiếu kinh nghiệm', v.v. và thực sự bắt đầu cải thiện tình hình.

TL; DR: Xem xét cẩn thận tình huống để tìm hiểu lý do tại sao mọi thứ kết thúc trong tình huống đó. Chấp nhận rằng tình hình là như thế và xem bạn có thể cải thiện như thế nào từ đó. Tìm hiểu ý kiến ​​của mọi người về điều này. Chọn trận đấu của bạn. Buộc thay đổi không hoạt động. Hợp tác để thực hiện các thay đổi. Bạn nên cố gắng chỉ ra làm thế nào mọi thứ có thể được cải thiện chứ không chỉ ra chúng tệ đến mức nào. Thuyết phục mọi người rằng những gì bạn muốn làm là vì lợi ích lớn hơn về lâu dài. Đưa họ lên tàu.

Và làm điều đó trong các bước nhỏ.

Nếu bạn mang quá nhiều thay đổi cùng một lúc mọi người sẽ cảm thấy nản lòng và bỏ cuộc. Thay đổi cần có thời gian. Thay đổi công ty của bạn hoặc thay đổi công ty của bạn. Chúc may mắn!