Một lập trình viên nên phát triển sự hiểu biết của mình về Quy trình hợp nhất và UML như thế nào? [đóng cửa]

Tôi biết rất nhiều nơi sử dụng UML và quy trình hợp nhất làm mô hình phát triển của họ ... nhưng sau đó có rất nhiều nơi không. Điều quan trọng là có nhiều kiến ​​thức cơ bản và chức năng về các chủ đề này hay tốt hơn là tập trung vào phát triển các kỹ năng lập trình trong các lĩnh vực khác (ví dụ như phát triển ngôn ngữ, IDE, v.v.)?

Trừ khi bạn nghĩ rằng sơn khô trong khi nước thải ngập cổ là một thời gian vui vẻ, hãy bỏ qua Quy trình hợp nhất. Đợi, bỏ qua nó là không đủ. Sợ nó Theo như tôi biết, ngày nay nó chỉ được sử dụng bởi những nơi rộng lớn vượt quá mọi hy vọng về hiệu quả, chất lượng hoặc sự tỉnh táo.

Mặt khác, UML có thể là một ký hiệu hữu ích cho các khái niệm lập trình quan trọng. Nhận UML chưng cất UML của Martin Fowler , đọc lướt qua và thực hành phác thảo sơ đồ trong khi suy nghĩ về thiết kế. Đó là một kỹ năng tôi sử dụng thường xuyên và tôi rất vui vì tôi có nó.

Xin lưu ý rằng mọi người cố gắng sử dụng quá mức UML. Bảng trắng UML trong khi thảo luận về mọi thứ là tuyệt vời. Một sơ đồ thỉnh thoảng trong tài liệu được xuất bản có thể là tốt đẹp. Nhưng nhiệm vụ ghi lại toàn bộ cơ sở mã của bạn trong UML là vô nghĩa và lãng phí. Và mong muốn "lập trình trong UML" là ngu ngốc. Nếu bạn gặp những người như vậy, hãy chạy trốn. Nhưng trước tiên, hãy gắn thương hiệu trán của họ bằng một sơ đồ trình tự, vì vậy phần còn lại của chúng tôi được cảnh báo chính xác.

Đừng dành quá nhiều thời gian cho UML. Trong nhóm của tôi, tôi là người duy nhất biết UML thực sự tốt và do đó tạo ra trường hợp sử dụng, thành phần, trạng thái, triển khai và các sơ đồ khác. Các thành viên khác trong nhóm tốt hơn tôi về mã hóa nhưng không tốt cho sơ đồ UML.

Thủ thuật chúng tôi sử dụng là tập trung vào sơ đồ lớp ở mức mô hình hóa để xác định cấu trúc của ứng dụng và cũng để cho nhà phát triển / kiến ​​trúc sư viết mã theo ý muốn. Sau đó chúng tôi hợp nhất mô hình với mã mới và cập nhật mô hình ở mỗi lần lặp. Thực sự dễ dàng và rất hiệu quả. Chúng tôi phát triển bằng Java với Omondo EclipseUML.

Tôi khuyên bạn không nên sử dụng bất kỳ MDD nào dành cho tôi một thứ nhảm nhí thực sự !! Nhà tạo mô hình sẽ cố gắng lấy thêm năng lượng trong quá trình phát triển nhưng điều này sẽ không tạo ra bất kỳ giá trị nào nếu họ cố gắng tạo tất cả mã từ mô hình. Mã thuộc về nhà phát triển / kiến ​​trúc sư nhưng không thuộc về người lập mô hình. UML chỉ nên là một khung nhìn của các yêu cầu dự án (ví dụ: usecase, chuỗi, v.v ....) quá trình (ví dụ: sơ đồ trạng thái hoặc kích hoạt), triển khai (triển khai, sơ đồ thành phần). Sơ đồ lớp nên một khung nhìn của mã và sơ đồ lớp UML chỉ nên được sử dụng như một trình xem mã. Mã hóa Java nên tôn trọng cách tiếp cận đối tượng và UML, cũng là một ngôn ngữ đối tượng thực sự hữu ích để tránh việc mã hóa ngu ngốc và ngu ngốc.

Điều quan trọng nhất là các lần lặp sơ đồ lớp giữa mô hình thành mã và mã để mô hình. Tôi thực sự không có nghĩa là đồng bộ hóa trực tiếp, nhưng để có thể hợp nhất mã và mô hình ở mỗi lần lặp. Tôi sử dụng Omondo EclipseUML và nghĩ rằng họ là người duy nhất hợp nhất java, các thực thể cơ sở dữ liệu và ID mô hình. Hợp nhất ID thực sự là một khái niệm mạnh mẽ và hoàn hảo cho các dự án nhanh của chúng tôi.

Đề nghị của tôi là không mua bất kỳ cuốn sách. Bạn nên có một cách tiếp cận đối tượng và sử dụng ngôn ngữ sơ đồ lớp để trực quan hóa các đối tượng của bạn để tạo ra kiến ​​trúc tốt hơn. Nếu một thành viên trong nhóm biết UML thì hãy sử dụng các sơ đồ khác, nếu không sơ đồ lớp sẽ là đủ.

Quy trình hợp nhất và UML là một tập hợp các công cụ truyền thông và tư duy có cấu trúc. Những công cụ này giúp theo một số cách; cả hai bằng cách xác định một cách nói về thiết kế, và bằng cách giúp chúng tôi làm việc thông qua các chi tiết và khía cạnh của thiết kế của chúng tôi.

Cải thiện suy nghĩ của riêng bạn là rất quan trọng để hoàn thành các chi tiết của một thiết kế và để tìm đường dẫn đến một sản phẩm lành mạnh và mạch lạc. Kỷ luật cá nhân giúp bạn tập trung, theo dõi chi tiết, suy nghĩ thấu đáo và ghi nhớ suy nghĩ của bạn là những tháng sau đó.

Cải thiện cách thiết kế được nói đến và cải thiện là rất quan trọng để giúp một nhóm các nhà thiết kế tiến xa hơn, nhanh hơn. Kỷ luật nhóm giúp nhận được nhiều hơn từ nhóm.

Nhưng hãy nhớ rằng UML và Quy trình hợp nhất chỉ là một trong nhiều công cụ tư duy. Chúng hợp lý, nhưng chúng có thể phù hợp hoặc không phù hợp với bạn hoặc nhóm của bạn (điều này cũng quan trọng như bất kỳ yếu tố nào khác).

Trong tâm trí tôi bây giờ có cách xung quanh UML. Lấy một cuốn sách và tìm hiểu nó. Bạn cần nó để:

• đọc sách kỹ thuật sử dụng UML (có rất nhiều)
• sử dụng nó như một công cụ phác thảo để thảo luận về các giải pháp / ý tưởng với các trường đại học.
• cung cấp cho mình một cách nhanh chóng để hình dung giải pháp bạn đang nghĩ và lý do về nó.
• đọc / lý do về thiết kế kỹ thuật / chức năng tại một số công ty

Quá trình thống nhất tôi nghĩ là một câu chuyện khác nhau, nó phụ thuộc vào nhà tuyển dụng bạn đang ở. Tôi sẽ đọc một cuốn sách ít nhất để biết nó là gì và khi đến lúc bạn thực sự cần nó nghiên cứu nó.

Hi vọng điêu nay co ich.

Tôi không nghĩ rằng bạn cần một kiến ​​thức cực kỳ chuyên sâu về UML nhưng bạn chắc chắn có thể nhìn vào sơ đồ và có thể biết chuyện gì đang xảy ra. Những gì bạn NÊN cố gắng để có được kiến ​​thức chuyên sâu là các mẫu thiết kế khác nhau (mua một cuốn sách). Khi bạn đưa ra các thiết kế của riêng mình, nó sẽ giúp bạn biết cả mẫu thiết kế và mẫu UML ngay cả khi bạn không thực sự vẽ nó ra. Nó cũng giúp bạn hiểu sơ đồ UML khi bạn nhìn thấy nó, bởi vì bạn có thể hiểu rõ hơn một chút tại sao UML trông như thế.

Tôi đã ở trong biz này từ năm 1987 và lần duy nhất tôi đã xử lý UML và Quy trình hợp nhất là một vài lần khi một nhà tư vấn sai lầm đã trả một số tiền rất lớn để buộc nhân viên phải ăn tất cả những chi tiết vụn vặt quá mức, và phương pháp bảo tồn. Sau mỗi nỗ lực để áp dụng crap không bị biến đổi này, cuối cùng chúng tôi đã tạo ra đủ tài liệu lỗi thời gần như ngay lập tức để lấp đầy Thư viện Quốc hội để tràn ra ngoài, đồng thời làm chậm thiết kế và phát triển các dự án của chúng tôi một cách vô ý thức.

Nếu sản phẩm kinh doanh của bạn được đo bằng pound giấy và / hoặc kích thước của tài liệu, sẽ không bao giờ được đọc nhiều hơn một lần (nếu nhiều), và sẽ mãi mãi bị lỗi thời, và đó sẽ là cơ sở để bạn được trả tiền, sau đó bằng mọi cách, đi toàn bộ con lợn với crap này.

Nếu không, hãy chạy la hét cho những ngọn đồi khi lần đầu tiên đề cập đến UML và UP. Hoặc tốt hơn, đánh bại người đầu tiên thốt ra nó thành bột giấy.

Bạn có thể đề cập rằng bạn có thể sử dụng UML MÀ KHÔNG CÓ Quy trình hợp nhất. Tôi sử dụng rất nhiều UML cùng một lúc so với lập trình, nhưng, đối với tôi, điều quan trọng là theo cách thực tế, không chỉ sử dụng nó vì "đó là một công cụ mới sáng chói".

Sơ đồ lớp, trường hợp sử dụng và sơ đồ tuần tự là yêu thích của tôi. Tôi không yêu cầu sử dụng các loại sơ đồ khác thường xuyên, như những sơ đồ này.

Nhiều công ty không sử dụng Quy trình hợp nhất / hợp lý.