Làm thế nào để giữ sự nhất quán trong kiến ​​trúc ứng dụng khi một nhóm phát triển?

Là nhà phát triển duy nhất trong một công ty khởi nghiệp, tôi có khả năng đưa ra nhiều quyết định trong kiến ​​trúc và khung ứng dụng của chúng tôi.

Nhanh chóng chuyển tiếp 4 năm và mua lại sau đó, tôi có một nhóm 5 người và rất nhiều lần cảm giác như miền tây hoang dã. Mọi người đưa ra bất kỳ quyết định thiết kế nào làm hài lòng họ: số nguyên và enum cho các loại DB ở một nơi và chuỗi khác, khung này cho một vấn đề và sau đó là một khung khác cho cùng một vấn đề ở nơi khác, v.v.

Làm thế nào để tôi đi về thực thi tính nhất quán? Nó cảm thấy quan trọng đối với tôi nhưng các thành viên trong nhóm của tôi dường như đăng ký vào phương pháp "nếu nó hoạt động, nó hoạt động".

Tôi đoán một phần lớn câu hỏi của tôi là: nó không thực tế đối với tôi để mong đợi các tiêu chuẩn như thế này? Tôi đấu tranh với ý tưởng đi qua như một nhà độc tài kìm hãm sự sáng tạo nhưng làm bất cứ điều gì họ muốn dường như không thể mở rộng được.

Điều gì làm cho bạn rất đặc biệt?

CPU của tôi nói rằng nó hoạt động và tôi muốn về nhà. Tại sao bạn làm phiền tôi?

Bạn có thể đối phó với thái độ này bằng cách buộc mọi người đưa ra yêu cầu kéo. Nhưng bây giờ thời hạn đang lờ mờ. Mã xấu nhấn vào cổng của lâu đài nguyên sơ của bạn và cuối cùng bạn chịu thua áp lực. Hoặc bạn giành chiến thắng chỉ để tìm mọi người rời đi và không ai sử dụng lâu đài nguyên sơ của bạn.

Có rất nhiều công cụ giúp giải quyết vấn đề này. Kiểm soát nguồn, đánh giá mã, tiêu chuẩn mã hóa, v.v. nhưng cốt lõi và linh hồn của vấn đề là ý kiến ​​chủ quan của bạn về những gì tốt nhất phải được xem là có liên quan. Cho rằng bạn phải kiếm được và duy trì sự tôn trọng của họ. Làm điều đó và điều này là dễ dàng hơn nhiều. Không làm điều đó và không có công cụ hoặc thực hành sẽ cứu bạn.

Cách tốt nhất để làm điều đó là giao tiếp sớm. Đừng nói với tôi "chúng tôi không sử dụng chuỗi cho các loại DB của mình trong cửa hàng này" 6 tháng sau khi tôi giải quyết được ý tưởng. Nói với tôi rằng nó đã bị chôn vùi trong tài liệu trong 2 năm không phải là lý do để tôi làm điều đó.

Vì lý do gì bạn có những thứ bạn quan tâm. Nếu bạn quan tâm đến chúng và có một điểm khiến những điều đó được truyền đạt rõ ràng trước, trong và ngay sau khi mã hóa mọi mô-đun.

Mã rình rập là một thực hành tuyệt vời. Đầu tư vào bất kỳ công cụ và thực hành nào bạn cần để bạn có thể xem lại mã trong vòng vài phút sau khi được viết. Chương trình cặp và công cụ chỉ đơn giản là một chiếc ghế khách.

Tại sao? Mỗi giây trôi qua sau khi tôi viết mã theo cấp số nhân sẽ tăng chi phí để thay đổi nó. Đó là bởi vì bộ nhớ mã của tôi có một nửa cuộc sống. Tôi bắt đầu quên nó ngay lúc bàng quang của tôi đòi nghỉ.

Giảm những điều bạn quan tâm đến các nguyên tắc cơ bản của họ. Thay vì đánh cho tôi một danh sách 101 quy tắc cần tuân theo, hãy đưa cho tôi 10 nguyên tắc mà chúng vi phạm để tôi có thể tự mình tìm ra quy tắc 102 nào.

Trao quyền cho tôi để áp đặt tầm nhìn của riêng tôi bằng cách giúp tôi nhìn thấy tầm nhìn của bạn và chúng tôi sẽ hợp tác tuyệt vời.

Có phải tôi không thực tế khi mong đợi những tiêu chuẩn như thế này? Tôi đấu tranh với ý tưởng đi qua như một nhà độc tài kìm hãm sự sáng tạo nhưng làm bất cứ điều gì họ muốn dường như không thể mở rộng được.

Vậy thì đừng ra lệnh! Làm cho điều này một kinh nghiệm tích cực. Đây không phải là một số tuổi hippy vô nghĩa. Đó là tâm lý cơ bản. Bạn đang cố gắng sửa đổi hành vi của con người. Ngẫu nhiên và tích cực là củng cố nhất (chỉ cần hỏi Las Vegas). Nếu bạn đi tiêu cực, bạn phải phù hợp với cốt thép của bạn. Đó là một nỗi đau không thể đạt được. Hãy tích cực khi bạn truyền bá sự khôn ngoan và bạn có thể bình thường về nó.

Tôi biết bạn đến từ đâu vì tôi đã ở đó. Bạn đã kiểm soát và bây giờ nó đã biến mất. Bạn muốn nó trở lại. Vâng vượt qua nó. Bây giờ bạn có một đội. Họ không cần phải kiểm soát. Cái họ cần là lãnh đạo. Những gì bạn cần không phải là kiểm soát. Đó là ảnh hưởng. Nó hoạt động tốt hơn và làm việc ít hơn rất nhiều. Làm chủ nó và thư giãn. Điều này nên được vui vẻ.

Làm đúng và bạn có thể đi nghỉ và điều này vẫn sẽ làm việc. Làm sao? Bởi không chỉ là một nhà lãnh đạo mà còn khiến những người khác trở thành lãnh đạo. Khi bạn đã thấm nhuần tầm nhìn của bạn trong nhóm, họ có thể làm việc trong khi bạn ra đi chỉ bằng cách bắt chước những gì bạn đang làm. Mentor những người mới và khuyến khích họ bước lên và ảnh hưởng đến những người khác.

Tôi biết nó khó. Chúng tôi đã không đi vào nghề này bởi vì chúng tôi giỏi giao tiếp với mọi người. Chúng tôi giao tiếp tốt nhất với mã. Tốt rồi. Chỉ cần làm nhanh và thường xuyên. Chỉ cho tôi tại sao của bạn là tốt hơn. Hãy lắng nghe nếu tôi nói không phải. Làm điều này trong khi tôi vẫn đang nghĩ về nó. Tôi thích mã. Có rất ít người trên hành tinh mà tôi có thể nói chuyện về nó. Hãy là một trong số họ.

Đầu tiên, khiến mọi người duy trì những thứ họ không viết. Nhà phát triển rất dễ dàng có thói quen sử dụng các khung và kỹ thuật mà họ đã quen. Thật xúc động khi phải chuyển đổi giữa các khung và phương pháp luận. Nếu ai đó bị buộc phải di chuyển ra ngoài góc mã của họ và trải nghiệm thường xuyên, điều đó sẽ khiến một số người phàn nàn và hy vọng một số cuộc thảo luận hữu ích có thể dẫn đến mọi người muốn chuẩn hóa một cái gì đó.

Tiếp theo, kéo yêu cầu và đánh giá mã. Không bao giờ cho phép mã được hợp nhất với các nhánh chính của bạn mà không cần xem lại mã trước. Bất cứ ai cũng có thể làm điều đó. Một lần nữa, khi ai đó thấy điều gì đó khác với những gì họ đã làm, nó có thể nhắc nhở thảo luận và làm việc theo nhóm để đi đến một giải pháp tốt hơn. Nó cũng làm cho tất cả mọi người trở thành người chăm sóc cơ sở mã, điều này (hy vọng) sẽ khiến mọi người quan tâm đến nó và trạng thái của mã đi vào nó.

Cuối cùng, có các cuộc thảo luận thiết kế. Họ có thể chính thức hoặc không chính thức, nhưng có chúng. Hãy để những người muốn tham gia làm như vậy. Thảo luận về các khung công tác bạn muốn sử dụng, ưu và nhược điểm của enums so với ints, v.v ... Sau đó đi đến quyết định và ghi lại nó ở đâu đó (như tài liệu tiêu chuẩn). Sau đó, bạn có một cái gì đó để chỉ ra khi vấn đề phát sinh. Ngoài ra, đừng ngại xem lại quyết định tiêu chuẩn. Công nghệ thay đổi (nhanh chóng) và do đó, nhu cầu của bạn như một nhóm và một công ty cũng có thể.

Giúp mọi người thấy những gì bạn thấy và cảm thấy như họ có cổ phần trong chất lượng của mã. Sau đó nhẹ nhàng thảo luận về việc tìm kiếm một tiêu chuẩn khi có sự khác biệt về quan điểm.

Thực hiện đánh giá mã mỗi khi ai đó muốn hợp nhất mã vào nhánh / thân chính và giữ mọi người theo các tiêu chuẩn đó khi xem lại mã.

Và tôi không có nghĩa là chỉ bạn nên thực hiện đánh giá mã. Mọi người nên xem lại mã của người khác. Điều này phổ biến kiến ​​thức về hệ thống trong toàn đội nhưng cũng tạo ra tình huống Carol xem xét mã của Bob và nói: "Tôi thấy bạn đã sử dụng một số nguyên ở đó. Tôi luôn sử dụng một enum." Họ phát hiện ra những khác biệt mà bạn đã thấy và, giả sử họ quan tâm, họ sẽ nhận ra rằng mọi người đều phải vào cùng một trang.

Các tiêu chuẩn được chấp nhận, đồng ý sẽ xuất hiện, tại thời điểm đó bạn ghi lại chúng và đảm bảo mọi người tuân theo chúng. Điều này sẽ bao gồm những thứ như "enums trong DB cho ...", v.v. Bạn cũng có thể bao gồm tài liệu để sử dụng khung nào, v.v.

Nếu có thể, bạn có thể viết các công cụ / tập lệnh để tự động phân tích các dự án của bạn và xác định các tiêu chuẩn, công cụ và phương pháp tiếp cận nào mà dự án đang sử dụng. Bạn có thể làm điều này bằng cách chạy một công cụ tùy chỉnh như là một phần của bản dựng CI.

Có đầu ra từ các công cụ được ghi vào tài liệu 'phiếu ghi điểm', ví dụ: một trang google với một hàng trên mỗi đơn vị (ví dụ: mỗi 'ứng dụng' hoặc dự án hoặc api hoặc bất cứ điều gì), với các cột cho các số liệu / tiêu chuẩn khác nhau được theo dõi. Điều này sẽ cung cấp cho mọi người tầm nhìn về những tiêu chuẩn nào, chúng được áp dụng tốt như thế nào, v.v. và cung cấp một số trật tự cho sự hỗn loạn.

Bạn cũng có thể cập nhật các cột theo cách thủ công, nhưng chúc may mắn giữ chúng cập nhật: D

Ngoài các câu trả lời được cung cấp, tôi nói bạn nên giáo dục nhóm của mình về những gì bạn mong đợi ở họ với tư cách là chuyên gia phát triển phần mềm, bắt đầu từ thời điểm họ phỏng vấn để gia nhập công ty.

1 - Tạo và làm theo các quy ước về cơ sở mã

Đây là một trong những biện pháp cơ bản nhất nhưng có lợi mà bạn có thể áp dụng để cải thiện chất lượng mã. Do kết quả của các quy ước sau, mã nguồn sẽ được thống nhất trong toàn bộ cơ sở mã, làm giảm nỗ lực nhận thức để tìm kiếm và đọc các tệp mã.

2 - Thực hiện các kiến ​​trúc phần mềm rõ ràng

Cơ sở mã của một dự án phần mềm không theo phong cách kiến ​​trúc rõ ràng, dù nó có thể là gì, dần dần xấu đi khi mã mới, không cấu trúc được thêm vào nó, trở nên khó sửa đổi hơn. Do đó, tầm quan trọng của việc dành hàng giờ cho việc thiết kế và bảo tồn kiến ​​trúc phần mềm đầy đủ.

3 - Ít hơn là tốt hơn: Ngôn ngữ, Khung và Công cụ

Với mỗi ngôn ngữ, khung và công cụ bổ sung mà bạn giới thiệu vào hệ thống của mình sẽ có thêm chi phí phát triển và vận hành. Bạn nên luôn luôn đánh giá chi phí dài hạn của một quyết định công nghệ trước khi đưa ra để giải quyết vấn đề ngắn hạn. Tránh các công nghệ dư thừa và tận dụng tối đa ngăn xếp hiện tại của bạn.

4 - Tham gia nhóm của bạn trong các quyết định thiết kế hệ thống

Cách hiệu quả nhất để xây dựng một môi trường tri thức được chia sẻ là liên quan đến nhóm trong tất cả các quyết định thiết kế hệ thống. Những lợi ích rất nhiều:

• Các cá nhân cảm thấy có giá trị và là một phần của đội
• Các quyết định quan trọng được thử thách bởi toàn đội trước khi đưa ra
• Điểm mạnh và điểm yếu của thiết kế hệ thống được mọi người hiểu rõ hơn
• Tạo ra ý thức trách nhiệm tập thể và tin tưởng

5 - Quy tắc tất cả trong

Tôi giữ quan điểm rằng các nỗ lực tái cấu trúc một thiết kế hệ thống nên được tiến hành để hoàn thành (toàn bộ), thay vì được kết luận một phần. Có nguy cơ lớn làm xói mòn thiết kế hệ thống của bạn nếu các nhà phát triển cảm thấy thoải mái khi áp dụng các kiểu mã hóa và mẫu kiến ​​trúc khác nhau bất cứ khi nào họ thấy phù hợp.

Đến thời điểm này, nếu bạn đã thực hiện thành công các đề xuất trước đó, nhóm của bạn hầu như sẽ đánh giá hành vi của nhà phát triển giả mạo này là không chuyên nghiệp và vô trách nhiệm.

Gần đây tôi đã viết một bài đăng blog về chủ đề này, bạn có thể tìm thấy thông tin chi tiết về các chủ đề này tại đó: https://thomasvilhena.com/2019/11/system-design-coherence