作為一名程式員，小伙伴們有沒有想過這個簡單的問題，“軟體是什么？”可以閉上眼睛讓自己想一會，如果覺得有點抽象不太好回答的話，來看看我的答案，
軟體 = 程式 + 資料 + 檔案 + （服務）
程式 = 資料結構 + 演算法
看完這兩個直觀的公式，是不是有一種恍然大悟的感覺，“哦，原來這樣啊，”
再來看四條對“軟體”的定義，雖然比較枯燥，但概念是到位的：
- 軟體是能夠完成預定功能，達到預期性能的，可以執行的計算機指令；
- 軟體是能夠讓程式處理適當資訊的資料結構；
- 軟體是描述程式操作和使用的檔案；
- 軟體是一種邏輯物體，具備知識性的產品集合，是對物理世界的一種抽象，同時又是一種人腦智力的成果，
在很多自以為是的甲方眼里，軟體是廉價的，可以隨意復制的，因此他們經常提出一些苛刻的要求，其中有一些讓軟體開發者感到哭笑不得：“這個需求簡單的嘞，你去網上隨便找個現成的，改一改就好了呀，花不了多長時間的，一個月可以搞定吧？”每次聽到類似的話，我的心里就有一萬只草泥馬奔騰而過，
軟體開發并不是一件輕而易舉的事情，需要經歷下面這些基本程序：
1）軟體計劃，確定產品定位和目標用戶，這一步是需要甲方去規劃和調研的，
2）軟體需求分析：根據甲方需求，分析出甲方需要的產品功能，這一步是需要專案負責人（或者產品經理）去和甲方溝通的，
3）根據需求進行設計：包括概要設計和詳細設計，這一步是需要專案負責人（或產品經理）做的，并且要正確地傳達給開發人員，
4）編碼并運行，這一步是需要開發人員去做的，
5）測驗：確認甲方需求，對設計和結果進行驗證，開發人員要進行單元測驗，集成測驗，如果有專業的測驗團隊的話，就需要站在甲方和用戶的角度去測驗整體產品是否符合要求并達到性能要求，
6）維護：保證軟體能夠在正式環境下運行，并且對一些缺陷（bug）進行修正，或者對功能進行完善，或者對性能進行改進，不斷迭代軟體版本，
瞧，軟體開發的程序并沒有甲方想象中那么簡單，如果有小伙伴遇到不講理的甲方，就把這篇文章扔給他好好看看，
既然軟體開發的程序是有難度的，是需要付出時間和精力的，那就有必要遵循一些原則，否則開發成本就會變得很昂貴，開發周期就會拖延很長時間，
原則一： Don’t Repeat Yourself，
直譯叫做“不要重復你自己”，還有另外一個耳熟能詳的版本，“不要重復造輪子”，
在你一開始進入軟體開發這個領域后，就一定要注意，把你自己寫過的一些解決方案匯總到一起，定期梳理一遍，寫點檔案，不斷重構，使它們成為一把把瑞士軍刀，如果可以的話，把它們開源出來，服務更多的開發者，
有了自己的工具庫后，當你下次遇到類似的需求時，就可以直接拿出來用，省去不少時間，
除此之外，你還應該善于利用那些業界已經開源出來的成熟的技術方案，比如下面這些，
GitHub 和碼云是兩個充滿寶藏的地方，如果你覺得自己的能力還不到自己造輪子的份上，那就一定要多上上這兩個網站，里面有很多成熟的解決方案供你免費使用，
比如說，你要一套商城系統，那么 marcozheng 的 mall 就可以直接拿來作為原型，比如說，你要一套人事管理系統，那么江南一點雨的 vhr 就可以直接拿來作為原型，（雖然推薦了很多次，但好朋友的，多推薦一次不嫌多，）
原則二： Keep it simple stupid，
著名的 KISS 原則，即“保持簡單、保持愚蠢”，和史蒂夫·喬布斯的名言“stay hungry, stay foolish”有著異曲同工之妙，
從蘋果產品的設計上也可以體現出來這個原則，起初的手機，比如說諾基亞智能機，帶很多物體鍵，但蘋果只有一個 home 鍵，其他全部虛擬鍵代替，徹底革了諾基亞的命，
在我們設計軟體的程序中，千萬不要想得太復雜，越簡單越好，等成型了以后再豐富效果，否則開發成本會變得很昂貴，軟體就可以腹死胎中，
原則三： You Ain’t Gonna Need It，
英文直譯為“你不需要它”，該規則要求程式員在必要之前不應該添加功能，極限編程的聯合創始人羅恩·杰弗里斯（Ron Jeffries）曾經說過：“總是在實際需要時才實作事物，而不是在預見到需要它們時才實作，”
專案負責人（產品經理）更應該堅持這條原則，千萬不要過度拆解用戶的需求，在產品設計的程序追加過多自己認為應該追加的功能，因為在一個軟體使用中，往往 80% 的請求都花費在 20% 的功能上，
很多次要的功能可能需要，因為它們的存在而使軟體錦上添花，但沒有它們，軟體的商業價值依然是存在的，功能越少，開發周期就會越短，這樣就更有可能打敗競品，
原則四： Done is better than perfect，
Done is better than perfect because perfect is never done，
很簡單的一句英文，能理解吧？
不要總想著把所有的功能做完善，做完美后再上線，應該在產品具有一定的雛形后就立即上線試錯，根據用戶的反饋，根據市場的需求再去考量是否追加一些其他的功能或者優化，
“人無完人，金無足赤”，應該允許一些瑕疵存在，刻意追求完美并不見得是一件好事，喬布斯想要一整塊螢屏，但技術達不到的時候，他也是會留一個 home 鍵的，
我們程式員在開發軟體的時候，也應該遵循這條原則，先把功能做出來再說，至于效果，用戶的體驗，應該往后放，不要總想著盡善盡美，盡善盡美意味著永遠也完不成——沒有最好，只有更好，
原則五： Choose the most suitable things，
選擇最適合的，不要盲目追求時髦，技術日新月異，應接不暇，如果在開發軟體的時候，一味追求最前沿的技術，可能就會讓產品變成小白鼠，
就好像我們談一場戀愛，不要一味去追求高不可攀的，往往那些在我們身邊的，肯陪伴我們的才是最好的，
技術選型的時候，適合就好，如果產品的目標用戶只有一千人不到，就沒必要搞分布式，搞大資料，否則就有點“蛇吞象”的意味；等真到了需要搞分布式，搞大資料的時候再升級完全來得及，
最后，希望小伙伴們在軟體開發的程序中，能夠去遵循這 5 條原則，畢竟每天作業的時候可以多摸魚 4 個小時，
肝了三天三夜，《程式員不可或缺的軟實力》第一版強勢來襲，純手敲，足足 20 萬字精華文章，貫穿了我十余年的編程生涯，涉及到了生活和作業中的方方面面，如果你是迷茫的在校大學生，或者剛入職的新人，相信我的個人經歷，可以給你帶去一些思考，從而樹立起正確的人生觀和價值觀，
那這份 PDF 該怎么獲取呢？
鏈接:https://pan.baidu.com/s/1o6MY84my0OD0DHnAmZT6rA 密碼:tx5e
最后，真心希望這份 PDF 能夠對大家起到實質性的幫助，我也會在后面不斷完善這本電子書，敬請期待，
當然，也日常求個贊！
CSDN認證博客專家
博客之星
博客專家
Java 大牛
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/128085.html
標籤：其他
上一篇：使用 Source Insight 閱讀 Linux 內核原始碼
下一篇：ML之sklearn：sklearn.metrics中常用的函式引數(比如confusion_matrix等 )解釋及其用法說明之詳細攻略