Một ví dụ tốt về một ý tưởng hoặc kỹ thuật phát triển phần mềm là một thất bại là gì?

Cụ thể một số ví dụ về ý tưởng của quần chúng ở đâu chỉ sai. Tại sao mọi người bắt đầu lên ý tưởng ngay từ đầu? Và tại sao các ý tưởng bị loại bỏ? Hoặc có lẽ các ý tưởng vẫn còn sống và tốt và nếu vậy tại sao?

Ví dụ, tôi có thể mô tả CORBA (và các công nghệ tương tự khác) như một thứ gì đó đã cố gắng giải quyết vấn đề giao tiếp giữa các thành phần của phần mềm. Nhiều người cảm thấy cần phải xác định hợp đồng giữa các thành phần khác nhau. Cuối cùng, HTTP + JSON đã giải quyết vấn đề cho số đông và các cơ chế RPC khác nhau như Thrift và Proto-bufs đã xuất hiện.

Về cơ bản, giống như trong thế giới bên ngoài máy tính, các ý tưởng và công nghệ cạnh tranh để thu hút sự chú ý, tận dụng, v.v ... Một số thắng, một số thua; và một số có vẻ là Người chiến thắng trong một thời gian, sau đó mờ dần đi với sự xuất hiện của The Next Big Thing. Nó có thể có hoặc không có gì để làm với cái mà thực sự tốt hơn. Chứng kiến ​​VHS vs Betamax, hoặc cuộc chiến gần đây hơn giữa các định dạng DVD khác nhau.

CORBA rất lớn, vụng về và khó sử dụng, nhưng đó là thứ tốt nhất mà một số người có thể phát minh ra vào thời điểm đó (lưu ý rằng nó được thiết kế trước World Wide Web - và HTTP, Java, XML, ... - được biết đến rộng rãi). Và đó cũng là một ví dụ kinh điển về thiết kế của ủy ban , nơi họ nhồi nhét mọi ý tưởng để làm hài lòng tất cả mọi người, cuối cùng làm cho nó trở nên vô dụng (ít nhất là được nhìn bởi đôi mắt ngày nay). Chưa kể giá của nó, mà với sự ra đời của FOSS sớm trở nên cấm đoán.

Cuối cùng, HTTP + JSON đã giải quyết vấn đề cho số đông

Ít nhất là đối với một người chưa từng thấy một vài "giải pháp cuối cùng" tương tự tăng và cuối cùng rơi xuống ... Thật tốt khi nhớ rằng có một tình cảm tương tự về CORBA trong thời điểm đó ;-)

Tôi cảm thấy có thể trích dẫn từ The Rise and Fall of CORBA :

Lịch sử của CORBA là một trong những ngành công nghiệp điện toán đã thấy nhiều lần và dường như các nỗ lực phần mềm trung gian hiện tại, cụ thể là các dịch vụ Web, sẽ tái hiện một lịch sử tương tự. [...]

Nhìn chung, quy trình áp dụng công nghệ của OMG phải được coi là lý do cốt lõi cho sự suy giảm của CORBA. Quá trình này khuyến khích thiết kế bởi ủy ban và điều động chính trị đến mức khó đạt được sự tầm thường về kỹ thuật, chứ đừng nói đến kỹ thuật xuất sắc. Hơn nữa, việc bổ sung các tính năng rời rạc dẫn đến sự xói mòn dần dần tầm nhìn kiến ​​trúc. [...]

Một quy trình dân chủ như OMG là hoàn toàn không phù hợp để tạo ra phần mềm tốt. Mặc dù các vấn đề thủ tục đã biết, tuy nhiên, ngành công nghiệp thích dựa vào các tập đoàn lớn để sản xuất công nghệ. Các dịch vụ web, viên đạn bạc hiện tại của phần mềm trung gian, sử dụng một quy trình giống như của OMG và, theo nhiều tài khoản, cũng phải chịu sự đấu đá, phân mảnh, thiếu sự gắn kết kiến ​​trúc, thiết kế bởi ủy ban và tính năng phình to. Dường như các dịch vụ web sẽ bắt đầu một lịch sử khá giống với CORBA.

Bây giờ từ một góc độ khác: khi đọc thuật ngữ "ý tưởng của quần chúng", tôi đã nghĩ về những điều rất khác so với CORBA hoặc các tiêu chuẩn khác; đây thường là ý tưởng của một người hoặc một nhóm nhỏ. Tôi đã nghĩ về những thực tiễn / quan điểm khét tiếng như "mã hóa cao bồi", "mã và cầu nguyện", "nó hoạt động trên máy của tôi", v.v ... Đây là những "ý tưởng thực sự" của IMHO, vì đây là cách mà hầu hết mọi người mới bắt đầu Nhà phát triển bắt đầu viết mã. Và họ đã sai, vì họ không mở rộng quy mô trong không gian cũng như thời gian - người ta không thể tạo ra các chương trình lớn, có thể bảo trì, có thể mở rộng theo cách này. Tuy nhiên, tôi cảm thấy tiếc rằng đó vẫn là tiêu chuẩn chứ không phải là ngoại lệ để mọi người cố gắng làm việc theo cách này trong các cửa hàng chuyên nghiệp trên toàn thế giới.

Điểm cực đoan khác của điều này là nhiều ý tưởng của các nhà quản lý và lý thuyết về "cách tiếp cận đúng" đối với sự phát triển SW, thể hiện trong các Phương pháp M lớn như CMM, RUP, Waterfall, v.v. Ý tưởng nằm sau tất cả những điều này là tất cả những gì bạn cần là Đúng quy trình và nó sẽ bắt đầu tự động sản xuất phần mềm chất lượng theo cách xác định, bất kể nhà phát triển thực sự là ai. Lưu ý rằng trò chơi tương tự cũng có thể được chơi bằng các phương thức Agile - đó chỉ là thay đổi nhãn. Bất kỳ người quản lý nào tin rằng việc lựa chọn (và giữ) các thành viên phù hợp cho nhóm phát triển của mình ít quan trọng hơn quá trình phát triển, chắc chắn sẽ thất bại, bất kể quá trình đó xảy ra. Tuy nhiên, niềm tin vào Quy trình này dường như vẫn còn phổ biến - có lẽ nó vẫn được dạy trong các trường quản lý?

Một ví dụ thường xuyên của những người đi sai là mô hình thác nước. Đây là sơ đồ của mô hình thác nước rập khuôn, cũng xuất hiện trong bài báo "Quản lý sự phát triển của các hệ thống phần mềm lớn" của Winston Royce .

Hình ảnh này được theo sau bởi văn bản này:

Tôi tin vào khái niệm này, nhưng việc thực hiện được mô tả ở trên là rủi ro và mời thất bại ... Giai đoạn thử nghiệm xảy ra ở cuối chu kỳ phát triển là sự kiện đầu tiên mà thời gian, lưu trữ, đầu vào / đầu ra, chuyển giao, v.v., là những kinh nghiệm được phân biệt với phân tích. Những hiện tượng này không thể phân tích chính xác. Chúng không phải là giải pháp cho các phương trình vi phân từng phần tiêu chuẩn của vật lý toán học chẳng hạn. Tuy nhiên, nếu những hiện tượng này không thỏa mãn các ràng buộc bên ngoài khác nhau, thì việc thiết kế lại chính là bắt buộc. Một bản vá bát phân đơn giản hoặc làm lại một số mã bị cô lập sẽ không khắc phục được những khó khăn này. Các thay đổi thiết kế được yêu cầu có khả năng gây rối đến mức các yêu cầu phần mềm dựa trên thiết kế và cung cấp lý do cho mọi thứ đều bị vi phạm. Các yêu cầu phải được sửa đổi, hoặc một sự thay đổi đáng kể trong thiết kế là bắt buộc. Trong thực tế, quá trình phát triển đã trở lại nguồn gốc và người ta có thể mong đợi vượt quá 100 phần trăm trong lịch trình và / hoặc chi phí.

Sau đó, Royce trình bày các mô hình quy trình thay thế liên quan đến việc lặp lại giữa giai đoạn hiện tại và giai đoạn trước và một chu trình giữa thiết kế phân tích yêu cầu và một chu kỳ khác giữa thử nghiệm mã thiết kế. Ông cũng xác định một số tài liệu và trong đó các giai đoạn cần hoàn thành, và ủng hộ sự tham gia của khách hàng và nhiều thác nước trong mỗi giai đoạn để bao gồm phân tích, thử nghiệm và sử dụng tất cả các tạo tác liên quan. Trên thực tế, những gì Royce thảo luận có thể được coi là một cách tiếp cận sớm đối với các phương pháp nhanh - mặc dù vậy, vẫn còn rất nhiều kế hoạch, nhưng là cơ sở cho phong trào nhanh nhẹn.

Tại sao mọi người bám vào thác nước đầu tiên, tôi không biết. Tôi đoán họ thích chấp nhận rủi ro và mời thất bại.

Tạo mã tự động từ mức độ trừu tượng cao hơn hoặc lập trình tự động .

Bài viết trên Wikipedia có phần thiếu thông tin lịch sử, nhưng đây là giấc mơ của các nhà quản lý kể từ khi lập trình viên trở nên đắt hơn máy tính.

Sau khi phát triển các ngôn ngữ cấp cao hơn như Fortran và Cobol, đã phát triển các ngôn ngữ cho các lĩnh vực đặc biệt như viết báo cáo. Easytrieve và SAS là một vài ví dụ.

Trong những năm 1980, các công cụ CASE là cơn thịnh nộ. CASE là viết tắt của kỹ thuật phần mềm hỗ trợ máy tính. Người ta cho rằng việc áp dụng nghiêm ngặt các nguyên tắc kỹ thuật sẽ giúp phát triển phần mềm nhanh hơn. Lý do chính khiến các công cụ này không bắt kịp, ngoài chi phí, là mức độ tiêu chuẩn hóa dữ liệu cao cần thiết để các công cụ hoạt động hiệu quả.

Internet bắt đầu nổi tiếng vào những năm 1990. Các loại lập trình mà Internet tạo điều kiện bùng nổ. Các lập trình viên được yêu cầu xử lý các hình ảnh minh họa, bản đồ, hình ảnh và các hình ảnh khác, cộng với hoạt hình đơn giản, với tốc độ chưa từng thấy trước đây, với một vài phương pháp nổi tiếng. Số lượng công nghệ để sản xuất các đối tượng này nhân lên. Ước mơ lập trình tự động mờ dần.

Lập trình thuê ngoài đến các địa điểm rẻ hơn là một trong số ít các phương pháp còn lại để giảm chi phí lập trình viên. Các vấn đề với gia công bao gồm các vấn đề giao tiếp và các vấn đề đặc điểm kỹ thuật.

Phương pháp hình thức

Ngày xửa ngày xưa, người ta đã đề xuất rằng phần mềm có thể được chứng minh là đúng. (Ý tưởng là việc kiểm tra không thể cho thấy rằng không có lỗi, nhưng bằng chứng sẽ có thể xảy ra.) Thật không may, việc đưa ra một bằng chứng cho một chương trình có một số nhược điểm lớn:

• Nó khó khăn và tốn thời gian hơn so với việc viết chương trình.
• Nó phải bao gồm toàn bộ chương trình, nghĩa là bạn cần bằng chứng cho bất kỳ thư viện, HĐH, v.v ...
• Nó không chứng minh sự vắng mặt của bọ, vì những lỗi đó có thể là do tai nạn.

Khái niệm này rất phổ biến trong những năm 70.

Liên kết: http://en.wikipedia.org/wiki/F normal_methods http://c2.com/cgi/wiki?ProofOfC chính xác http://c2.com/cgi/wiki?PractitionersRejectFTHERMethods