Viết Phần mềm tuyệt vời

Question

Tôi hiện đang đọc Phân tích và thiết kế hướng đối tượng của Head First. Cuốn sách nói rằng để viết phần mềm tuyệt vời (tức là phần mềm được thiết kế tốt, được mã hóa tốt, dễ bảo trì, tái sử dụng và mở rộng), bạn cần phải làm ba việc sau:

1. Đầu tiên, hãy đảm bảo phần mềm tất cả mọi thứ khách hàng muốn nó làm
2. Sau khi hoàn thành bước 1, áp dụng các nguyên tắc và kỹ thuật hướng đối tượng để loại bỏ bất kỳ mã trùng lặp nào có thể bị trượt trong
3. Sau khi bước 1 và 2 hoàn tất, sau đó áp dụng các mẫu thiết kế để đảm bảo phần mềm này có thể duy trì và tái sử dụng trong nhiều năm tới.

Câu hỏi của tôi là, bạn có làm theo các bước này và theo thứ tự này khi phát triển phần mềm tuyệt vời? Nếu không, bạn thường làm theo các bước nào để đảm bảo nó được thiết kế tốt, được mã hóa tốt, dễ bảo trì, tái sử dụng và mở rộng?

Answer 1

Tôi đã đọc cuốn sách này. Tôi nghĩ rằng có một số giải thích sai ở khắp mọi nơi.

1. Thứ nhất, đảm bảo các phần mềm làm mọi thứ khách hàng muốn nó để làm

   Cuốn sách được nói chắc chắn rằng bạn hiểu các yêu cầu của khách hàng trước khi bắt đầu thiết kế.

2. Khi bước 1 hoàn tất, áp dụng Object Oriented nguyên tắc và kỹ thuật để loại bỏ bất kỳ mã trùng lặp mà có thể đã bị trượt trong

   Cuốn sách nói đến thiết kế với nguyên tắc OO

3. Khi bước 1 và 2 đã hoàn thành, sau đó áp dụng các mẫu thiết kế để đảm bảo phần mềm được duy trì và có thể sử dụng lại trong nhiều năm tới.

   Sử dụng mẫu thiết kế.

Answer 2

Tôi không đồng ý với # 1 vì hầu hết các phần mềm tuyệt vời đều cần một số lần lặp lại lớn để trở thành thực sự tuyệt vời. Chỉ khác cách để thực sự đạt đượC# 1 (trong lần thử đầu tiên) là sao chép một số phần mềm đã sẵn sàng khác. Nhưng để tìm ra điều gì đó mới mẻ và độc đáo (như tôi đã làm với ClipMate vào năm 1991), bạn hãy nỗ lực hết mình, sau đó phát hành nó cho mọi người để xem khách hàng phải nói gì về nó. Thông qua các chu kỳ lặp lại của việc đánh giá lại sản phẩm do kết quả đầu vào và tương tác của khách hàng, cuối cùng bạn sẽ đạt được phần mềm tuyệt vời.

Answer 3

Định hướng đối tượng không phải là điều bạn nghĩ đến như một suy nghĩ - bạn bắt đầu với phân tích và thiết kế OO và tiến hành triển khai OO. Tôi nghi ngờ bạn có thể đã đọc sai hoặc hiểu sai cuốn sách. Tương tự như vậy với các mẫu thiết kế - chúng không phải là tiện ích bổ sung.

Answer 4

Tôi thường bắt đầu với thiết kế hướng đối tượng. Nó sẽ phải là một bẩn/hack khá nhanh chóng không cần # 2 và # 3. Vấn đề là, không để quá liều vào chúng.

Answer 5

Nếu tôi diễn giải chính xác, điều đó nghe có vẻ hơi lố bịch. Nhưng có lẽ ý định là đúng - 1) có thể được diễn giải là "ở lại tập trung", đặc biệt tập trung vào nhu cầu kinh doanh. Điều đó không có nghĩa là bỏ qua tất cả các nhu cầu mã hóa, nhưng nhận được sự cân bằng đúng. Có rất nhiều thay đổi mã và tái cấu trúc mà không nghi ngờ gì là cải thiện chất lượng của mã, nhưng chúng phải được tăng trọng so với thời gian, rủi ro và sự chậm trễ gây ra cho dự án. Là một nhà phát triển, tất cả quá dễ dàng để (trên) ưu tiên các thay đổi mã trên nhu cầu kinh doanh.

Áp dụng nguyên tắc OO sau đó có vẻ không thực tế - nếu bạn chưa sử dụng nguyên tắc OO, phần mềm thực hiện những gì khách hàng muốn xây dựng ngay từ đầu? Có lẽ đó là gợi ý để tái cấu trúc liên tục, KISS, và giảm thiết kế phía trước ủng hộ một chu kỳ phát triển lặp đi lặp lại.

Có một yếu tố của sự thật trong 3) - nhận dạng các mẫu sau khi phần mềm được xây dựng và tái cấu trúc để cô lập các phần tử lặp đi lặp lại phổ biến, nhưng tôi nghĩ đây là một hậu quả tự nhiên của chu kỳ phát triển lặp lại.

Answer 6

Phần mềm tuyệt vời đầu tiên và quan trọng nhất phải làm mọi thứ mà khách hàng cần để thực hiện và ít nhất hầu hết những gì khách hàng muốn. Đây không phải là điều tương tự. Ngoài ra nó là tốt hơn để bắt đầu với một cái gì đó nhỏ và đơn giản, và phát triển nó hơn là cố gắng để xây dựng tất cả mọi thứ trong một ứng dụng ginormous.

Đối với hai điểm còn lại, chúng có vẻ hơi bối rối. Tránh trùng lặp là một nguyên tắc thiết kế, nhưng chỉ một trong nhiều nguyên tắc. Tại sao đơn nó ra để xem xét đặc biệt?Thay vì (nói) Lập trình với giao diện? Hoặc Nói không hỏi? Hoặc Tránh cửa sổ bị hỏng?

Hmmmm ...

Khi tôi bắt đầu gõ câu trả lời này, tôi có ý định nói rằng tôi không nghĩ rằng bạn có thể trang bị thêm các kỹ thuật OO hoặc các mẫu thiết kế. Nhưng có suy nghĩ về nó một số chi tiết nó đã xảy ra với tôi rằng đây không phải là trường hợp. Nó là khá phổ biến trong TDD thực hành cho việc thực hiện ban đầu - điều đơn giản nhất mà được mã để vượt qua thử nghiệm - được khá thủ tục. Nhưng một khi mã vượt qua các thử nghiệm của nó thì có một chu kỳ tái cấu trúc áp dụng các mẫu thiết kế và tạo ra một thực hiện hướng đối tượng hơn.

Answer 7

Phần mềm tuyệt vời dựa trên thiết kế tốt và lập trình sạch sẽ với mẫu thiết kế phê duyệt (MVC, thành phần quá trình ..).