Chiến đấu (nhận thức) áp đảo so với đi với dòng chảy [đóng]

Tôi đã tham gia một nhóm có cách tiếp cận khác với thiết kế từ tôi. Tôi tin vào cách tiếp cận của YAGNI để thiết kế. Ví dụ, nếu một phương thức (giao diện, lớp) không được sử dụng, nó phải được loại bỏ. Đó là nó.

Mọi người trong nhóm của tôi đang xây dựng một ứng dụng mô-đun và một trong các mô-đun được coi là "khung". Ứng dụng này là người dùng duy nhất của khung này và hiện tại không có kế hoạch nào để có nhiều khách hàng hơn. Tuy nhiên, các phần của mã trong khung này được viết và duy trì như thể nó có thể được sử dụng sau này và tính nhất quán và hoàn chỉnh sẽ chiến thắng YAGNI. Có những thứ trừu tượng ở những nơi có thể không bao giờ cần trừu tượng, v.v.

Tôi đã cố gắng tranh luận một vài điều, nhưng mỗi điểm cần rất nhiều thời gian để thuyết phục, nếu có, và tôi sợ rằng việc "đẩy" quá nhiều sẽ dẫn đến việc đội chia thành hai phe đối nghịch.

Tôi có thể "đi theo dòng chảy" và viết thêm mã mà không có bất kỳ vấn đề cá nhân nào. Bây giờ tôi sẽ mất nhiều thời gian hơn để viết mã, và rất có thể, nhiều thời gian hơn để duy trì, tuy nhiên , mỗi cuộc thảo luận để không làm gì thêm cũng làm mất thời gian và thêm áp lực.

Câu hỏi là, trong trường hợp có nhiều ý kiến ​​khác nhau, điều gì sẽ làm một dịch vụ lớn hơn, mã không cần thiết nhưng "phù hợp", hoặc các đối số liên tục và động lực nhóm bị phá vỡ?

Duy trì một khung hình tưởng tượng là một quyết định có ý nghĩa về mặt kiến ​​trúc, vì vậy câu hỏi được đưa ra trong câu hỏi làm thế nào để chúng tôi đưa ra và phát triển kiến ​​trúc Hồi trong đội. Bạn phải bắt đầu với các quy tắc ra quyết định được xác định rõ ràng và được mọi người trong nhóm chấp nhận vì không có trò chơi nào mà không có quy tắc .

Khi gia nhập công ty, một trong những câu hỏi quan trọng nhất bạn có thể hỏi là -

Làm thế nào để quá trình ra quyết định làm việc trong nhóm và làm thế nào nó phát triển theo thời gian?

Không có quá trình ra quyết định tồi tệ hơn quá trình ra quyết định tồi . nếu không có quy trình, ai đó cần xác định một. Mặt khác, số lượng vô nghĩa tăng lên cùng với số lượng bất đồng với đội.

Tôi nghĩ với điều này, chúng tôi sẽ đóng vòng lặp - hoặc bạn có thẩm quyền và quyền hạn để xác định quy trình ra quyết định khi nó bị thiếu HOẶC bạn đồng ý với quy trình hiện tại / và cách thức phát triển. Chọn một.

Lập luận liên tục và động lực nhóm bị phá vỡ sẽ không bao giờ giúp bạn đi rất xa.

Tôi sẽ cố gắng để hiểu tại sao có một khuôn khổ ở nơi đầu tiên.

Nhiều khả năng lý do là nó dự kiến ​​sẽ được sử dụng trong các hệ thống khác sau này. Nếu đó là trường hợp thì nó có ý nghĩa để làm nhiều hơn là cần thiết ngay bây giờ.

Lý do là nếu một ứng dụng đang được sản xuất, một ứng dụng mới đang được tiến hành yêu cầu cập nhật khung, sau đó mỗi khi có gì đó thay đổi trong khung, có lẽ các bản tóm tắt không cần thiết trước đó được thêm vào, thì ứng dụng gốc phải được cập nhật và được thử nghiệm là tốt.

Đó là rất nhiều tái cấu trúc và kiểm tra lại một cái gì đó trong sản xuất.

Nếu bạn chọn không bao gồm khung được cập nhật trong ứng dụng cũ, thì bạn có 2 khung để duy trì một trong số đó đã lỗi thời.

Duy trì mã lỗi thời cũng không tốt cho tinh thần.

Nếu bạn chưa quen với một đội, cố gắng không làm xáo trộn lực lượng sẽ là mối quan tâm đầu tiên của bạn .

Tôi cho rằng bạn không ở vị trí lãnh đạo / kiến ​​trúc sư và các quyết định không phụ thuộc vào bạn.

Các thứ hai mối quan tâm là tìm hiểu . Học được rất nhiều. Tìm hiểu lý do tại sao họ đưa ra quyết định, tại sao khung được tạo ra, lý do đằng sau đó là gì. Khi bạn có tất cả thông tin, sau đó bạn có thể đưa ra quyết định có căn cứ về cách tiếp cận các vấn đề có thể xảy ra, chẳng hạn như áp đảo và giao tiếp xấu.

Đặt câu hỏi, một cách lịch sự . Đặt mình vào vị trí của một sinh viên, và không phải là một bậc thầy. Mọi người sẽ dễ dàng "dạy" bạn hơn tại sao họ lại làm như vậy.

Ngay bây giờ bạn là người bị ruồng bỏ. Bạn đang tham gia một đội nước ngoài, và bạn nên tìm hiểu phong tục của họ và tự thích nghi.

Nếu bạn làm công việc của mình đúng cách, với cách tiếp cận lịch sự với mọi người, mọi người sẽ tự nhiên lắng nghe bạn theo thời gian. Và sau đó, nếu bạn hoàn toàn đúng khi nói rằng phương pháp của bạn là phương pháp tốt nhất nói chung, bạn có thể tác động đến mọi người để thay đổi.

Tôi hầu như không biết ai thích làm việc với một người thường chỉ trích, nhưng không tạo ra giá trị. Hãy tham khảo nhóm của bạn, một người mà họ tự hào khi làm việc cùng.

Ngoài ra, nên đọc: https://www.amazon.com/How-Win-Friends-Influence-P People / dp / 0671027034

Có 2 điều cơ bản tôi nghĩ đang xảy ra. Đầu tiên là văn hóa. Bạn là người mới trong nhóm và bạn chưa tìm ra cách làm việc với nhóm này. Họ có thể có các chính sách và thực tiễn khác nhau có thể thực sự làm việc cho họ. Ngoài ra một hoặc nhiều trong số họ có thể đã áp dụng cho vị trí của bạn và vì vậy họ có thể đang tích cực phá hoại những nỗ lực của bạn hoặc chỉ không nói cho bạn biết những gì bạn cần biết.

Thứ hai là bạn có thể đã đọc sai thiết kế. Phần mà bạn nghĩ là mã chết thực sự có thể là sự khái quát hóa các phần khác của thiết kế hoặc nó có thể đang hoạt động để hỗ trợ một cái gì đó mà doanh nghiệp muốn cuối cùng hỗ trợ. Nó thực sự có thể là mã chết. Ngừng ám ảnh về nó và hiểu tại sao nó ở đó. Nó thực sự có thể mất vài tháng để tìm ra.

Trong các ngành công nghiệp không thích rủi ro (ví dụ: ngân hàng, trung gian ...) trong đó có khả năng nhỏ là một đoạn mã có thể được sử dụng, đoạn mã đó sẽ tồn tại trong nhiều thập kỷ.

Để làm nổi bật điều này, một trong những cấu trúc cơ sở dữ liệu lạ mà tôi đã thấy tập trung xung quanh 6 bảng. 3 trong số chúng là các bảng ánh xạ kết nối ba bảng còn lại. Nó không có ý nghĩa gì khi mã chỉ ra rằng chỉ có một chúng được sử dụng như một mối quan hệ nhiều-nhiều và hai cái còn lại đang thực hiện một-nhiều. Các nhà thiết kế ban đầu của điều này đã rời đi và không ai có thể giải thích chính xác làm thế nào hoặc tại sao nó hoạt động. Cuối cùng, tôi tình cờ thấy một tài liệu kinh doanh giải thích về thiết kế - vì vậy tôi đoán là doanh nghiệp đã yêu cầu và một số DBA chỉ thực hiện theo cách mà doanh nghiệp có thể hiểu - mặc dù có những hạn chế rõ ràng. 30 năm sau nó vẫn ở đó, kiếm tiền của công ty - nhưng từ quan điểm phát triển khó hiểu, duy trì và phát triển cùng.

Tôi thấy một số điểm tốt về việc có một phần như vậy ra khỏi ứng dụng ngay cả khi không có ai sử dụng nó.

Điều này có thể thực thi sự phát triển của các chức năng kỹ thuật trong khung với các thử nghiệm thích hợp của chúng bên ngoài bối cảnh chức năng của ứng dụng (và trên lộ trình riêng của nó).

Hơn nữa, có thể bạn không muốn mọi nhà phát triển chạm vào khung đó mà chỉ những người cao niên nhất, vì vậy một lần nữa đưa nó ra ngoài ứng dụng là một lợi thế.

Đối với các lớp trừu tượng không cần thiết, tốt, nếu chúng đã ở đó, đừng thay đổi thứ gì đó đã hoạt động.

Tuy nhiên, bạn có thể nhớ cho nhóm của mình trong tương lai rằng mục tiêu của khung là làm nhẹ công việc của bạn, không làm nặng thêm.

Đọc giữa dòng, tôi nghiêng về các thành viên trong nhóm của bạn. Làm cho một cái gì đó "phức tạp hơn mức cần thiết" không chỉ mở đường cho chức năng tương lai có thể không bao giờ cần thiết, nó còn phục vụ sự hiểu biết của nhà phát triển về ứng dụng, nó kết hợp một mô hình trong phần mềm, nó ghi lại một ý tưởng.

Và làm như vậy nó hạn chế cách phát triển trong tương lai có thể đi. Nó giữ cho các nhà phát triển không hoàn toàn nắm bắt được thiết kế / ý định đi lạc.

Một nhà phát triển mới lúc đầu có thể khó chịu với thiết kế "phức tạp không cần thiết", nhưng nó cũng hướng dẫn anh ta đi đúng hướng, điều đó khiến anh ta rơi vào hố thành công và khiến anh ta khó "làm mọi thứ theo cách của mình" sẽ chỉ là một cách khác thực sự làm phức tạp mọi thứ bởi vì nó sẽ dẫn đến các cách tiếp cận khác nhau trong cùng một ứng dụng, điều này khiến cho người tiếp theo khó khăn hơn trong việc xoay quanh nó.

YAGNI không (hoặc không nên) có nghĩa là "bạn có thể bỏ qua thiết kế" hoặc "làm nhanh và bẩn". Nếu đội của bạn có suy nghĩ xa xỉ thì tôi sẽ nói đó là điều đáng trân trọng hơn là chiến đấu.