Bạn nên tạo sơ đồ lớp trước hoặc sau khi thực hiện?

Cách tôi nhìn thấy nếu bạn tạo một cái trước khi bạn có được lợi thế:

• Lập kế hoạch trước
• Tổng quan về dự án

nhưng bạn thua:

• Thời gian (làm việc có thể bạn sẽ lặp lại khi viết mã)

Mặt khác, tôi chỉ có thể tạo tất cả chúng sau khi viết mã của mình chỉ để giữ nó làm tài liệu tham khảo cho các nhà phát triển trong tương lai.

Cái nào phục vụ mục đích của sơ đồ lớp và cái nào có lợi hơn?

Nếu bạn tạo chúng trước đó, chúng sẽ là một phần của giai đoạn thiết kế.

Nếu bạn tạo chúng sau, bạn chỉ có thể sử dụng chúng cho tài liệu. Nhưng tài liệu sẽ tốt hơn và nhanh hơn nếu bạn làm điều đó trong quá trình thiết kế và mã hóa.

Nhân tiện, bạn không mất thời gian trong việc thiết kế! Phần mã hóa sẽ nhanh hơn. Và tốt hơn.

Rốt cuộc, bạn nghĩ rằng việc thiết kế một tòa nhà chọc trời hoặc một cây cầu là mất thời gian thay vì chỉ bắt đầu xây dựng nó?

Một thỏa hiệp là bắt đầu tạo một số mã giả trong giai đoạn thiết kế (chỉ là nguyên mẫu của các lớp / hàm) và sử dụng khung mã này để xây dựng các sơ đồ lớp.

Khi tôi đã tạo chúng trước khi mã hóa, chúng tôi xem chúng là tài liệu "tạm thời". Đó là, chúng tôi tạo ra các sơ đồ và suy nghĩ của chúng tôi trên giấy. Chúng tôi bắt đầu mã hóa từ các sơ đồ lớp. Chúng tôi sau đó ném chúng ra. Không đáng để dành thời gian để duy trì chúng khi mã hóa đã bắt đầu. Và nếu bạn muốn các mô hình lớp cập nhật, hãy sử dụng một công cụ để tạo chúng từ mã.

Trong cả hai trường hợp, họ sẽ dính xung quanh như là một phần của tài liệu. Không ai sẽ cập nhật chúng khi thay đổi được thực hiện. Các sơ đồ sẽ không có ngày trên chúng để bạn thậm chí không biết phiên bản mã mà chúng đề cập đến. Khi một người mới được thêm vào dự án, bạn sẽ đưa cho người đó sơ đồ có nội dung "Đây là một số sơ đồ được tạo tại một số thời điểm trong quá trình thiết kế hoặc thực hiện. Chúng tôi không biết chúng cập nhật như thế nào."

Đây là một phần của thiết kế và do đó nên được tạo ra trước khi thực hiện. Điều này không có nghĩa là chúng không thể được tinh chỉnh trong / sau khi thực hiện để phản ánh trạng thái triển khai hiện tại.

Cung cấp một thiết kế sau khi thực hiện là cái mà tôi gọi là "mã hóa cao bồi" và chắc chắn rằng bạn có thể phát triển mạnh ở miền tây hoang dã hoang dã nhưng hãy nhớ rằng những chàng cao bồi thường sẽ chết vào lúc này hay lúc khác.

Nó phụ thuộc vào độ sâu của thiết kế. Một số người khăng khăng viết sơ đồ lớp cho cả những lớp tầm thường nhất, bởi vì "đó là cách thực hành tốt". Tôi nghĩ thật lãng phí thời gian để vẽ một cái gì đó khi bạn đã biết chính xác nó sẽ được thực hiện như thế nào. Khi tạo ra một thiết kế mới, một cái gì đó không quen thuộc, chắc chắn sẽ hữu ích khi vẽ một số sơ đồ trước.

Mặc dù vậy, tôi không bao giờ sử dụng các công cụ UML, vì thiết kế thường thay đổi rất nhiều trong quá trình thực hiện nên tôi phải vẽ lại sơ đồ. Tôi cho rằng một công cụ hai chiều tốt sẽ xử lý những thay đổi này, nhưng tôi chưa bao giờ sử dụng một công cụ tốt (mặc dù tôi chỉ sử dụng những công cụ miễn phí). Thay vào đó, tôi vẽ trên giấy hoặc trên bảng trắng để giúp tôi sắp xếp thiết kế. Sau khi tôi thực hiện nó và chắc chắn rằng nó có âm thanh, tôi sẽ làm một sơ đồ chính thức hơn.

Ngoài ra, đừng quên các loại sơ đồ khác. Tôi luôn thấy các sơ đồ trình tự là một trong những sơ đồ hữu ích nhất và tôi thường sử dụng chúng khi có nhiều giao tiếp giữa các thành phần.

Trước khi thực hiện. Như một trong những đồng nghiệp cũ của tôi đã từng nói 'Tôi thích lập trình càng nhiều càng tốt trước khi tôi bắt đầu viết mã' và tôi nghĩ đó là một cách tiếp cận tốt với nó.

Tôi thấy rằng hành động vẽ sơ đồ thường cảnh báo tôi về thông tin bị thiếu. Điều này cũng sẽ xảy ra nếu tôi chỉ gõ một trình soạn thảo mã mà không vẽ sơ đồ, nhưng các trường hợp sẽ cách xa nhau hơn (vì tôi sẽ dành thời gian để viết các thuật toán và tính toán và kiểm tra, v.v.) và vì vậy tôi có thể cho phép nhiều thời gian hơn để đi qua trước khi nhận được thông tin còn thiếu của tôi.

Ngoài ra, nếu thiết kế mà bạn mơ hồ có trong đầu hóa ra là tào lao, bạn sẽ nhận thấy điều đó nhanh hơn nếu bạn vẽ sơ đồ đó trước. Vì vậy, tôi ít nhất rút ra một cái gì đó nhanh chóng và không chính thức. Việc nó biến thành sơ đồ điện tử mà người khác có thể sử dụng để tham khảo hay không sẽ phụ thuộc vào dự án.

Việc tạo sơ đồ lớp nên được thực hiện, trong và sau vì mô hình phải tương tác với mã và sửa đổi yêu cầu. Đầu tiên bạn cần tạo một sơ đồ lớp để bắt đầu dự án của bạn. Nó sẽ giúp hình dung ở mức độ trừu tượng cao hơn đối tượng của bạn. Bạn sẽ có thể tạo ra một kiến ​​trúc phần mềm ổn định và thông minh. Sau đó, bạn cần mã hóa và đôi khi bạn sẽ nhận thấy rằng kiến ​​trúc có vẻ tốt trong UML là không thực sự có thể có trong mã. Sau đó, bạn thay đổi mã và kiến ​​trúc của bạn. Cuối cùng, bạn cập nhật mô hình của mình với sửa đổi mã và tạo tài liệu.

Trong quyết định dự án cuối cùng của tôi, những người ra quyết định đã thay đổi yêu cầu của tôi hơn 50 lần trong năm ngoái. Nó thực sự đau đớn và UML giúp tôi giữ truy xuất nguồn gốc của các thay đổi và tại sao. UML nên cho phép hợp nhất mô hình và mã bất cứ lúc nào theo cách lặp (ví dụ từ mã này sang mô hình, từ mô hình đến mã, từ cả hai, từ mã sau khi tái cấu trúc, v.v.) Tôi sử dụng Omondo EclipseUML cho Helios và tôi thực sự hài lòng với Công cụ này. Tính năng yêu thích của tôi là hợp nhất mô hình cho phép tôi cập nhật mô hình của mình bất cứ lúc nào mà không mất thông tin mô hình. Tôi cũng thích các thực thể mô hình hóa trực tiếp trong sơ đồ lớp và tạo cơ sở dữ liệu bằng cách sử dụng bản mẫu và ngủ đông. Thực sự mạnh mẽ và đầy đủ từ đối tượng đến cơ sở dữ liệu !!

Trước : nó sẽ giúp tổ chức những suy nghĩ của bạn và truyền đạt ý định của bạn. Đừng đi vào chi tiết ở đây.

Sau : nó tự động được tạo từ mã như một phần của quá trình xây dựng, rõ ràng (hy vọng bạn không quá gắn bó với uml)

Cả hai đều hữu ích, nhưng những thứ trước đây có thể bị loại bỏ ngay khi nó được triển khai ... dù sao nó cũng đã lỗi thời.

Với Topcasing , tôi tạo sơ đồ lớp trong giai đoạn thiết kế. Sau đó, tôi nhấp vào nút "Tạo mã" để tạo ra một khung vẽ triển khai của tôi. Sau đó, tôi điền vào chỗ dành sẵn với mã.

Tôi sẽ bỏ phiếu cho câu trả lời (C) Đừng bận tâm.

Chúng hầu như không cần thiết. Cá nhân, tôi không bao giờ bận tâm để nhìn vào họ khi họ được cung cấp.

Chúng không cần thiết trước khi phát triển, vì thiết kế sẽ thay đổi. Và nếu bạn không nghĩ rằng thiết kế của các lớp học của bạn sẽ thay đổi, thì bạn đã tự còng tay mình và ngăn bản thân tương lai của bạn không thể giải quyết vấn đề một cách chính xác. Nếu bạn nghĩ rằng bạn phải tuân theo một số sơ đồ lớp đã có từ trước, thì bạn có thể làm việc cho NASA hoặc bạn đang tự bắn vào chân mình.

Sau đó, chúng là tài liệu không cần thiết. Nếu bạn không thể hiểu được các lớp đang làm gì hoặc chúng có liên quan với nhau như thế nào với một chút kiểm tra mã, thì bạn có một lỗ hổng trong bộ kỹ năng của mình với tư cách là nhà phát triển phần mềm.

Tất nhiên, câu trả lời này nghe có vẻ thực sự kiêu ngạo và quan điểm; ồ

Với Eiffel và các công cụ liên quan, đây chỉ là một điểm khác biệt của quan điểm, tất cả đều trỏ đến cùng các tệp bên dưới.