吐槽
一年前我跳槽來到現在所在的這家公司的時候，其實是帶著滿滿的期望以及boss對未來發展的承諾，但是事到如今，我卻是一腔的不滿，一身的疲憊。回顧從業3年來，大大小小的專案也做了一些，但是除了剛開始的小專案做的比較順利之外，後來的專案沒有幾個是成功的。當然這肯定要歸咎於自身的無知和不知上進，然後另外的小部分的原因實在是公司對於軟體過程的無知和放任。
自從離開第一家公司之後，我覺得自己再沒有技術上的重大突破。其一是平時積累學習太少，其次是公司沒能在技術上給予規範和發展的支援，這點可能很多公司都是這樣，boss的關注點不會在於軟體的實現過程，他更關心結果。作為一個開發者或者說專案的實施者來說，我覺得軟體過程比軟體結果更重要，這將直接導致一個軟體的質量，以及它能否作為一個產品而存在。
我所理解的軟體過程
這裡的軟體過程，指的是需求、設計、開發到實施上線，大部分小公司對這些過程都是沒有明確分工的。這也直接導致了專案管理的混亂，造成專案質量和風險的不可控。在日常的工作學習中，我對軟體過程形成了自己的理解，可以概括為需求詳細、設計明確、開發保質保量、計劃實施。那麼這四點立足於我的工作又該如何展開？
需求詳細
這四個字的意思，其實不需要過多解釋，就是一份詳細的需求文件。然而開發人員這麼簡單的訴求，往往很難得到滿足，為什麼？首先，需要去追究專案經理的責任問題。專案需求作為一個專案的根基和功能依據，它的存在是必要而不是可要的。如果沒有一分詳細的需求去確定我們們的產品的需求（功能）邊界，那麼產品如何實現？閉門造車式的空想，屁股決定腦袋式的拍板...這些大概都太常見了，正因為如此造成了一個專案開發人員無從下手，甚至今天做了這個功能明天就不知道做什麼功能了。我遇到一個專案經理竟然跟我們說“這個星期我都不知道做什麼”，我去了，真是讓小夥伴們驚呆了。其次，我們們要來看一份簡單的需求，只包含了蜻蜓點水的功能概述。這樣的需求，無論是誰都沒法做到對接下來要做的內容瞭然於胸了，這樣的情況不得不讓我們的開發反覆的在開發時去重新明確需求，這是何等的浪費時間！所以，一份詳細的需求文件，應該包含了對業務的分析，以及功能的詳細描述為系統設計框定邊界。
設計明確
詳細的需求面前設計人員應該站在系統的實現角度，用開發的角度去設計系統，大到硬體方案，小到每個程式碼模組的介面設計，都應該做到明明白白。這點我覺得不是浪費時間，因為好的設計是對後面開發的一種規範和約定，在沒有任何約束的開發狀態下，必然導致了反覆的重構，冗餘的程式碼和沒有效率的功能實現。試想如果拿到需求我們們就進去模組開發，逐個功能進行開發，一個人開發還好，如果是2個、3個甚至更多，那麼大家的程式碼必定缺乏統一性，我們的開發效率和系統的效率如何保證。不斷的回頭改程式碼的經歷我想大部分開發都經歷過，多麼痛的覺悟！！
開發保質保量
說到開發實在是要吐槽一番，我也是開發，但是首先吐槽的是自己有點懶。測試用例總是不高興寫完整，前期拖拖拉拉後期加班加點，質量得不到保證不說，弄的自己身心俱疲。不過公司沒有對開發作出規範和約束也是造成這種現狀的原因之一。開發和測試是並行的，雖然大公司都是不同的人分開並行的，但是我想一般的都是開發自己在做。不過單元測試確實是開發的職責了，如何在開發開始階段就更進測試環境的搭建，測試用例的梳理和安排，這些都是後期開發質量的保證。如果都在前期做了很好的安排和計劃，那麼程式猿們，我們們按照計劃來進行還會加班麼？當然boss總是不會讓我們好過，壓縮下開發時間也是常事，不過良好的計劃依然是開發階段需要保證的，這樣能有質量的保證。
計劃實施
這個點跟我們計劃生育一樣，要計劃好了，出生前營養充分忙前忙後，要出生了自然不能鬆解了。在實施上線之前，務必要所有人進行確認，確保需求得到了實現，以及所有的肯能風險和意外都是有對策的。否則出了差錯我想又是要苦逼的團團轉了。不過這裡我想要說，錯誤日誌和郵件提醒真的很重要啊，實施上線了以後誰每個日誌，誰不是每天看郵件...難不成還拿資料來debug下麼？
Summary
對於以上的理解，可能在大公司的成員來看真的是小菜，然後對於眾多中小型的開發公司來說，我想誰參與誰明白了。軟體像種糧食，沒有很好的過程保證，那麼還會有豐收季麼？