Có phải nhu cầu về đặc tả thiết kế phần mềm giảm đáng kể với sự phát triển của các ngôn ngữ lập trình biểu cảm hơn?

Đối với nhiều người CNTT, kể cả bản thân tôi vài năm trước, quy trình phát triển phần mềm lý tưởng sẽ liên quan đến việc tạo ra các tài liệu thiết kế chi tiết với nhiều sơ đồ UML trước khi một dòng mã được viết. (Điều này trông giống như một mô tả về mô hình thác nước nhưng nó giống với nhanh nhẹn, ngoại trừ việc lặp lại nhỏ hơn.)

Trong hai hoặc ba năm qua, tôi đã thay đổi hoàn toàn suy nghĩ của mình. Tôi vẫn nghĩ rằng một đặc tả yêu cầu chi tiết với các trường hợp thử nghiệm liên quan là hoàn toàn cần thiết. Đối với các dự án lớn, tôi cũng sẽ yêu cầu một phác thảo về kiến ​​trúc tổng thể trước khi bắt đầu viết mã. Nhưng tất cả phần còn lại nên được thực hiện trong mã càng nhiều càng tốt. Trong trường hợp lý tưởng không nên có mô tả về thiết kế phần mềm ngoại trừ chính mã.

Làm thế nào tôi đi đến kết luận này? Dưới đây là một số đối số:

Phản hồi

Các công cụ để viết tài liệu hoặc tạo sơ đồ cung cấp ít phản hồi. Đúng, có các công cụ mô hình hóa thực hiện một số kiểm tra tính nhất quán trên các sơ đồ UML nhưng chúng bị giới hạn và đi kèm với rất nhiều chi phí.

Không có phản hồi thì khó nhận biết và sửa lỗi.

Ngay khi bạn viết mã, bạn sẽ nhận được rất nhiều phản hồi, ví dụ:

• Lỗi và cảnh báo từ trình biên dịch
• Kết quả phân tích mã tĩnh
• Bài kiểm tra đơn vị

Lỗi có thể nhanh chóng được nhận ra và sửa chữa.

Tính nhất quán

Để đảm bảo rằng mã phù hợp với tài liệu của bạn, bạn phải kiểm tra lại nhiều lần. Nếu có những thay đổi thường xuyên, thật khó để giữ đồng bộ mã và tài liệu.

Tái cấu trúc

Có các công cụ và kỹ thuật mạnh mẽ để tái cấu trúc mã trong khi tái cấu trúc các mô tả hoặc sơ đồ văn bản thường khó và dễ bị lỗi.

Có một điều kiện tiên quyết để thực hiện công việc này: Mã phải đủ dễ đọc và hiểu. Điều này có lẽ không thể đạt được với Trình biên dịch, Cơ bản hoặc Fortran nhưng các ngôn ngữ hiện đại (và thư viện) thì biểu cảm hơn nhiều.

Vì vậy, nếu các đối số của tôi là hợp lệ, sẽ có một xu hướng về tài liệu và đặc tả thiết kế phần mềm nhẹ hơn hoặc nhẹ hơn. Có bằng chứng thực nghiệm cho xu hướng này?

Tôi đặt câu hỏi về tiền đề rằng các ngôn ngữ ngày càng biểu cảm hơn. Với mã ASP.NET ngày nay bằng c #, tôi viết ở mức tương tự như khi tôi viết mã ASP trong Visual Basic. Chúng tôi vẫn sử dụng c ++. Javascript đã thêm các tính năng nhưng nói chung ngôn ngữ không thay đổi. Tương tự với SQL.

Tôi nghĩ những thay đổi khác này có ý nghĩa hơn:

1. Thông qua các bài kiểm tra đơn vị tự động. Một số người sẽ nói rằng các bài kiểm tra là đặc điểm kỹ thuật. Vì vậy, chúng tôi đã không loại bỏ sự cần thiết phải viết thông số kỹ thuật; thay vào đó, chúng tôi viết chúng bằng mã chứ không phải trong tài liệu Word.

2. Thay đổi phương pháp triển khai. Trước đây, rất tốn kém khi mắc lỗi vì bạn sẽ cần gửi một bản sao cập nhật của phần mềm của mình. Vì vậy, bạn phải cẩn thận. Với các ứng dụng điều khiển web, bạn có thể triển khai các bản sửa lỗi để sử dụng ngay lập tức và bạn có thể đủ khả năng phản ứng với các vấn đề thay vì dự đoán chúng, cơ cấu lại mã khi bạn đi.

3. Thông qua các mẫu thiết kế. Khi mọi người đều biết các mẫu, bạn hầu như không phải thiết kế bất cứ thứ gì; bạn chỉ có thể nói "thêm một nhà máy lưu trữ" và nhóm của bạn sẽ làm điều đó mà không cần phải xem UML.

4. Hợp đồng dữ liệu của SOA. Ngày nay, hầu hết mọi thứ đều là SOA. Tất cả bạn cần là một WSDL. Những ngày xác định và ghi lại các định dạng truyền dữ liệu đã không còn nữa. Động thái hiện tại hướng tới nhiều dịch vụ RESTful và micro tiếp tục xu hướng này.

5. Phần mềm nhỏ hơn. Một phần là kết quả của kiến ​​trúc SOA, các nhóm đang viết các chương trình nhỏ hơn được gắn với nhau. Mỗi thành phần riêng lẻ ít phức tạp hơn và yêu cầu thiết kế phía trước ít hơn; Ngoài ra, việc thay đổi một phần kiến ​​trúc sẽ dễ dàng hơn mà không phá vỡ giải pháp tổng thể do các vụ cháy bắt buộc bởi các định nghĩa giao diện giữa các thành phần.

6. Sử dụng nhiều, nhiều hơn các thư viện thành lập. .NET CLR cung cấp rất nhiều chức năng ngoài giá, do đó, không cần thiết kế một sơ đồ cho bộ đệm dữ liệu phiên. Các thư viện bên thứ ba như jQuery UI hoặc Bootstrap thiết lập các tiêu chuẩn để viết mã để hoạt động theo một cách nhất định. Bạn không cần phải ghi lại những điều này; các đội nên có thể chỉ sử dụng chúng.

7. Công nghiệp trưởng thành. SWE đã học được rằng không có thứ gọi là dự án "Battlestar Galactica" nơi bạn dành nhiều năm và nhiều năm cố gắng để đạt được một mục tiêu cụ thể; đến khi những năm đó trôi qua, mục tiêu sẽ thay đổi. Ngày nay chúng ta biết rằng thời gian để tiếp thị quan trọng hơn nhiều so với việc có được mọi thứ chính xác theo cách chúng ta muốn trong thiết kế.

8. Các kỹ sư được giáo dục tốt hơn và nhất quán hơn. Ngày nay, bạn có thể thuê các kỹ sư hiểu các thực tiễn tốt nhất (hy vọng) và sẽ chỉ thực hiện chúng mà không cần một tài liệu thiết kế cho họ biết phải làm gì.

9. Các công cụ năng suất như TFS cho phép bạn viết một tác vụ đơn giản tham chiếu trường hợp sử dụng và cung cấp một vài gạch đầu dòng cho bất kỳ quyết định kỹ thuật mơ hồ nào. Bạn không cần nhiều hơn thế. Các nhà phát triển có thể xem xét, ước tính, nhận mã đánh giá, đăng ký, v.v. mọi thứ thông qua công cụ. Điều này hiệu quả hơn nhiều so với làm việc với các tài liệu bên ngoài vì nó liên kết mọi thứ với nhau.

Bạn vẫn cần tài liệu thiết kế cho một số thứ ... ví dụ: nếu ứng dụng của bạn được chia thành các thành phần khác nhau được phát triển bởi các nhóm khác nhau, ít nhất bạn cần cho họ biết thành phần nào chịu trách nhiệm cho yêu cầu nào. Nhưng phần lớn, các phương pháp phát triển ngày nay cho phép tự do hơn nhiều trong khi cung cấp cho bạn các công cụ để quản lý và chứa bất kỳ rủi ro nào có thể phát sinh từ một nhà phát triển đưa ra quyết định kém.

Tôi sẽ tranh luận cho Không .

Vì lý do đơn giản mà

Đối với nhiều người CNTT, kể cả bản thân tôi vài năm trước, quy trình phát triển phần mềm lý tưởng sẽ liên quan đến việc tạo ra các tài liệu thiết kế chi tiết với nhiều sơ đồ UML trước khi một dòng mã được viết.

Chưa bao giờ được coi là "lý tưởng", vì Lập trình cực đoan đã tồn tại từ những năm 1990 . Và như bạn nói:

Trong trường hợp lý tưởng không nên có mô tả về thiết kế phần mềm ngoại trừ chính mã.

Đã được tranh luận từ lâu. Ví dụ bài viết huyền thoại này từ năm 1992: Thiết kế phần mềm là gì .

Những điều trên cho thấy rằng bạn có thể có quá trình "cực đoan" với kiến ​​trúc tiến hóa và cách tiếp cận lặp đi lặp lại mà không cần các ngôn ngữ hoặc IDE phức tạp.

Thay vào đó, tôi sẽ nói rằng sự thay đổi "dường như" này từ phía trước thiết kế với rất nhiều sơ đồ và sử dụng tài liệu tình huống sang cách tiếp cận tiến hóa và lặp đi lặp lại chỉ đơn giản là các nhà quản lý "trường học cũ" được thay thế bằng những người mới, người lớn lên nhiều hơn môi trường năng động và dễ dàng hơn nhiều để chấp nhận và làm việc trong môi trường "nhanh nhẹn" hơn.

Tôi khá đồng ý với điều này nhưng tôi nghĩ nó bắt đầu sớm hơn nhiều so với bạn ngụ ý. Tôi cũng nghĩ rằng có một yếu tố lớn khác ngoài biểu cảm. Khi cha tôi mới bắt đầu lập trình, ông phải tạo ra những tấm thẻ đục lỗ và sắp xếp thời gian trên máy tính. Bạn có thể có một cơ hội một ngày để chạy chương trình của bạn. Không có nhiều thời gian để lãng phí mã xây dựng, để nó thất bại và sau đó sửa nó. Bạn có thể bắn 2 hoặc 3 lần vào nó và nếu nó không hoạt động, bạn sẽ gặp rắc rối.

Nguy cơ của điều này có nghĩa là rất quan trọng để dành nhiều thời gian thêm để lên kế hoạch cho chương trình của bạn. Mọi người sẽ viết mã của họ ra bằng bút chì, và sau đó chuyển nó vào các thẻ đục lỗ. Khi công nghệ phát triển, bạn có thể mã ngay vào thiết bị đầu cuối nhưng bạn vẫn đang sử dụng tài nguyên được chia sẻ và CPU rất tốn kém. Một phương pháp thử nghiệm đầu tiên sẽ hoàn toàn không thể thực hiện được trong thế giới đó. Nếu bạn không có kế hoạch trước, các đồng nghiệp của bạn sẽ ở bàn làm việc của bạn với cây chĩa.

Tài nguyên điện toán đã trở nên rẻ hơn và tốt hơn với tốc độ đáng kinh ngạc. Nhiều ràng buộc mà theo đó tất cả các thực hành này đã được phát triển hoàn toàn bị xóa sạch. Như Euphoric chỉ ra, việc di chuyển khỏi điều này thực sự đã bắt đầu vào những năm 90. Sự tiếp nối của phần lớn thiết kế phía trước lớn là quán tính thuần túy.

Vì vậy, vâng, tính biểu cảm được cải thiện của các ngôn ngữ lập trình đã có tác động đến điều này từ thực tế đơn giản là việc sử dụng mã biểu cảm như tài liệu riêng của nó dễ dàng hơn. Chi phí sản xuất một tài liệu cho bạn biết những gì mã nói là rất cao và giá trị của nó (chắc chắn là sai ở một mức độ nào đó.) Đồng thời chi phí ném cứt vào tường và xem những gì gậy về cơ bản là không đáng kể.

Tôi nghĩ rằng bạn quên mục đích của việc có tài liệu thiết kế ở nơi đầu tiên!

Tài liệu thiết kế (yêu cầu, trường hợp sử dụng, mô phỏng, v.v.) cho phép chúng tôi mô tả, hiểu và thảo luận về hệ thống ở mức cao. Số lượng chi tiết còn lại trong các tài liệu đó là những gì làm cho chúng hữu ích.

Không cần phải có tài liệu mô tả hành vi chính xác của hệ thống trong tất cả các chi tiết, vì thực sự chính mã nguồn phục vụ mục đích này.

Phát triển phần mềm có thể được coi là quá trình biến đổi các thông số kỹ thuật có thể đọc được của con người ở mức độ cao thành các thông số kỹ thuật rõ ràng ở mức độ thấp có thể thực hiện được bằng máy. Nhưng bạn cần một số đầu vào cho quá trình này.

Trong trường hợp lý tưởng không nên có mô tả về thiết kế phần mềm ngoại trừ chính mã.

Điều này là xa hơn bạn ngụ ý. Ngay cả những thứ như các loại phụ thuộc (mà theo tôi hiểu, về mặt lý thuyết khá hứa hẹn) đã được vài năm.

Xác minh chính thức khá khó khăn và vì lý do đó, nơi duy nhất thường sử dụng xác minh chính thức là các thư viện mật mã.

Bài kiểm tra đơn vị

Nếu thử nghiệm tài sản không đạt được xu hướng, tôi không nghĩ rằng điều này sẽ thực tế trong một thời gian dài.

Hơn nữa, viết các bài kiểm tra tốt (sẽ không cần chỉnh sửa với mọi bộ tái cấu trúc nhưng vẫn sẽ bắt đủ lỗi) là khá khó khăn.

Để đảm bảo rằng mã phù hợp với tài liệu của bạn, bạn phải kiểm tra lại nhiều lần. Nếu có những thay đổi thường xuyên, thật khó để giữ đồng bộ mã và tài liệu.

Có lẽ dễ dàng hơn để sử dụng một công cụ kiểm tra tài liệu tại thời điểm này.

Có một điều kiện tiên quyết để thực hiện công việc này: Mã phải đủ dễ đọc và hiểu.

Thật không may, thiết kế các ngôn ngữ không chỉ cực kỳ biểu cảm mà còn có thể đọc được rất khó. Các ngôn ngữ như Go ưu tiên khả năng đọc và nó đánh bại suy nghĩ cấp cao hơn.

Cuối cùng, theo kinh nghiệm của tôi, các ngôn ngữ và công cụ tốt hơn không dẫn đến phần mềm có ít lỗi hơn mà là các dự án lớn hơn. Thực sự không có cách nào hợp lý pandocsẽ được viết vào năm 1970.