Phần cứng hướng đối tượng

Tôi đến từ một nền tảng OO mạnh mẽ và gần đây tôi đã bắt đầu làm việc trong một tổ chức, mặc dù mã được viết bằng Java, ít chú trọng đến thiết kế OO tốt hơn so với những gì tôi đã từng sử dụng. Tôi đã được thông báo rằng tôi giới thiệu "quá nhiều trừu tượng" và thay vào đó tôi nên viết mã theo cách nó luôn được thực hiện, đó là một kiểu thủ tục trong Java.

TDD cũng không được thực hành nhiều ở đây, nhưng tôi muốn có mã kiểm tra. Chôn logic kinh doanh trong các phương thức riêng tư tĩnh trong các "lớp Thần" lớn (dường như là chuẩn mực cho nhóm này) là không thể kiểm chứng được.

Tôi đấu tranh trong việc truyền đạt rõ ràng động lực của mình với đồng nghiệp. Có ai có một số lời khuyên về cách tôi có thể thuyết phục đồng nghiệp của mình rằng sử dụng OO và TDD dẫn đến mã dễ duy trì hơn không?

Câu hỏi này về nợ kỹ thuật có liên quan đến câu hỏi của tôi. Tuy nhiên, tôi đang cố gắng tránh phát sinh khoản nợ ngay từ đầu, trái ngược với việc trả nó sau khi thực tế đó là những gì câu hỏi khác đề cập.

Bạn đã không phàn nàn về nó là không thể nhầm lẫn, chỉ là không theo ý thích của bạn. Nếu đó là một sự lựa chọn phong cách có chủ ý, nó có thể chỉ là một trường hợp khác biệt sáng tạo không thể hòa giải, và bạn nên điều chỉnh phong cách của mình cho phù hợp, hoặc tìm một nơi nào đó phù hợp với phong cách ưa thích của bạn.

Mọi người có thể và thực hiện viết mã mô-đun, hiệu quả, trừu tượng hóa, tương đối không có lỗi theo kiểu thủ tục mọi lúc. Java là một lựa chọn ngôn ngữ kỳ quặc cho một cửa hàng như vậy, nhưng tôi có thể thấy điều đó xảy ra nếu các yếu tố bên ngoài quyết định ngôn ngữ, chẳng hạn như cần phát triển cho Android chẳng hạn.

Mọi người đều là một thiên tài. Nhưng nếu bạn đánh giá một con cá bằng khả năng trèo cây, nó sẽ sống cả đời với niềm tin rằng nó thật ngu ngốc. - Albert Einstein

Nếu đó là một sự lựa chọn có chủ ý, bạn thực sự không thể đánh giá họ bằng cách họ tuân thủ tốt các nguyên tắc thiết kế hướng đối tượng tốt như thế nào, bạn nên đánh giá xem họ tuân thủ tốt các nguyên tắc thiết kế thủ tục tốt như thế nào, và cũng tái cấu trúc theo đó. Java không cho phép bạn viết mã bên ngoài một lớp, vì vậy sự hiện diện của một người không có nghĩa là họ dự định một mô-đun hướng đối tượng.

Mặt khác, nếu mã là một mớ hỗn độn trong cả hai mô hình, có lẽ bạn chỉ nên cắt lỗ.

Đọc câu hỏi của bạn, tôi nhớ một mẹo của cuốn sách Lập trình viên thực dụng.

Một trong những lời khuyên của nó là Be a Catalyst for Change:

Bạn có thể đang ở trong một tình huống mà bạn biết chính xác những gì cần làm và làm thế nào để làm điều đó. Toàn bộ hệ thống chỉ xuất hiện trước mắt bạn. Bạn biết đó là đúng. Nhưng hãy xin phép để giải quyết toàn bộ sự việc và bạn sẽ gặp phải sự chậm trễ và những cái nhìn trống rỗng. Mọi người sẽ thành lập ủy ban, ngân sách sẽ cần phê duyệt và mọi thứ sẽ trở nên phức tạp. Mọi người sẽ bảo vệ tài nguyên của riêng họ. Đôi khi điều này được gọi là "mệt mỏi khởi động."

Đã đến lúc nấu Stone Soup. Tìm ra những gì bạn có thể yêu cầu hợp lý. Phát triển nó tốt. Khi bạn đã có nó, hãy cho mọi người thấy và để họ ngạc nhiên. Sau đó nói "tất nhiên, sẽ tốt hơn nếu chúng tôi thêm vào." Giả vờ nó không quan trọng. Ngồi lại và chờ đợi họ bắt đầu yêu cầu bạn thêm chức năng bạn muốn ban đầu. Mọi người thấy dễ dàng hơn để tham gia một thành công liên tục. Cho họ thấy một cái nhìn thoáng qua về tương lai và bạn sẽ khiến họ tập hợp xung quanh.

Vì vậy, tôi nghĩ rằng nếu bạn bắt đầu làm tốt công việc với kiến ​​thức OO và TDD của mình, chẳng mấy chốc họ sẽ bắt đầu nhìn và hỏi về công việc của bạn.

Để bán những cách mới để làm việc, bạn cần thể hiện những lợi ích rõ ràng. Viết nhiều lớp trừu tượng hơn, không có lợi ích rõ ràng nhưng mơ hồ: "nó có thể có ích cho tương lai" sẽ không hiệu quả.

Làm cho các nhà máy nơi các nhà máy tạo ra nhiều hơn một loại đối tượng. Sử dụng tiêm phụ thuộc, nơi nó ngay lập tức cho thấy lợi ích. Tạo các giao diện thực sự sẽ được thực hiện bởi nhiều hơn một lớp.

Điều tôi thấy quá thường xuyên trong "OO thực sự" là các kỹ thuật tiên tiến được sử dụng để giải quyết các vấn đề thực sự đơn giản theo cách quá phức tạp.

Làm thế nào bạn có thể cho thấy lợi ích của một nhà máy nếu nó chỉ bao giờ sẽ tạo ra cùng một đối tượng? Tìm một vấn đề trong mã của bạn có lợi từ các kỹ thuật nâng cao và cho thấy quan điểm của bạn và làm việc từ đó.

Chiến tranh được chiến thắng một trận tại một thời điểm.

Bạn chỉ có thể thuyết phục họ bằng cách sử dụng một đoạn mã nhỏ và triển khai TDD và thực hành OO tốt hơn trên đó để nhận ra lợi ích. Bạn đã dẫn họ đến miền đất hứa, không chỉ hiển thị những tấm bưu thiếp đẹp của nó.

Chắc chắn, tôi nghĩ rằng có những trường hợp quá trừu tượng được sử dụng trong nhiều cơ sở mã ngày nay. Chỉ đưa vào những gì bạn cần, và bao gồm cả trừu tượng là tốt.