Thế nào là một source/design tốt ?

Câu hỏi:

Đứng trước một bản design, một mã nguồn; tiêu chí nào để đánh giá rằng bản design đó tốt hay dở, source code đó tốt hay dở ?

Trả lời cua anh cl

Đọc source dễ biết trình độ của coder.
Đọc design doc trình bày theo kiểu problem và possible solutions thì dễ bắt được lối suy nghĩ của tác giả. Tuy nhiên việc đánh giá còn tùy vào nhiều thứ chung quanh nữa.

----------------------------------------

Quoted from truonglapvi

Như vậy có cảm tính quá không anh ? Có 2 trường hợp
1. Người đọc có rất nhiều kinh nghiệm và nhận xét được. Cái này thì pass :)
2. Người đọc muốn học/rút kinh nghiệm từ code đang có. Làm sao bây giờ ?

Đọc code chứ phải đọc fiction đâu mà có chuyện cảm tính trong này. Những tiêu chuẩn dùng để đánh giá như style guide, best practice, bug patterns... rõ ràng đến mức có thể "tự động hoá việc đọc" bằng những tiện ích như findbugs thì cảm tính len vô từ đâu? Kinh nghiệm chỉ liên quan với tốc độ nhận định, người có kinh nghiệm tới đâu cũng học được vài điều khi đọc code.

Quoted from truonglapvi

...
I consider these issues to be important. However, I consider the intent of the programmer to be more important. If the programmer is trying his/her best to produce the best code possible in the time given, and not cut corners, then the code is as good as it can be.

Câu này rất chính xác. Có điều, lấy tiêu chuẩn gì để đánh giá là không có short-cut? ;-)

Quoted from truonglapvi

Một câu nói thường nghe là: "source code này chạy được rồi và không thấy bug cho dù vi phạm hết những gì anh đưa ra". Làm sao để thuyết phục một người viết nó tốt hơn?

Liên quan với câu trên của big Bob, phải không? ;-) Không ai thuyết phục được ai cả nếu không có những tiêu chuẩn đặt trước, chạy được functional test là một chuyện còn những thứ non-functional khác (nếu có) thì sao?

Quoted from truonglapvi

Hình như design mà anh nói thiên về giải pháp and/or overview and/or architecture nhiều hơn là design có thể cài đặt code ngay (design ở mức gần gũi với code) ?

Những thứ xung quanh có phải là về mặt văn phong, cách trình bày ... ?
Không có problem nào được giải quyết mà không có problem statement. Không có giải pháp nào là tuyệt đối cả. Software engineer phải nhận định được vấn đề và phải đưa ra ít nhất hai gải pháp cho vấn đề đó. Công việc này được lập lại ở tầng thấp nhất và cần được "capture" trong documentation (hay code) chú 1 mớ UML lằn nhằn không có nghĩa lý gì cả?
Những thứ xung quanh cụ thể tới constraints của project.