Một mẹo tôi thấy rất hữu ích và nó đã giúp tôi trong quá khứ là viết doc trước, trong và sau khi bạn viết mã.
Khi thiết kế một API để người khác sử dụng, tôi thường ghi lại thiết kế trước khi viết mã. Nếu tôi đã qua kỹ thuật thiết kế, thông số kỹ thuật thiết kế thường đầy xung đột và vô nghĩa.
Trong quá trình mã hóa, tôi thường loại bỏ định nghĩa lớp và hàm chức năng và bắt đầu viết nhận xét doxygen cho chúng. Trong các ý kiến tôi sẽ có trường hợp sử dụng, mã mẫu và các giả định của các giao diện. Trong giai đoạn này, trước khi quá nhiều mã thực được viết, giao diện lớp thường trải qua quá trình thiết kế lại nhiều lần. Tôi biết tôi đã qua kỹ thuật khi mã mẫu khó viết và tôi có một thời gian khó giải thích giao diện. Rất nhiều ý tưởng thiết kế xấu được tiếp xúc và loại bỏ khi bạn cố gắng giải thích cho mọi người cách sử dụng API của bạn.
Sau khi mã hóa, tôi thay thế mã mẫu trong các nhận xét bằng mã được biên dịch và kiểm tra thực được sao chép từ các bài kiểm tra đơn vị của tôi và ghi lại thêm hành vi của giao diện. Một dấu hiệu khác của kỹ thuật là khi các bài kiểm tra đơn vị của tôi không thể theo kịp với sự thay đổi giao diện bởi vì có quá nhiều phần chuyển động và quá nhiều cách để làm điều tương tự và kiểm tra đơn vị tăng trưởng theo tỷ lệ mũ.
Nguồn
2009-06-04 05:35:22
Có vẻ như có liên quan: http://stackoverflow.com/questions/469161/how-do-you-define-a-good-or-bad-api http://stackoverflow.com/questions/750112/overengineering -how-to-avoid-it –