Làm thế nào để bạn lập kế hoạch kiến ​​trúc của một ứng dụng trước khi viết bất kỳ mã nào? [đóng cửa]

Một điều tôi gặp khó khăn là lập kế hoạch kiến ​​trúc của ứng dụng trước khi viết bất kỳ mã nào.

Ý tôi không phải là thu thập các yêu cầu để thu hẹp những gì ứng dụng cần làm, mà là suy nghĩ hiệu quả về cách tốt để bố trí cấu trúc lớp, dữ liệu và luồng tổng thể và lặp lại những suy nghĩ đó để tôi có một kế hoạch đáng tin cậy hành động trong tâm trí trước khi mở IDE. Hiện tại, tất cả đều trở nên dễ dàng chỉ cần mở IDE, tạo một dự án trống, bắt đầu viết các bit và bob và để thiết kế 'phát triển' từ đó.

Tôi thu thập UML là một cách để làm điều này nhưng tôi không có kinh nghiệm về nó nên nó có vẻ hơi viển vông.

Làm thế nào để bạn lập kế hoạch kiến ​​trúc của một ứng dụng trước khi viết bất kỳ mã nào? Nếu UML là cách tốt nhất, bạn có thể giới thiệu một cách ngắn gọn và thiết thực cho một nhà phát triển các ứng dụng nhỏ không?

Tôi đánh giá cao đầu vào của bạn.

Tôi thực sự thấy rằng lần đầu tiên viết trên giấy hoặc bảng trắng thực sự rất quan trọng. Sau đó, chuyển sang UML nếu bạn muốn, nhưng không có gì đánh bại được sự linh hoạt của việc chỉ vẽ nó bằng tay lúc đầu.

Tôi xem xét những điều sau:

1. những gì hệ thống phải làm, đó là, vấn đề mà hệ thống đang cố gắng giải quyết là gì
2. khách hàng là ai và mong muốn của họ là gì
3. những gì hệ thống phải tích hợp với
4. có bất kỳ khía cạnh kế thừa nào cần được xem xét không
5. người dùng can thiệp là gì
6. Vân vân...

Sau đó, tôi bắt đầu xem hệ thống như một hộp đen và:

1. những tương tác cần xảy ra với hộp đen đó là gì
2. những hành vi nào cần xảy ra bên trong hộp đen, tức là những gì cần xảy ra với những tương tác đó để hộp đen thể hiện hành vi mong muốn ở cấp độ cao hơn, ví dụ: nhận và xử lý tin nhắn đến từ hệ thống đặt chỗ, cập nhật cơ sở dữ liệu, v.v. .

Sau đó, điều này sẽ bắt đầu cung cấp cho bạn một cái nhìn về hệ thống bao gồm các hộp đen bên trong khác nhau, mỗi hộp có thể được chia nhỏ hơn nữa theo cách tương tự.

UML rất tốt để thể hiện hành vi như vậy. Bạn có thể mô tả hầu hết các hệ thống chỉ sử dụng hai trong số nhiều thành phần của UML, đó là:

• sơ đồ lớp và
• sơ đồ trình tự.

Bạn cũng có thể cần sơ đồ hoạt động nếu có bất kỳ sự song song nào trong hành vi cần được mô tả.

Một tài nguyên tốt để học UML là cuốn sách tuyệt vời của Martin Fowler "UML Distilled" ( liên kết Amazon - được khử trùng cho liên kết kiddie tập lệnh có sẵn (-:). Cuốn sách này cung cấp cho bạn cái nhìn nhanh về các phần thiết yếu của từng thành phần của UML.

Oh. Những gì tôi đã mô tả là khá nhiều cách tiếp cận của Ivar Jacobson. Jacobson là một trong Three Amigos của OO. Trên thực tế, UML ban đầu được phát triển bởi hai người khác tạo thành Three Amigos, Grady Booch và Jim Rumbaugh

Bạn chắc chắn nên xem qua Mã hoàn chỉnh của Steve McConnell- và đặc biệt là tại chương tặng phẩm của anh ấy về "Thiết kế trong xây dựng"

Bạn có thể tải xuống từ trang web của anh ấy:

http://cc2e.com/File.ashx?cid=336

Nếu bạn đang phát triển cho .NET, Microsoft vừa xuất bản (dưới dạng sách điện tử miễn phí!) Hướng dẫn Kiến trúc Ứng dụng 2.0b1 . Nó cung cấp vô số thông tin thực sự tốt về việc lập kế hoạch kiến ​​trúc của bạn trước khi viết bất kỳ mã nào.

Nếu bạn tuyệt vọng, tôi hy vọng bạn có thể sử dụng phần lớn nó cho các kiến ​​trúc không dựa trên .NET.

Tôi sẽ mở đầu điều này bằng cách nói rằng tôi chủ yếu làm công việc phát triển web trong đó phần lớn kiến ​​trúc đã được quyết định trước (WebForms, bây giờ là MVC) và hầu hết các dự án của tôi là những nỗ lực hợp lý nhỏ, chỉ mất chưa đến một năm. Tôi cũng biết rằng tôi sẽ có ORM và DAL để xử lý tương tác dữ liệu và đối tượng kinh doanh của mình. Gần đây, tôi đã chuyển sang sử dụng LINQ cho việc này, rất nhiều "thiết kế" trở thành thiết kế cơ sở dữ liệu và ánh xạ thông qua trình thiết kế DBML.

Thông thường, tôi làm việc theo cách TDD (phát triển theo hướng thử nghiệm). Tôi không dành nhiều thời gian để nghiên cứu các chi tiết kiến ​​trúc hoặc thiết kế. Tôi thu thập tương tác tổng thể của người dùng với ứng dụng thông qua các câu chuyện. Tôi sử dụng các câu chuyện để thiết kế tương tác và khám phá các thành phần chính của ứng dụng. Tôi thực hiện rất nhiều bảng trắng trong quá trình này với khách hàng - đôi khi chụp các chi tiết bằng máy ảnh kỹ thuật số nếu chúng có vẻ đủ quan trọng để giữ ở dạng sơ đồ. Chủ yếu các câu chuyện của tôi được ghi lại dưới dạng câu chuyện trong wiki. Cuối cùng, các câu chuyện được sắp xếp thành các bản phát hành và lặp lại.

Lúc này, tôi thường có một ý tưởng khá tốt về kiến ​​trúc. Nếu nó phức tạp hoặc có những điểm bất thường - những thứ khác với cách làm bình thường của tôi - hoặc tôi đang làm việc với một người khác (không phải là điển hình), tôi sẽ lập sơ đồ mọi thứ (lại trên bảng trắng). Điều này cũng đúng với các tương tác phức tạp - tôi có thể thiết kế bố cục trang và dòng trên bảng trắng, giữ nó (hoặc chụp qua máy ảnh) cho đến khi tôi hoàn thành phần đó. Khi tôi đã có ý tưởng chung về nơi mình sẽ đến và những việc cần phải làm trước tiên, tôi sẽ bắt đầu viết thử nghiệm cho những câu chuyện đầu tiên. Thông thường, câu này giống như: "Được rồi, để làm được điều đó, tôi sẽ cần những lớp này. Tôi sẽ bắt đầu với lớp này và nó cần phải làm điều này." Sau đó, tôi bắt đầu vui vẻ TDDing cùng và kiến ​​trúc / thiết kế phát triển từ nhu cầu của ứng dụng.

Theo định kỳ, tôi sẽ thấy mình muốn viết lại một số đoạn mã hoặc nghĩ rằng "cái này thực sự có mùi" và tôi sẽ cấu trúc lại thiết kế của mình để loại bỏ sự trùng lặp hoặc thay thế các bit có mùi bằng thứ gì đó thanh lịch hơn. Hầu hết, tôi lo lắng về việc giảm chức năng trong khi tuân theo các nguyên tắc thiết kế tốt. Tôi thấy rằng việc sử dụng các mẫu đã biết và chú ý đến các nguyên tắc tốt khi bạn thực hiện sẽ mang lại hiệu quả khá tốt.

http://dn.codegear.com/article/31863

Tôi sử dụng UML và thấy hướng dẫn đó khá hữu ích và dễ đọc. Hãy cho tôi biết nếu bạn cần điều gì đó khác biệt.

UML là một ký hiệu. Đó là một cách ghi lại thiết kế của bạn, nhưng không phải (theo ý kiến ​​của tôi) để thực hiện một thiết kế. Tuy nhiên, nếu bạn cần viết ra giấy, tôi khuyên bạn nên sử dụng UML, không phải vì nó là "tốt nhất" mà bởi vì nó là một tiêu chuẩn mà những người khác có thể đã biết cách đọc, và nó đánh bại việc phát minh ra "tiêu chuẩn" của riêng bạn.

Tôi nghĩ phần giới thiệu tốt nhất về UML vẫn là UML Distilled , bởi Martin Fowler, bởi vì nó ngắn gọn, đưa ra hướng dẫn thực tế về nơi sử dụng nó và nói rõ rằng bạn không cần phải mua toàn bộ câu chuyện UML / RUP để sử dụng nó. hữu ích

Làm thiết kế rất khó, không thể nắm bắt được hết trong một câu trả lời của StackOverflow. Thật không may, các kỹ năng thiết kế của tôi, chẳng hạn như chúng, đã phát triển qua nhiều năm và vì vậy tôi không có một nguồn nào để có thể giới thiệu cho bạn.

Tuy nhiên, một mô hình mà tôi thấy hữu ích là phân tích độ mạnh (google cho nó, nhưng có phần giới thiệu ở đây ). Nếu bạn có các trường hợp sử dụng của mình cho những gì hệ thống phải làm, một mô hình miền về những thứ liên quan, thì tôi nhận thấy phân tích độ mạnh mẽ là một công cụ hữu ích trong việc kết nối cả hai và tìm ra những thành phần chính của hệ thống cần. .

Nhưng lời khuyên tốt nhất là đọc nhiều, suy nghĩ kỹ và thực hành. Đó không phải là một kỹ năng thuần túy có thể dạy được, bạn phải thực sự làm được.

Tôi không đủ thông minh để lập kế hoạch trước nhiều hơn một chút. Khi tôi lập kế hoạch trước, kế hoạch của tôi luôn bị sai, nhưng bây giờ tôi đã dành n ngày cho những kế hoạch tồi. Giới hạn của tôi dường như là khoảng 15 phút trên bảng trắng.

Về cơ bản, tôi làm ít công việc nhất có thể để tìm hiểu xem liệu tôi có đang đi đúng hướng hay không.

Tôi xem xét thiết kế của mình cho những câu hỏi quan trọng: khi A chuyển B đến C, liệu nó có đủ nhanh cho D không? Nếu không, chúng ta cần một thiết kế khác. Mỗi câu hỏi này có thể được trả lời với một mức tăng đột biến. Nếu phần gai trông đẹp, thì chúng tôi đã có thiết kế và đã đến lúc mở rộng nó.

Tôi viết mã theo hướng nhận được một số giá trị thực của khách hàng càng sớm càng tốt để khách hàng có thể cho tôi biết tôi nên đi đâu.

Bởi vì tôi luôn làm sai mọi thứ, tôi dựa vào cấu trúc lại để giúp tôi làm đúng. Tái cấu trúc là rủi ro, vì vậy tôi phải viết các bài kiểm tra đơn vị khi tôi tiếp tục. Việc viết bài kiểm tra đơn vị sau khi thực tế là khó vì khớp nối, vì vậy tôi viết bài kiểm tra của mình trước. Giữ kỷ luật về những thứ này là khó, và một bộ não khác nhìn nhận mọi thứ khác nhau, vì vậy tôi thích có một người bạn cùng viết mã với mình. Người bạn mã của tôi có mũi, vì vậy tôi thường xuyên tắm rửa.

Hãy gọi nó là "Lập trình cực đoan".

"Bảng trắng, bản phác thảo và ghi chú Post-it là những công cụ thiết kế tuyệt vời. Các công cụ tạo mô hình phức tạp có xu hướng gây mất tập trung hơn là chiếu sáng." Từ Thực tiễn của một nhà phát triển nhanh nhẹn của Venkat Subramaniam và Andy Hunt .

Tôi không tin bất cứ điều gì có thểđược lên kế hoạch trước khi thực hiện. Tôi đã có 10 năm kinh nghiệm, nhưng đó chỉ là ở 4 công ty (bao gồm cả 2 địa điểm tại một công ty, gần như đối lập nhau) và hầu như tất cả kinh nghiệm của tôi là về việc xem các cụm khổng lồ ****** ** s xảy ra. Tôi bắt đầu nghĩ rằng những thứ như tái cấu trúc thực sự là cách tốt nhất để làm mọi thứ, nhưng đồng thời tôi nhận ra rằng kinh nghiệm của mình còn hạn chế và có thể tôi chỉ đang phản ứng với những gì tôi đã thấy. Điều tôi thực sự muốn biết là làm thế nào để có được trải nghiệm tốt nhất để tôi có thể đưa ra kết luận chính xác, nhưng có vẻ như không có đường tắt và nó chỉ liên quan đến việc mất nhiều thời gian khi thấy mọi người làm sai :(. 'thực sự muốn thử làm việc tại một công ty nơi mọi người làm đúng (bằng chứng là triển khai sản phẩm thành công),

Tôi xin phép có sự khác biệt: UML có thể được sử dụng cho kiến ​​trúc ứng dụng, nhưng thường được sử dụng cho kiến ​​trúc kỹ thuật (khung, biểu đồ lớp hoặc trình tự, ...), bởi vì đây là nơi những sơ đồ đó có thể dễ dàng được giữ đồng bộ với sự phát triển .

Kiến trúc ứng dụng xảy ra khi bạn sử dụng một số đặc tả chức năng (mô tả bản chất và các luồng hoạt động mà không đưa ra bất kỳ giả định nào về việc triển khai trong tương lai) và bạn chuyển đổi chúng thành đặc điểm kỹ thuật.

Các thông số kỹ thuật đó đại diện cho các ứng dụng bạn cần để thực hiện một số nhu cầu kinh doanh và chức năng.

Vì vậy, nếu bạn cần xử lý một số danh mục tài chính lớn (đặc điểm kỹ thuật chức năng), bạn có thể xác định rằng bạn cần chia đặc điểm kỹ thuật lớn đó thành:

• một người điều phối để chỉ định những tính toán nặng nề đó cho các máy chủ khác nhau
• một trình khởi chạy để đảm bảo tất cả các máy chủ tính toán được thiết lập và chạy trước khi bắt đầu xử lý các danh mục đầu tư đó.
• GUI để có thể hiển thị những gì đang diễn ra.
• một thành phần "chung" để phát triển các thuật toán danh mục đầu tư cụ thể, độc lập với phần còn lại của kiến ​​trúc ứng dụng, để tạo điều kiện cho kiểm thử đơn vị, nhưng cũng có một số kiểm tra chức năng và hồi quy.

Vì vậy, về cơ bản, suy nghĩ về kiến trúc ứng dụng là quyết định "nhóm tệp" nào bạn cần phát triển theo một cách thống nhất (bạn không thể phát triển trong cùng một nhóm tệp như launcher, GUI, dispatcher, ...: chúng sẽ không thể phát triển với tốc độ tương tự)

Khi một kiến ​​trúc ứng dụng được xác định rõ, mỗi thành phần của nó thường là một ứng cử viên sáng giá cho một thành phần cấu hình , đó là một nhóm tệp có thể được phiên bản hóa thành một VCS (Hệ thống kiểm soát phiên bản), có nghĩa là tất cả các tệp của nó sẽ được gắn nhãn cùng nhau mỗi khi bạn cần ghi lại ảnh chụp nhanh của ứng dụng đó (một lần nữa, sẽ rất khó để gắn nhãn cho tất cả hệ thống của bạn, mỗi ứng dụng của nó không thể ở trạng thái ổn định cùng một lúc)

Tôi đã làm kiến ​​trúc được một thời gian. Trước tiên, tôi sử dụng BPML để tinh chỉnh quy trình kinh doanh và sau đó sử dụng UML để nắm bắt các chi tiết khác nhau! Bước thứ ba nói chung là ERD! Vào thời điểm bạn hoàn thành với BPML và UML, ERD của bạn sẽ khá ổn định! Không có kế hoạch nào là hoàn hảo và không có kế hoạch nào là hoàn hảo 100%. Lập kế hoạch tái cấu trúc, mục tiêu là giảm thiểu tái cấu trúc càng nhiều càng tốt!

Tôi cố gắng chia nhỏ suy nghĩ của mình thành hai lĩnh vực: đại diện cho những thứ tôi đang cố gắng thao túng và những gì tôi định làm với chúng.

Khi tôi đang cố gắng tạo mô hình cho thứ mà tôi đang cố gắng thao tác, tôi nghĩ ra một loạt các định nghĩa về mặt hàng rời rạc - một trang web thương mại điện tử sẽ có SKU, sản phẩm, khách hàng, v.v. Tôi cũng sẽ có một số thứ phi vật chất mà tôi đang làm việc - một đơn đặt hàng hoặc một danh mục. Khi tôi có tất cả các "danh từ" trong hệ thống, tôi sẽ tạo một mô hình miền cho thấy các đối tượng này có liên quan với nhau như thế nào - một đơn đặt hàng có một khách hàng và nhiều SKU, nhiều skus được nhóm lại thành một sản phẩm, v.v. trên.

Các mô hình miền này có thể được biểu diễn dưới dạng mô hình miền UML, sơ đồ lớp và SQL ERD.

Khi tôi đã tìm ra các danh từ của hệ thống, tôi chuyển sang các động từ - ví dụ, các hoạt động mà mỗi mục này trải qua để thực hiện một thứ tự. Những thứ này thường ánh xạ khá tốt để sử dụng các trường hợp từ các yêu cầu chức năng của tôi - cách dễ nhất để diễn đạt những điều này mà tôi đã tìm thấy là trình tự UML, hoạt động hoặc sơ đồ cộng tác hoặc sơ đồ bơi.

Điều quan trọng là phải coi đây là một quá trình lặp đi lặp lại; Tôi sẽ thực hiện một số góc nhỏ của miền, sau đó thực hiện các thao tác và sau đó quay lại. Lý tưởng nhất là tôi sẽ có thời gian viết mã để thử mọi thứ khi tôi đang làm - bạn không bao giờ muốn thiết kế vượt quá xa so với ứng dụng. Quá trình này thường rất tồi tệ nếu bạn nghĩ rằng bạn đang xây dựng kiến ​​trúc hoàn chỉnh và cuối cùng cho mọi thứ; thực sự, tất cả những gì bạn đang cố gắng làm là thiết lập nền tảng cơ bản mà nhóm sẽ chia sẻ chung khi họ phát triển qua quá trình phát triển. Bạn chủ yếu tạo ra một từ vựng được chia sẻ để các thành viên trong nhóm sử dụng khi họ mô tả hệ thống, chứ không phải đặt ra luật về cách nó phải được thực hiện.

Tôi thấy mình gặp khó khăn khi nghĩ ra một hệ thống trước khi mã hóa nó. Thật quá dễ dàng để chỉ lướt qua một số thành phần mà sau này bạn mới nhận ra là phức tạp hơn nhiều so với bạn tưởng.

Một giải pháp là chỉ cần cố gắng thực sự chăm chỉ. Viết UML ở mọi nơi. Đi qua mọi lớp. Hãy nghĩ cách nó sẽ tương tác với các lớp khác của bạn. Điều này rất khó thực hiện.

Những gì tôi thích làm là làm cho một cái nhìn tổng quát ban đầu. Tôi không thích UML, nhưng tôi thích vẽ các sơ đồ để giải quyết vấn đề. Sau đó, tôi bắt đầu thực hiện nó. Ngay cả khi tôi chỉ viết ra cấu trúc lớp với các phương thức trống, tôi thường thấy những thứ mà tôi đã bỏ lỡ trước đó, vì vậy sau đó tôi cập nhật thiết kế của mình. Khi đang viết mã, tôi sẽ nhận ra mình cần phải làm điều gì đó khác đi, vì vậy tôi sẽ cập nhật thiết kế của mình. Đó là một quá trình lặp đi lặp lại . Khái niệm "thiết kế mọi thứ trước, và sau đó thực hiện tất cả" được gọi là mô hình thác nước, và tôi nghĩ những người khác đã cho thấy đó là một cách làm phần mềm tồi.

Hãy thử Archimate.