軟件/服務發展的一般過程（例如，將軟件從版本1.0發展到版本2.0）

Question

我是一名研究生，學習計算機科學，在建立實際行業的軟件或服務方面經驗不足。所以，我只知道軟件或服務如何表面化的理想過程，這是軟件工程類中介紹的。

因此，我不知道在軟件進化過程中發生的REAL過程。

例如，假設有一個成功的SW，其版本是1.3，管理人員決定用一些新的真棒功能開發2.0版本。那麼，開發團隊通常會遵循什麼程序？通常情況下，需求 - >架構 - >詳細設計 - >代碼？或者開始複製版本1.3的代碼並找到可重用的部分？我想知道公司如何開發下一個主要版本的SW。

感謝您的回答，提前。我會繼續看這個帖子，所以如果你想澄清我的問題，請問。我會修改我的問題。

Answer 1

從我作爲自由職業開發人員的經歷來看，我認爲在'現實生活'中，這個過程遠遠沒有那麼明確，但往往或多或少是一個持續一半的組織。另一半則有點混亂。約，它是這樣的：

1. 一套新的需求定義 - 從客戶的要求或由於其他外部因素（例如像新的操作系統版本，新的法律規定或類似的...）或者始發。這些都在規範文檔中列出，這是大多數軟件項目所見過的唯一文檔 - 如果有的話。即使這樣做通常也是一種紙張浪費 - 通常在實踐中實現功能的實現往往是無證的臨時基礎。
2. 然後，這些功能將隨着時間的推移組裝到項目源存儲庫的新分支中。 （你可以把這種新的分支的原代碼複製如果你絕對想要的。但是，這是不常見，通常它只是叫新的分支）。通常情況下，使用每個功能分支方法，其中每新功能在新分支中實現，然後直接將其合併回主產品分支或主新版本分支。第一種「方法」（實際上，它是一種混亂的方式，儘可能快地將功能帶出門戶），這導致了持續不斷的新功能流，通常用於網站和公司內部軟件 - 兩者都很容易更新。
3. 體系結構部分也大多發生在臨時的基礎上，一旦軟件的第一個版本出貨並且代碼庫的最大部分已經在那裏。作爲一名開發人員（特別是當您剛剛接觸該項目時），嘗試在實現新功能時儘可能少地觸摸原始代碼庫（以避免副作用）。當然，你有計劃去做什麼，但是你肯定沒有時間做'詳細設計'文件。 - 你爲什麼？無論如何，沒有人會對它們感興趣，而且這種類型的文檔在編碼開始後的10秒內往往會過時。所以他們通常被認爲是無用的浪費時間。實際上，代碼（也可能是隨附的測試套件）是設計文檔。
4. 通常，項目有某種截止日期。此時，負責人將查看新實現和批准功能的概述，然後確定可以向新版本提供哪些版本號。 - 許多持續工作的項目根本沒有版本號。他們使用RTM的日期（有時甚至是時間！）來達到這個目的。

一些積分：

• 有可能是公司裏，這個過程更有條理，甚至作品！但這通常伴隨着很多管理，很多文書工作和許多會議 - 大多數公司根本承受不起這個。根據我的經驗，在許多小公司中，這個過程有很大一部分是混亂的，大大超過了「現實生活」中的「專業」。
• 大多數軟件由相應公司在內部使用 - 例如，內部CRM，庫存管理軟件或機器轉向軟件。當公司內部不需要它時，軟件通常是更大產品的一部分，例如汽車中的引擎轉向程序或某種硬件的UI。這個星球上的一小部分軟件真的打算作爲獨立產品銷售。我猜想這個百分比遠低於5％。
• 已有軟件的大型重寫/重構極少發生。 - 大多數開發人員在他們的職業生涯中甚至不會看到這種情況。
• 大約75％的工作年限，軟件開發人員根本就不參與新項目，而是擔心某些維護活動！
• 特別是詳細設計實際上很少發生。它被大多數開發人員認爲是毫無意義的浪費，並且在編程世界（敏捷軟件開發）中有一個強大的，非常受歡迎的，廣受好評的運動，支持這種觀點。