Có thực sự không có một điều trong 20 năm qua cung cấp lợi ích phát triển phần mềm khổng lồ? [đóng cửa]

Trong No Silver Bullet , Fred Brooks đưa ra nhiều dự đoán về tương lai của công nghệ phần mềm, được tóm tắt tốt nhất bởi:

Không có sự phát triển duy nhất, trong cả công nghệ hoặc kỹ thuật quản lý, mà chính nó hứa hẹn thậm chí là một sự cải thiện lớn về năng suất, về độ tin cậy, tính đơn giản.

Lập luận của ông rất thuyết phục. Brooks đã viết vào năm 1986: anh ấy có đúng không? Các nhà phát triển trong năm 2014 có sản xuất phần mềm với tốc độ nhanh hơn 10 lần so với các đối tác của họ vào năm 1986 không? Theo một số liệu thích hợp - mức tăng năng suất thực sự lớn đến mức nào?

Các nhà phát triển trong năm 2014 có sản xuất phần mềm với tốc độ nhanh hơn 10 lần so với các đối tác của họ vào năm 1986 không?

Tôi sẽ tưởng tượng rằng có ít nhất một trật tự cải thiện năng suất kể từ đó. Nhưng không phải bằng cách tận dụng một sự phát triển duy nhất, trong công nghệ hoặc kỹ thuật quản lý.

Tăng năng suất đã đến từ sự kết hợp của các yếu tố. Lưu ý: Đây không phải là một danh sách toàn diện:

1. Trình biên dịch tốt hơn
2. Máy tính mạnh hơn rất nhiều
3. Intellisense
4. Hướng đối tượng
5. Định hướng chức năng
6. Kỹ thuật quản lý bộ nhớ tốt hơn
7. Kiểm tra giới hạn
8. Phân tích mã tĩnh
9. Gõ mạnh
10. Kiểm tra đơn vị
11. Thiết kế ngôn ngữ lập trình tốt hơn
12. Tạo mã
13. Hệ thống kiểm soát mã nguồn
14. Tái sử dụng mã

Và như vậy. Tất cả các kỹ thuật này kết hợp để tạo ra tăng năng suất; không có một viên đạn bạc nào tạo ra một tốc độ tăng tốc độ lớn.

Lưu ý rằng một số trong những kỹ thuật này đã tồn tại từ những năm sáu mươi, nhưng chỉ quan sát thấy sự công nhận và áp dụng rộng rãi gần đây.

Câu trả lời của Robert Harvey là tốt, nhưng tôi nghĩ ông đã bỏ qua những gì có thể là lý do lớn nhất khiến các lập trình viên làm việc hiệu quả hơn bao giờ hết: thư viện phần mềm có sẵn rộng rãi.

Khi tôi bắt đầu sự nghiệp của mình, không có STL, .NET, QT, v.v. Bạn có C hoặc C ++ thô, và đó là về nó.

Những việc trước đây mất vài ngày hoặc vài tuần hoặc làm việc (phân tích cú pháp XML, kết nối TCP / IP, truyền thông HTTP) giờ đây có thể được thực hiện với một số dòng mã C #. Đây là nơi chúng tôi đã nhận được các đơn đặt hàng lớn hơn về năng suất tổng thể của nhà phát triển.

Sản phẩm hiện tại của chúng tôi sử dụng khung cửa sổ lắp ghép mà chúng tôi đã mua từ một nhà cung cấp. Điều này cho phép tôi có một giao diện người dùng cửa sổ lắp ghép đầy đủ chức năng trong vài phút. Tôi rùng mình khi nghĩ về những gì sẽ cần để làm điều đó trong những ngày sử dụng API win32.

Để tranh luận, tôi không đồng ý với lời khẳng định của Fred Brooks .

Có một sự cải tiến trong công nghệ cho phép một mình cải thiện năng suất: internet , và chính xác hơn là sự sẵn có tiến bộ của kết nối internet ở mọi nhà trong hai thập kỷ qua.

Có thể tìm thấy ngay một câu trả lời cho gần như mọi vấn đề bạn có thể gặp phải khi nhà phát triển cho phép tăng năng suất rất lớn. Bạn không biết cách chọn phần tử thứ n trong JQuery? Tìm kiếm của Google dẫn đến câu trả lời cho câu hỏi chính xác về Stack Overflow . Bạn không biết cách sử dụng overflowCSS? MDN của Mozilla có ở đây . Quên virtualtừ khóa có nghĩa là gì trong C #? Google giúp , một lần nữa.

Khi tôi bắt đầu lập trình, tôi không có internet. Tôi đã có sách, cũng như một số tài liệu định dạng kỹ thuật số được lưu trữ cục bộ, nhưng tìm kiếm qua sách và tài liệu là một quá trình chậm chạp và cho dù tôi có bao nhiêu sách đi chăng nữa, vẫn có nhiều vấn đề không được đề cập ở đó.

Quan trọng hơn, gần như mọi vấn đề bạn gặp phải đã bị người khác gặp phải trước đó. Internet giúp tìm kiếm những người có lỗi này và giải quyết thành công. Đây không phải là một loại thông tin bạn tìm thấy trong sách hoặc tài liệu chính thức như MSDN. Thay vào đó, thông tin như vậy thường được tìm thấy:

• Trên Stack Overflow, rõ ràng. Ví dụ, tôi chưa thấy cuốn sách nào đề cập đến vấn đề này .

• Trong blog. Tôi đã tìm thấy rất nhiều trợ giúp trên các blog khi tôi gặp vấn đề cụ thể, đó là với cấu hình WCF hoặc máy chủ proxy không khởi động hoặc lỗi khó hiểu khi sử dụng API cụ thể trên máy có văn hóa khác với en-US.

• Trong các báo cáo lỗi liên quan đến phần mềm nguồn mở. Ví dụ, gần đây nó rất hữu ích khi tôi cố gắng sử dụng MAAS của Ubuntu và khi tôi sử dụng PXE. Bạn cũng không tìm thấy loại thông tin này trong sách.

Tầm quan trọng của sự sẵn có ngay lập tức của một câu trả lời cho hầu hết các vấn đề mà người ta có thể gặp phải đặc biệt đáng chú ý nếu chúng ta tính đến việc hầu hết thời gian một nhóm dành cho một dự án được dành để duy trì nó.

• Internet không giúp được gì nhiều trong các giai đoạn kiến ​​trúc và thiết kế (Lập trình viên. Có thể giúp ích, nhưng sẽ rất có giá trị đối với một kiến ​​trúc sư đọc sách về kiến ​​trúc và thiết kế, để tìm hiểu các mẫu thiết kế, v.v.).

• Nó bắt đầu hữu ích trong các bước thử nghiệm và triển khai, khi có vấn đề thực sự phát sinh.

• Nhưng hầu hết các vấn đề xuất hiện trong quá trình bảo trì, đó là khi sự giúp đỡ từ những người khác thông qua internet có vẻ rất quan trọng . Ví dụ cơ bản: một dịch vụ WCF hoạt động hoàn hảo trên máy của tôi , nhưng không có ngoại lệ nào khi được triển khai trong sản xuất, trong khi nó hoạt động trong hai tuần qua. Điều này đã xảy ra với tôi và tôi rất biết ơn các nhà văn blog và cộng đồng Stack Overflow đã giúp tôi giải quyết vấn đề trong vài giờ thay vì hàng tuần.

Nó sẽ biện minh cho sự gia tăng năng suất x10? Khó nói.

• Một mặt, có những trường hợp bạn tìm thấy câu trả lời ngay lập tức, trong khi bạn có thể mất nhiều ngày để tìm kiếm nó một mình (hoặc bị buộc phải viết lại một phần lớn của ứng dụng).

• Mặt khác, năng suất tổng thể được cải thiện dựa trên nhiều yếu tố, chẳng hạn như quản lý dự án tốt hơn (Agile, TDD, v.v.), quản lý nhóm tốt hơn ( Quản lý cấp tiến của Stephen Denning), các công cụ tốt hơn (trình gỡ lỗi, trình biên dịch , IDE, v.v.), phần cứng tốt hơn (không, tôi sẽ không làm việc hiệu quả nếu buộc phải ghi vào Trình biên dịch cho CPU chậm và RAM rất hạn chế), v.v.

Tôi muốn nói rằng internet là một ứng cử viên khá tốt. StackOverflow và Google là những công cụ mạnh nhất của nhà phát triển hiện đại. Chia sẻ kiến ​​thức ngay lập tức trên cơ sở toàn cầu! Ngày nay, bạn không cần biết câu trả lời, bạn chỉ cần biết cách tìm hiểu câu trả lời - và đó là một mục tiêu hoàn toàn đầy đủ cho phép các nhà phát triển dành ít thời gian hơn để đọc và nhiều thời gian hơn để viết mã, và do đó có hiệu quả. Điều đó có nghĩa là mọi lập trình viên trên thế giới đều có quyền truy cập vào tất cả các câu trả lời, và tất cả những gì họ cần làm là biết cách đặt câu hỏi đúng.

Tôi sẽ đề xuất rằng các xu hướng kéo chúng ta theo hướng khác (tức là hướng tới năng suất thấp hơn) ít nhất là mạnh mẽ như các xu hướng bạn đã hỏi về. Kinh nghiệm làm công cụ phát triển máy khách / máy chủ như VB6 hoặc PowerBuilder đã tiến gần đến lý tưởng "Phát triển ứng dụng nhanh" (RAD). Bạn phải vẽ các biểu mẫu của mình và có các móc rõ ràng cho mã thủ tục hoặc mã SQL của bạn.

Phát triển web, ít nhất là ban đầu, đã phá hủy rất nhiều kỹ thuật và cơ sở hạ tầng khiến những điều này trở nên khả thi, và nhiều nhà phát triển máy khách / máy chủ chỉ dừng lại là nhà phát triển, hoặc tuyệt vọng, nói, VB6.

Việc chuyển đổi sang phát triển Web hướng đến khách hàng rất nhiều là một trải nghiệm chặt chém khác; Microsoft đã trở lại với lý tưởng RAD với WebForms, và sau đó nó nhanh chóng không được ủng hộ. Thay vào đó, các nhà phát triển dự kiến ​​sẽ lạm dụng cơ sở hạ tầng (ví dụ: XMLHttpRequest, vốn hiếm khi được sử dụng cho XML) và mặt khác, ở mức độ trừu tượng thấp trong nỗ lực làm cho trang web của họ tương tác nhiều hơn

Có nhiều lý do chính đáng đằng sau tất cả các chuyển đổi này và thật không công bằng khi so sánh một quy trình mang lại một .EXE (yêu cầu cài đặt và quản lý tại từng khách hàng) để phát triển Web, cũng không hoàn toàn công bằng khi so sánh một quy trình dựa nhiều vào trên postback với một trong đó mang lại một trải nghiệm liền mạch hơn. Nhưng tôi sẽ nói rằng các thực tiễn hiện đang thịnh hành dẫn đến một số quá trình suy nghĩ cấp thấp đáng ngạc nhiên trong số những người đã bỏ lỡ máy khách / máy chủ, RAD và những thứ tương tự. Các nút máy khách / máy chủ chỉ hoạt động và chắc chắn người ta không phải lo lắng về các kênh dữ liệu cơ bản có dữ liệu cho các trình xử lý sự kiện đã thực hiện điều này.

Ngược lại, các nhà phát triển hiện đại hơn có xu hướng nghĩ rằng những người trong chúng ta đã phát triển máy khách / máy chủ (hoặc thậm chí phát triển Web dựa trên postback) có xu hướng sử dụng các phím tắt (và có nghĩa là theo cách xấu). Điều đó có thể hiểu được, nhưng tôi vẫn nghĩ rằng cách phát triển đương đại được thực hiện ở mức độ thấp đáng kinh ngạc, và những ngày tìm kiếm "viên đạn bạc" dường như đã nhường chỗ cho thời đại chế giễu những người trong chúng ta nghi ngờ sự khôn ngoan của khai thác và nấu chảy chì của chúng ta.

Công nghệ đã tiến bộ rất nhiều và bây giờ chúng ta có tất cả những điều Robert Harvey liệt kê trong câu trả lời của mình, nhưng:

• Vấn đề dường như đang thay đổi yêu cầu . Khách hàng biết rằng sẽ không lãng phí vật liệu khi thay đổi các yêu cầu của dự án phần mềm, vì vậy họ làm. Loại yêu cầu đó thay đổi gần như không bao giờ xảy ra một khi dự án thế giới vật lý như tòa nhà, được thực hiện một nửa.

• Một khía cạnh quan trọng khác là lập trình tiếp tục có tính thủ công cao . Hiếm khi có, mã do RAD tạo ra được sản xuất mà không được sửa đổi bằng tay trước.

• Mã tiếp tục rất phức tạp và sự phức tạp đó dường như không giảm với các công nghệ mới.

• Tỷ lệ thời hạn không đáp ứng hoặc vượt quá ngân sách tiếp tục lớn hơn so với những người trong các ngành khác và thường phải trả nợ kỹ thuật để đáp ứng chúng, tạo ra chi phí ẩn.

• Một điều mà, không nghi ngờ gì, đã xảy ra là sự ngăn cách đã bị ảnh hưởng. Một loạt các công nghệ mà người ta phải biết là các lập trình viên phải chuyên môn hóa một số lượng nhỏ công nghệ để trở nên thực sự giỏi về chúng, đòi hỏi các loại chuyên gia khác nhau phải hoàn thành một dự án lớn.

• Một điều nói về sự phức tạp của phần mềm là trong khi có hàng trăm nhà sản xuất ô tô trên thế giới, danh sách các công ty có khả năng tạo và bảo trì một hệ điều hành , (máy tính để bàn, di động, nhúng hoặc cách khác), có thể được đếm bằng ngón tay bàn tay của bạn.

• Tất cả những điều trên đã tạo ra một tình huống trong đó không có đủ người học làm lập trình viên , do đó chính phủ đã tạo ra các chiến dịch để thúc đẩy nhiều sinh viên tham gia vào con đường sự nghiệp đó.

• Một hương vị của sự trưởng thành của ngành công nghiệp phần mềm là giấy phép phần mềm tiếp tục tuyên bố "<companyX> không đưa ra tuyên bố nào về tính phù hợp của phần mềm này cho bất kỳ mục đích cụ thể nào. Nó được cung cấp" như là "không có bảo hành rõ ràng hay ngụ ý." Hãy tưởng tượng một nhà sản xuất phần cứng nói rằng sản phẩm của họ không phù hợp với bất kỳ mục đích cụ thể nào. Đó là tình trạng của nghệ thuật ngay bây giờ.

Trong khi người ta có thể tranh luận với các số liệu cụ thể (nghĩa là mọi thứ được cải thiện theo hệ số 9,98?), Tôi (nói như một cái gì đó của đồng hồ cũ) phải đồng ý với tâm lý chung của nhận xét của Brooks.

Trước hết, có rất ít công nghệ thực sự mới được phát minh kể từ năm 1970. Vâng, các mạch tích hợp đã dài hơn, thấp hơn, rộng hơn và sợi thủy tinh đã cải thiện tốc độ liên lạc, nhưng cứ sau một bước lại có một bước lùi.

Công nghệ trình biên dịch đã cho phép cải thiện gấp 10 lần "năng suất" của lập trình viên so với năm 1970, khi một hàm số được tạo ra chia cho thời gian mã hóa thực tế, nhưng sự phát triển của các ngôn ngữ và môi trường lập trình mới hoặc "sửa đổi" có nghĩa là lập trình viên trung bình đang chi tiêu ngày càng nhiều thời gian ở chế độ "bắt kịp" và ít hơn trong hoạt động sản xuất. Apple, Google và Microsoft đều đưa ra những "nâng cấp" mới và không tương thích đáng kể với môi trường của họ với tốc độ thấp hơn mức đó sẽ gây ra cuộc nổi dậy giữa các khách hàng của họ ... Tương tự, HTML / CSS / Javascript / bất cứ điều gì tiếp tục phức tạp hơn.

Đã có lúc tốc độ mà tài liệu có thể được sản xuất và tuyên truyền sẽ hạn chế và khắc phục tất cả sự "đổi mới" này, nhưng, nhờ có Internet, tài liệu nghiêm ngặt không còn thực sự cần thiết - chỉ cần phun ra các chức năng và dựa vào các blogger chồn ra các chi tiết và làm cho chúng có sẵn.

Đã thêm: Tôi đã suy nghĩ về điều này từ hôm qua và đặc biệt là suy nghĩ về dự án tôi đã làm từ khoảng năm 1978 đến năm 2008. Dự án này (Hệ thống IBM / 38 và những người kế nhiệm của nó) có phần độc đáo ở những nỗ lực ban đầu là được thực hiện để kiểm soát sự phức tạp của nó (một là phân chia phần mềm thành hai phần gần bằng nhau, với giao diện "máy" giữa chúng). Trong khu vực cụ thể nơi tôi làm việc, một số đồng nghiệp của tôi cũng tương tự chuyên kiểm soát sự phức tạp (mặc dù chúng tôi không sử dụng thuật ngữ đó nhiều vào thời điểm đó). Kết quả là một sản phẩm (lúc đầu) khá mạnh mẽ và "gây ấn tượng" với khách hàng khá nhiều từ git-go. Và đó là một niềm vui để làm việc trên - như chơi trong một dàn nhạc được đào tạo tốt.

Tất nhiên, qua nhiều năm, sự phức tạp len lỏi vào, thường là theo lệnh của các nhà hoạch định và quản lý thị trường, những người không đánh giá cao việc kiểm soát sự phức tạp (điều này khác với việc duy trì sự đơn giản). Tôi không có cảm giác rằng điều này là không thể tránh khỏi, nhưng không thể ngăn chặn trong trường hợp này mà không có người quản lý (như Glenn Henry ban đầu) đẩy lùi lực lượng của sự nhầm lẫn.

Rất nhiều điều chúng ta đã học được trong thực hành kỹ thuật phần mềm trong hơn 30 năm qua là ở dạng "công nghệ X có thể tăng tốc độ phát triển ban đầu của phần mềm mới, nhưng nếu bạn không dành nhiều hoặc nhiều thời gian để suy nghĩ về cách thức và Khi nào nên sử dụng nó khi bạn tiết kiệm bằng cách sử dụng nó, về lâu dài, nó sẽ biến ứng dụng của bạn thành một vũng nợ kỹ thuật, khiến bạn mất nhiều thời gian và công sức để bảo trì. "

Các công nghệ thuộc loại dao cạo này bao gồm: ngôn ngữ lắp ráp được mã hóa bằng tay, trình biên dịch, trình thông dịch, thư viện thủ tục, lập trình mệnh lệnh, lập trình chức năng, lập trình hướng đối tượng, cấp phát bộ nhớ thủ công, thu gom rác, loại tĩnh, loại động, phạm vi từ vựng, phạm vi động , Con trỏ "an toàn", con trỏ "không an toàn", không có con trỏ như một khái niệm ngôn ngữ, định dạng tệp nhị phân, định dạng tệp đánh dấu cấu trúc, macro, mẫu, tránh macro và mẫu, bộ nhớ chia sẻ, chuyển tin nhắn, luồng, coroutines, các vòng lặp sự kiện không đồng bộ, các dịch vụ từ xa tập trung, dịch vụ phân tán, phần mềm được cài đặt cục bộ, mảng, danh sách được liên kết, bảng băm và cây.

Thực tế là nhiều mục trong danh sách trên xuất hiện trong các nhóm cùng nhau làm cạn kiệt không gian giải pháp đã biết là rất có chủ ý, và chính nó sẽ cho bạn biết điều gì đó. Người ta có thể lập luận rằng những cải tiến rõ ràng, duy nhất trong các bảng quảng cáo mà chúng tôi đã có kể từ khi lần đầu tiên bật Z3 là lập trình có cấu trúc khối (trái ngược với mã spaghetti) và bảo vệ bộ nhớ (tôi không bao giờ bỏ lỡ những ngày mà một lỗi đánh máy có thể làm hỏng toàn bộ máy tính của tôi).