Tôi đã dành rất nhiều thời gian để đọc các cuốn sách khác nhau về "thiết kế tốt", "mẫu thiết kế", v.v. Tôi là một fan hâm mộ lớn của phương pháp RẮN và mỗi khi tôi cần viết một đoạn mã đơn giản, tôi nghĩ về tương lai. Vì vậy, nếu triển khai một tính năng mới hoặc sửa lỗi yêu cầu chỉ cần thêm ba dòng mã như thế này:
if(xxx) {
doSomething();
}Điều đó không có nghĩa là tôi sẽ làm theo cách này. Nếu tôi cảm thấy đoạn mã này có khả năng trở nên lớn hơn trong tương lai gần nhất, tôi sẽ nghĩ đến việc thêm trừu tượng, di chuyển chức năng này sang một nơi khác và cứ thế. Mục tiêu tôi đang theo đuổi là giữ độ phức tạp trung bình giống như trước khi tôi thay đổi.
Tôi tin rằng, từ quan điểm mã, đó là một ý tưởng khá hay - mã của tôi không bao giờ đủ dài và khá dễ hiểu ý nghĩa của các thực thể khác nhau, như các lớp, phương thức và quan hệ giữa các lớp và các đối tượng.
Vấn đề là, nó tốn quá nhiều thời gian và tôi thường cảm thấy sẽ tốt hơn nếu tôi chỉ thực hiện tính năng đó "như hiện tại". Đó chỉ là về "ba dòng mã" so với "giao diện mới + hai lớp để thực hiện giao diện đó".
Từ quan điểm sản phẩm (khi chúng ta nói về kết quả ), những điều tôi làm là khá vô nghĩa. Tôi biết rằng nếu chúng ta sẽ làm việc trên phiên bản tiếp theo, có mã tốt thực sự rất tuyệt. Nhưng mặt khác, thời gian bạn dành để làm cho mã của mình "tốt" có thể đã được dành cho việc triển khai một vài tính năng hữu ích.
Tôi thường cảm thấy rất không hài lòng với kết quả của mình - mã tốt chỉ có thể làm A còn tệ hơn mã xấu có thể làm A, B, C và D.
Cách tiếp cận này có khả năng dẫn đến lợi ích ròng tích cực cho một dự án phần mềm, hay nó là một sự lãng phí thời gian?