Tại sao chúng ta không thể nắm bắt thiết kế phần mềm hiệu quả hơn? [đóng cửa]


14

Là kỹ sư, tất cả chúng ta đều "thiết kế" các đồ tạo tác (tòa nhà, chương trình, mạch điện, phân tử ...). Đó là một hoạt động (design-the-verb) tạo ra một loại kết quả (design-the-noun).

Tôi nghĩ rằng tất cả chúng ta đều đồng ý rằng thiết kế-danh từ là một thực thể khác với chính tạo tác.

Một hoạt động chính trong kinh doanh phần mềm (thực sự, trong bất kỳ doanh nghiệp nào mà sản phẩm tạo ra sản phẩm kết quả cần phải được nâng cao) là để hiểu "thiết kế (danh từ)". Tuy nhiên, dường như chúng ta, với tư cách là một cộng đồng, đã thất bại khá nhiều trong việc ghi lại nó, bằng chứng là số lượng nỗ lực mà mọi người bỏ ra để khám phá lại sự thật về cơ sở mã của họ. Yêu cầu ai đó chỉ cho bạn thiết kế mã của họ và xem những gì bạn nhận được.

Tôi nghĩ về một thiết kế cho phần mềm là có:

  • Một đặc điểm kỹ thuật rõ ràng cho những gì phần mềm được cho là phải làm và nó hoạt động tốt như thế nào
  • Một phiên bản rõ ràng của mã (phần này rất dễ, mọi người đều có nó)
  • Một lời giải thích về cách mỗi phần của mã phục vụ để đạt được đặc tả (ví dụ: mối quan hệ giữa các đoạn đặc tả và đoạn mã)
  • Một lý do là tại sao mã là như vậy (ví dụ, tại sao một lựa chọn cụ thể chứ không phải là một lựa chọn khác)

Những gì KHÔNG phải là một thiết kế là một quan điểm cụ thể về mã. Ví dụ [không chọn cụ thể trên] sơ đồ UML không phải là thiết kế. Thay vào đó, chúng là các thuộc tính bạn có thể lấy từ mã, hoặc có thể nói là các thuộc tính bạn muốn bạn có thể lấy từ mã. Nhưng theo nguyên tắc chung, bạn không thể lấy được mã từ UML.

Tại sao sau hơn 50 năm xây dựng phần mềm, tại sao chúng ta không có cách thường xuyên để thể hiện điều này? (Vui lòng mâu thuẫn với tôi bằng các ví dụ rõ ràng!)

Ngay cả khi chúng tôi làm, hầu hết cộng đồng dường như rất tập trung vào việc lấy "mã" mà thiết kế danh từ bị mất đi. (IMHO, cho đến khi thiết kế trở thành mục đích của kỹ thuật, với tạo tác được trích ra từ thiết kế, chúng ta sẽ không giải quyết vấn đề này).

Những gì bạn đã xem là phương tiện để ghi lại các thiết kế (theo nghĩa tôi đã mô tả nó)? Tài liệu tham khảo rõ ràng để giấy tờ sẽ được tốt. Tại sao bạn nghĩ rằng cụ thể và chung có nghĩa là không thành công? Làm thế nào chúng ta có thể thay đổi được điều này?

[Tôi có ý tưởng riêng của mình đưa ra quan điểm gạch đầu dòng ở trên, nhưng tôi quan tâm đến câu trả lời của người khác ... và thật khó để thực hiện kế hoạch của tôi [[và có lẽ đó là vấn đề thực sự: -]]]

EDIT 2011/1/3: Một trong những chủ đề trả lời gợi ý rằng "tài liệu" (có lẽ là văn bản, đặc biệt là không chính thức) có thể là đầy đủ. Tôi đoán tôi nên làm rõ rằng tôi không tin điều này. Các công cụ CASE xuất hiện trên bối cảnh bắt đầu từ những năm 80, nhưng các công cụ ban đầu hầu như chỉ thu được các pixel cho sơ đồ của bất cứ thứ gì bạn vẽ; trong khi các công cụ được cho là thành công về mặt thương mại, chúng thực sự không hữu ích lắm. Một cái nhìn sâu sắc quan trọng là, nếu các tạo tác "thiết kế" bổ sung không thể giải thích chính thức, bạn không thể nhận được bất kỳ trợ giúp công cụ nghiêm túc nào. Tôi tin rằng cái nhìn sâu sắc tương tự áp dụng cho bất kỳ hình thức nắm bắt thiết kế hữu ích lâu dài nào: nếu nó không có cấu trúc chính thức, nó sẽ không được sử dụng thực sự. Tài liệu văn bản khá nhiều thất bại bài kiểm tra này.


1
Đồng ý với UML - một công cụ giao tiếp tốt nhất, góp phần vào mô tả thiết kế, nhưng bản thân nó không phải là thiết kế. Tuy nhiên, tệ nhất là UML là mã nguồn đồ họa.
Steve314

định lượng "nó hoạt động tốt như thế nào"
Steven A. Lowe

Khi tôi xây dựng các hệ thống, tôi đã đáp ứng rất nhiều yêu cầu "không chức năng": được mã hóa bằng ngôn ngữ này , sử dụng cơ sở dữ liệu đó , xử lý các bản ghi 1E10 với thời gian phản hồi trung bình 100mS, ... Bạn không thể loại bỏ các đặc điểm kỹ thuật này. (Không có các yêu cầu không chức năng, vòng lặp mãi mãi là một chương trình phù hợp cho bất kỳ thông số chức năng nào). Toàn bộ quan điểm của tôi về chụp "thiết kế" là xử lý một yêu cầu không chức năng khác: "duy trì".
Ira Baxter

Cuộc thảo luận của bạn có vẻ thú vị nhưng tôi vẫn không chắc câu hỏi chính xác là gì. Bạn có nghĩ rằng bạn có thể cố gắng đưa ra một cái gì đó như một ví dụ cụ thể hoặc một cái gì đó để làm rõ chính xác những gì bạn quan tâm. Tôi đang suy nghĩ về một cái gì đó giống như ví dụ FFT nơi bạn có thể đưa ra bức tranh đầy đủ về 4 gạch đầu dòng trong câu hỏi của bạn giống như bạn nhìn thấy chúng và có thể bạn muốn làm gì với kết quả sau khi chụp.
n1ckp

Tôi không biết gì về vấn đề này, nhưng đó là chủ đề của 'Thiết kế thiết kế' của Fred Brooks . (Xin lỗi nếu bạn đã quen thuộc.) Ông thảo luận về các ví dụ từ lập trình và kiến ​​trúc. Ông đặc biệt lưu ý rằng việc nắm bắt các lý do (cho cả thiết kế và các thiết kế thay thế bị từ chối) thực sự hữu ích và không được phục vụ tốt bởi các công cụ hiện tại.
Paul D. Chờ đợi

Câu trả lời:


8

Tôi nghĩ rằng có một số lý do tại sao chúng ta vẫn không giỏi trong việc này.

  1. Mọi người trong một thời gian dài mặc dù phần mềm giống như những ngôi nhà, và đang sử dụng các quy trình và ý tưởng từ xây dựng. "Kiến trúc sư phần mềm" là một tiêu đề mà tất cả các lập trình viên đều muốn. Trong mười năm qua, kiến ​​trúc sư phần mềm gần như đã chết. Ý tưởng về các quy trình thác nước mà trước tiên bạn có một kiến ​​trúc sư nói rằng phần mềm nên hoạt động và trông như thế nào, sau đó nhờ mọi người tạo sơ đồ về cách nó nên được xây dựng và cuối cùng có khỉ khỉ thực hiện các sơ đồ / công việc UML tuyệt vời này để mô tả, ý tưởng này là bây giờ bị chế giễu rộng rãi. Vì vậy, trên thực tế, toàn bộ ngành công nghiệp đã sủa sai đường trong 40 năm.

  2. Các công cụ chúng tôi sử dụng liên tục thay đổi và cải thiện. Lập trình là một câu đố logic, và chúng tôi đưa ra những ý tưởng và kỹ thuật tốt hơn để trừu tượng hóa câu đố đó và làm cho nó trở nên dễ hiểu. Cách chúng ta mô hình hóa điều này phải phát triển với cùng tốc độ, nhưng nó tụt lại phía sau. Các kỹ thuật cải tiến để trừu tượng hóa câu đố lập trình cũng có nghĩa là chúng ta có thể tăng độ phức tạp. Và vì vậy chúng tôi làm. Lập trình luôn nằm ở rìa của sự phức tạp mà chúng ta là lập trình viên có thể xử lý.

  3. Làm cho các cách mô tả chương trình là một loại trừu tượng. Nếu chúng ta có thể đưa ra một cách tốt để trừu tượng hóa phần mềm, chúng ta cũng có thể đưa sự trừu tượng hóa đó trực tiếp vào các công cụ phát triển, và do đó thêm một sự trừu tượng hóa / đơn giản hóa khác vào lập trình. Điều này đã xảy ra nhiều lần hơn. Ví dụ về sự trừu tượng như vậy là các hàm, lớp và thư viện.

  4. Vì thế; Nếu bạn có một mô hình thành côngchính xác của phần mềm, mô hình đó sẽ tương đương với phần mềm. Loại nào làm cho toàn bộ nỗ lực trở nên vô nghĩa, điều này lần lượt chứng thực điểm 1 ở trên: Mô hình hóa phần mềm ít hữu ích hơn nhiều so với suy nghĩ trước đây. Thay vào đó, tốt hơn là trích xuất dữ liệu về phần mềm từ mã. Việc tạo một mô hình UML từ cách mã thực sự trông sẽ sáng hơn nhiều so với việc tạo một mô hình UML và cố gắng thực hiện mô hình lý thuyết đó.


2
Đừng đồng ý với điểm cuối cùng của bạn. Đúng, nó sẽ tương đương với phần mềm, nhưng vẫn dễ dàng vẽ lại mô hình hơn là cấu trúc lại phần mềm thực tế khi (không phải) nếu bạn phát hiện ra một thứ gì đó không phải là một ý tưởng hay. Tôi sẽ không đánh giá thấp tầm quan trọng của bước thiết kế.
Joris Meys

1
@Joris Meys: Vấn đề là bạn sẽ không biết cái gì và cái gì không phải là ý tưởng hay cho đến khi bạn thực hiện nó. (Ngoại trừ trong các trường hợp tầm thường, nhưng sau đó bạn sẽ không sử dụng sơ đồ UML nhiều). Ngoài ra, bạn không nên đánh giá quá cao độ khó của mã tái cấu trúc. Tôi khuyên bạn nên đọc sách của Kent Becks trên XP và Test Driven Design.
Lennart Regebro

@Lennart: thx cho tiền boa
Joris Meys

2
@Lennart: Sự khác biệt giữa bạn và Công việc là dường như bạn đồng ý rằng một đặc tả được thể hiện bằng cách nào đó có thể là cần thiết, mặc dù tôi không biết bộ trừu tượng hiện có thể lập trình của bạn làm điều đó như thế nào. Nhưng hãy tưởng tượng rằng tôi cần một chương trình xử lý tín hiệu trích xuất các tần số chính. Thông báo tôi đã không đề nghị làm thế nào. Bạn có thể quyết định sử dụng Biến đổi Fourier nhanh và chắc chắn tôi sẽ tìm thấy dấu chân trên toàn bộ mã thực hiện các bit FFT. Nhưng đâu là thực tế mà bạn quyết định sử dụng FFT được ghi lại rõ ràng? Tôi tin rằng bạn cần nó trừ khi độc giả của bạn là tất cả hiểu biết.
Ira Baxter

1
@Ira Baxter: Làm thế nào về "Chúng tôi đã chọn thực hiện xử lý tín hiệu với FFT"? Mã nguồn có ý kiến, bạn biết. Và tôi cũng có thể viết nó trong một tệp README. Các biểu thức rõ ràng của đặc điểm kỹ thuật là mã. Các dòng văn bản như "Chúng tôi đã chọn triển khai nó với FFT" không rõ ràng, cũng không được thiết kế theo nghĩa của bài đăng gốc của bạn. Đó là tài liệu của việc thực hiện. Bạn dường như đã kết thúc trong một chế độ tranh luận, nhưng tôi không hiểu những gì bạn đang cố gắng tranh luận.
Lennart Regebro

5

Bạn có thể quan tâm đến việc xem xét tài liệu truy xuất nguồn gốc phần mềm. Không theo thứ tự đặc biệt:

  • CUBRANIC, D., MURPHY, GC, Singer, J., VÀ BOOTH KELLOGG, S. Hipikat: bộ nhớ dự án để phát triển phần mềm. Giao dịch về Kỹ thuật phần mềm 31, 6 (2005), 446 Điện65.
  • TANG, A., BABAR, MA, GORTON, I., VÀ HAN, J. Một khảo sát về việc sử dụng và tài liệu của lý do thiết kế kiến ​​trúc. Trong Proc của Hội nghị IEEE / IFIP hoạt động lần thứ 5 về Kiến trúc phần mềm (2005).
  • RAMESH, B., POWERS, T., STUBBS, C., VÀ EDWARDS, M. Thực hiện yêu cầu truy xuất nguồn gốc: Một nghiên cứu trường hợp. Trong Proc of the Int'l Symp on Request Engineering (York, 1995).
  • HORNER, J., VÀ ATWOOD, ME Thiết kế hợp lý: cơ sở lý luận và các rào cản. Trong Proc của Hội nghị Bắc Âu lần thứ 4 về Tương tác giữa người và máy tính: Thay đổi vai trò (Oslo, Na Uy, 2006).
  • CLELAND-HUANG, J., SETTIMI, R., ROMANOVA, E., BERENBACH, B., VÀ CLARK, S. Thực hành tốt nhất để truy xuất nguồn gốc tự động. Máy tính 40, 6 (tháng 6 năm 2007), 27 Hàng35.
  • ASUNCION, H., FRANÇOIS, F., VÀ TAYLOR, RN Một công cụ truy xuất nguồn gốc phần mềm công nghiệp đầu cuối. Trong Proc của Cuộc họp chung lần thứ 6 của Phần mềm Châu Âu Eng Conf và SymMl IntIGl của ACM SIGSOFT về các nền tảng của Kỹ thuật phần mềm (ESEC / FSE) (Dubrovnik, 2007).

Lưu ý rằng đây chỉ là phần nổi của tảng băng trôi và tôi chắc chắn rằng mình đã bỏ quên một số giấy tờ quan trọng.

Một lưu ý khác, công việc riêng của tôi về Arcum là phương tiện để các lập trình viên bày tỏ với IDE về việc sử dụng các thành ngữ thiết kế xuyên suốt. Sau khi được thể hiện, các lập trình viên sau đó có thể chuyển đổi mã nguồn của họ để sử dụng các triển khai thay thế:

Ngẫu nhiên, Arcum cũng liên quan đến công việc DMS của bạn.


1
+1 cho điều này. RT không phải là tất cả nhưng đó là một trong những bước tích cực để thực sự giải quyết vấn đề thay vì đưa ra những lý do cũ tương tự cho nó.
Aaronaught

2

UML là một chương trình mà các kế hoạch dành cho một tòa nhà theo quan điểm khiêm tốn của tôi. Một mình các kế hoạch không phải là một thiết kế ngoài khóa học, bạn cần các thông số kỹ thuật vật liệu (công cụ mã được sử dụng) cho điều đó, một cái nhìn chung về tòa nhà (một số biểu diễn sơ đồ của toàn bộ phần mềm, bao gồm cả thiết kế GUI), cách tòa nhà được trồng trong môi trường xung quanh (một sơ đồ rõ ràng về cách phần mềm tương tác với các phần mềm khác / được trồng trong HĐH), cách nó phù hợp với khí hậu và đất (tương tác với phần cứng), ... Rất nhiều sách về thiết kế cố gắng định nghĩa nó, nhưng cũng như vậy nhiều điều trong khoa học, mỗi nhà khoa học có một chút định nghĩa của riêng mình.

Bây giờ, tôi cũng không đồng ý với quan sát của bạn rằng bạn không thể lấy được mã từ UML. Bạn có thể, nếu bạn có thông tin bổ sung được đề cập. Nhưng mã thực sự không phải là thiết kế nữa, đó là tạo tác. Bạn cũng không thể trích xuất đá thật và bê tông từ một kế hoạch, nhưng bạn cần có kế hoạch đặt đá thật và bê tông ở dạng chính xác và đúng vị trí.

Trong ánh sáng đó, tôi thấy bài viết sau đây rất thú vị (tôi đã gặp nó trong một bối cảnh khác khi tôi đang tìm kiếm phần mềm đồ thị, nhưng dù sao ...). Cách tiếp cận đồ thị để mô tả một thiết kế có ý nghĩa với tôi, mặc dù - theo tôi - đây chỉ là một phần của thiết kế. Điều thú vị là cách tiếp cận này đưa ra một khung để hiểu và cấu trúc lại các thiết kế (trái ngược với cấu trúc lại phần mềm), như được chỉ ra trong các bài viết sau:

Có rất nhiều cách tiếp cận khác để mô tả (một phần) thiết kế, như thiết kế có cấu trúc (Biểu đồ HIPO) hoặc thiết kế chương trình tích hợp , các mẫu thiết kế , ...

Tuy nhiên, miễn là không có tiêu chuẩn ngành nào được đặt ra, không thể có được cách "thông thường" để thể hiện điều này. Ngay cả sau hơn 50 năm. Và thành thật mà nói, nếu công ty của bạn tìm thấy một cách tốt để thể hiện một thiết kế, bạn sẽ chia sẻ nó với thế giới chứ?


Nếu công ty của bạn tìm thấy một cách tốt để làm điều này, các lập trình viên sẽ nói với mọi người khác khá nhanh chóng. :-)
Lennart Regebro

Tôi nghĩ rằng bạn bỏ lỡ quan điểm của tôi về UML (và bất kỳ ký hiệu "đơn" nào khác). UML-before-code là một ràng buộc về cách bạn muốn xây dựng phần mềm. Tất cả các ký hiệu khác cũng vậy (vâng, tôi đã thấy rất nhiều trong số này, tôi đã ở đây một thời gian). Có một ràng buộc, có thể tạo ra cuộc họp mã đó ràng buộc (phương thức đùa: sản xuất tất cả các chương trình có thể và kiểm tra xem cái nào phù hợp với ràng buộc đó, chọn một trong những cái đó). Theo nghĩa này, bạn có thể "tạo mã từ UML". Nhưng (nếu chúng ta tuân theo sơ đồ lớp), mã đó sẽ không thực hiện chức năng bạn muốn ...
Ira Baxter

... Và hầu hết các chương trình công chứng khác cũng bị như vậy, họ không thực sự nắm bắt được một đặc điểm kỹ thuật về những gì chương trình phải làm. Họ cũng không cung cấp bất cứ điều gì như một lý do; Tại sao biểu đồ UML của bạn có hình dạng như vậy? Phần nào của mã tôi có thể thay đổi mà không phá vỡ biểu đồ? Tôi có thể thay đổi theo cách không làm hỏng ý định đằng sau biểu đồ không?
Ira Baxter

@Ira: Sau khi truy cập trang web của bạn, nó trở nên rõ ràng hơn với tôi. Nhưng tôi phải thừa nhận rằng một cuộc thảo luận ngữ nghĩa cấp cao về những vấn đề này nằm ngoài chuyên môn của tôi. Tuy nhiên, nếu bạn coi mã thực là một phần của thiết kế, thì tạo tác thực sự ở đâu? UML - hoặc bất kỳ ký hiệu nào khác - theo ý kiến ​​khiêm tốn của tôi là bản thiết kế của cấu trúc mã và đó là thứ tôi muốn gọi là một phần của thiết kế. Nhiều hơn mã thực tế trong thực tế. nhớ phần . Đó không phải là thiết kế, nhưng vẫn là một đóng góp thiết yếu cho nó. một lần nữa, theo ý kiến ​​khiêm tốn của tôi. Cơ sở lý luận, vv có thể được thêm vào đó như được giải thích.
Joris Meys

@Joris: Hầu hết các ký hiệu sơ đồ có thể được coi là các phép chiếu (các tạo phẩm được suy ra) từ mã (ít nhất là sau khi hoàn thành) hoặc có thể được coi là hướng dẫn để xây dựng mã (bản thiết kế). Có rất nhiều sơ đồ có thể (một số được liệt kê trong câu trả lời của bạn). Những cái nào là cơ bản cho mã bạn có, và đó chỉ là tai nạn? Sơ đồ là digrams, vì vậy họ nên đủ điều kiện; Tuy nhiên, tôi khá tự tin rằng sơ đồ của một số đoạn mã sẽ không được coi là một phần của thiết kế. Vậy, cơ bản là gì? Tình cờ là gì?
Ira Baxter

2

Từ kinh nghiệm cá nhân của riêng tôi, tôi sẽ lập luận rằng chúng tôi nắm bắt tốt việc thiết kế phần mềm. Chúng tôi có một cơ sở dữ liệu về các tài liệu yêu cầu và thiết kế cho mọi tính năng mà chúng tôi đã từng triển khai trên nền tảng của mình. Tôi cho rằng hoàn cảnh của tôi có thể là duy nhất. Dưới đây là một số điều để suy nghĩ về mặc dù.

Mỗi người trong nhóm của tôi đều có bằng kỹ sư ... chủ yếu là EE hoặc CE. Kỹ thuật dạy bạn thiết kế như một phần của chương trình giảng dạy.

Tôi nghĩ rằng có rất nhiều cái gọi là kỹ sư phần mềm đến từ nền tảng CS. Thiết kế phần mềm không phải là một phần không thể thiếu của hầu hết các chương trình CS. Tôi không nói rằng tất cả các chuyên ngành CS đều kém về thiết kế, nhưng tôi cá rằng hầu hết không có giáo dục chính thức nào dạy chúng. Tôi nghĩ rằng rất nhiều người cho rằng nếu bạn có thể lập trình rằng bạn có thể thiết kế phần mềm thì điều đó không đúng. Cho rằng nhiều lập trình viên không có nền tảng kỹ thuật, không có gì đáng ngạc nhiên khi nhiều dự án phần mềm không có một đội ngũ giỏi trong việc nắm bắt thiết kế.


Vậy bạn sử dụng phương pháp cụ thể nào để viết yêu cầu và tài liệu thiết kế? (Tôi đã xem tiểu sử của bạn và đang mong đợi được nhìn thấy ai đó từ không gian phòng thủ và rất ngạc nhiên). Tôi giả sử theo yêu cầu của bạn có nghĩa là một số văn bản ngôn ngữ tự nhiên? ... Nếu vậy, bạn không có tranh luận về họ? (Tôi phân biệt yêu cầu ngôn ngữ tự nhiên với thông số kỹ thuật chính thức). Họ đã hoàn thành chưa? Còn hồ sơ thiết kế? Họ có cập nhật hoàn toàn cho hệ thống vận chuyển hiện tại không? Tôi sẽ đồng ý rằng rất nhiều người được gọi là lập trình viên và kỹ sư phần mềm thì không, vì vậy chúng ta có thể thảo luận về những gì nên làm.
Ira Baxter

1
Tôi không chắc chắn rằng có một tên cụ thể cho phương pháp của chúng tôi. Yêu cầu của chúng tôi là những gì tôi sẽ gọi là lai giữa yêu cầu ngôn ngữ tự nhiên và tài liệu thiết kế cấp cao. Chúng tôi thường có hai vòng chỉnh sửa. Đầu tiên, chúng tôi ghi lại những gì một tính năng cần phải làm bằng tiếng Anh. Sau đó, chúng tôi xác định chính xác cách nó sẽ hoạt động theo quan điểm của người dùng. Tài liệu có hai mục tiêu. Một, chúng tôi muốn cung cấp một tài liệu có thể được xem xét bởi nhóm Marketing của chúng tôi để đảm bảo chúng tôi đáp ứng nhu cầu kinh doanh của chúng tôi. Hai, chúng tôi muốn cung cấp một tài liệu mà nhóm QA của chúng tôi có thể sử dụng để kiểm tra.
Pemdas

1
Tài liệu thiết kế của chúng tôi là chính thức và chi tiết hơn nhiều. Chúng luôn bao gồm các nội dung sau: Một số loại phân tích ca sử dụng, mọi giải thích về giao dịch hoặc lý do chúng tôi chọn một cách cụ thể để thực hiện, tham chiếu đến các thiết kế khác, định nghĩa giao diện rõ ràng, cấu trúc dữ liệu ... v.v. Chúng tôi không nhất thiết phải có ý kiến ​​rõ ràng về cách mã cụ thể đáp ứng các yêu cầu nhất định. Tôi không quyết định về việc tôi có nghĩ điều này quan trọng hay không.
Pemdas

1
Tôi muốn nói rằng các tài liệu của chúng tôi được cập nhật 95%. Một vài điều ở đây và trượt qua các vết nứt.
Pemdas

2

Tôi thấy hai vấn đề.

Đầu tiên là rất khó để giữ mã và tài liệu đồng bộ. Nếu chúng là riêng biệt, chúng sẽ phân kỳ và tài liệu sẽ trở nên vô dụng. Các lập trình viên đã cố gắng sử dụng các công cụ để thực hiện công việc giữ chúng đồng bộ (chẳng hạn như các công cụ CASE), nhưng các công cụ này có giữa các lập trình viên và mã của họ, điều này gây ra nhiều thiệt hại hơn là tốt. Một trong những hiểu biết chính của thiết kế hướng tên miền (Evans, 2004) là thiết kế tốt thực sự khó, vì vậy để có được thứ gì đó từ nó, bạn phải:

  • chọn khu vực nhỏ nhất có thể có trong chương trình của bạn, nơi thiết kế tốt sẽ mang lại lợi ích lớn, được gọi là miền lõi
  • làm việc rất chăm chỉ để có được một thiết kế tốt dưới dạng ngôn ngữ phổ biến mà tất cả các thành viên trong nhóm sử dụng mọi lúc
  • càng nhiều càng tốt, làm cho phần thiết kế của mã

Một vấn đề lớn khác với cách chúng ta thiết kế, là phương pháp thiết kế của chúng ta không đủ toán học. Sự trừu tượng rò rỉ không cho vay để rút ra kết luận chắc chắn từ chúng, và thế giới của logic được áp dụng nghiêm ngặt và sự thật rõ ràng được gọi là toán học, điều mà các lập trình viên chủ yếu né tránh.

Một vài công cụ toán học mà chúng ta có, như các phương thức chính thức, rất khó sử dụng.

Map-less là một ví dụ hay về toán học trong lập trình. Ý tưởng cốt lõi là thế này: Khi bạn có một hoạt động nhị phân, kết hợp, bạn có thể phân phối thực thi của nó rất dễ dàng. Một hoạt động nhị phân là một hàm có hai tham số, tính kết hợp ngụ ý rằng (a + b) + c = a + (b + c)

a1 + a2 + ... + a99 + b1 + b2 + ... + b99 + c1 + c2 + ... + c99 là

(a1 + a2 + ... + a99) + (b1 + b2 + ... + b99) + (c1 + c2 + ... + c99) trong đó các As, Bs và C có thể được thêm vào các vị trí khác nhau và tóm tắt trong thời gian không.

Map-less là một ý tưởng đơn giản đến nực cười. Nó có thể được mô tả trên một mảnh giấy. Nếu bạn có thể cho rằng người đọc đã nắm vững khái niệm về tính kết hợp, nếu phù hợp với một mảnh giấy khá nhỏ. Bây giờ hãy cố gắng giải thích bản đồ thu nhỏ cho ai đó mà không sử dụng thuật ngữ kết hợp hoặc đề cập đến nó một cách gián tiếp. Tao thách mày.

Thiết kế phần mềm không có trừu tượng toán học cũng giống như cố gắng làm kiến ​​trúc mà không bao giờ bận tâm đến việc học hình học.

Có lẽ Haskell có thể khắc phục điều này theo thời gian. Việc sử dụng các khái niệm từ lý thuyết thể loại để mô tả các chương trình có vẻ hứa hẹn với tôi. Lý thuyết phạm trù quá trừu tượng đến nỗi ngay cả các nhà toán học cũng ít sử dụng nó, nhưng rõ ràng các phạm trù, trừu tượng ngoài sự công nhận, dường như đủ trừu tượng để mô tả cấu trúc của phần mềm. Chúng ta sẽ tìm ra. Chậm rãi.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.