在沒有體驗過一整個軟體開發過程並參與其中的工程師是很難說自己是一個合格全棧工程師或者說是獨立開發者的。在工作了整整四年後，我可以說我已經是一個合格的獨立開發者了。這其中踩過了無數的坑，也付出了很多精力去解決這些問題。
在各個群裡面，其實我也遇見了很多覺得自己很厲害的php工程師或者nodejs工程師，覺得自己能夠寫（App，Web，Backend，Desktop）當中任意排列組合的兩三個後就會覺得自己很厲害，覺得自己是一個全棧工程師了，並且也被很多不明覺厲的小白稱讚兩句，哇好厲害。
然，php5。With all my respect, well, I allege that you guys thoroughly suck.
私以為一個完整且健壯的產品是應該涵蓋以下八個方面的：
- 規劃
- 設計
- 程式碼
- 測試
- CI/CD
- 溝通
- 交付
- 貢獻
規劃
我們並不是大師，但是我們是一群為了理想而奮鬥終身的敏捷武士，我們堅持精益的理念：通過不斷的學習和有價值的使用者反饋，對產品進行快速迭代優化。
在專案開始之初，就需要對整個專案所涉及的行業有一個大概的瞭解，也需要去了解一些專有名詞，並熟記於心。不同的行業可以共用很多模組，但是在細節的處理上就能夠體現出一個優秀的程式設計師所具備的素質。 這個階段最重要的角色並不是Programmer而是一個Planner，在這裡你需要給User和Client講故事，並把寫好的故事做成一個Storyboard，然後讓Client以及User自己挑選符合自己口味的Story以及Timeline，沒錯，就是讓User和Client演繹自己的故事。與此同時，你需要根據你的經驗並且用“恰當”的方式去引導他們的觀點，我把“恰當”拿出來單獨講是因為很多時候，一個Planner的角色是由產品經理或者專案經理去擔當的，但是作為一個全棧的程式設計師，這裡就要求不要把自己的角色固定住。只是覺得自己是一個程式設計師，而不去思考產品的本身是對與錯，在任何時候，用“恰當”的方式去據理力爭是卓有成效的，但也不要盲目的更具自己的經驗去據理力爭，你需要去了解這個矛盾背後產生的原因，這需要調查，收集一些資訊，不能盲目的下結論。 實踐是檢驗真理的唯一標準。
設計
很遺憾，我不是設計師，但是我見過太多設計師了。 我依舊不能設計出一款好看的產品。 其實很多工科生的審美是奇怪的，特指做出來的東西，他們的愛好可能很文藝很清新，或是很有藝術細胞，那麼為什麼做出來的東西會一塌糊塗呢，這個也是我反思了很久的問題，究其原因我覺得應該是我把很多固有的思維生搬硬套進來，然後做出了一個四不像，儘管能夠從各種渠道去怎麼完成一個效果，但是由於缺乏專業人士的指導，所以做出來的東西往往是更符合自己的審美，但卻不是一個普遍美觀的產品。 在推薦使用Sketch以及一些設計協作相關的產品搭配使用。
程式碼
在交付軟體的過程中，程式碼其實只是其中的一個小環節，說到底就是把你解決掉問題的方法翻譯成電腦能夠理解出來的語言。 而如何Ship Better Code呢？ 需要考慮很多邊界條件？沒錯。 需要寫更優雅的程式碼？沒錯。 需要動腦？沒錯。 在寫程式碼之前，你要思考這樣寫是不是很"得體"，如果你用了很多層很多次迴圈反覆繞自己，那麼你完了，也不要噴別人的程式碼差了，反思一下自己。 常言道，三思而後行，程式碼本身並不是一個體力活，一味的堆砌一些shit code並沒有什麼作用，就是傳說中屎糊的程式碼；作為一個腦力勞動，寫出來的每一行程式碼都是需要提現出自己思考的價值的。
測試
測試其實是一個老生常談的問題，無論是從Unit Test到Integration Test還是到Acceptance Test，從任何一個地方增加測試都可以讓你更有信心的寫程式碼以及方便的修改程式碼，因為測試結果會告訴你，Everything is under control。
很多人一開始會偷懶不寫測試，只是一個很小的功能，或者說不知道如何去寫一個測試，我就是這樣的，隨著專案的code base增大，你每一次很小的修改都會帶來不知道會發生什麼的結果，比如程式崩潰，比如少了一個值等。這些都可以通過測試來給你解決掉。
這些比單純地呼叫Postman檢視結果會更加的優秀，程式碼可以使你更加自由的組合你需要的測試工具，比如每次測試完你都需要clean database，在某一個模組面前，你需要mock一些資料，或者stub一些第三方的返回。
CI/CD
如果說在上一部分是讓你更加自信的寫，修改程式碼，那在這一塊就是讓你更加自信的交付程式碼，可以保證軟體在各種各樣的環境下面儘可能的統一起來。通過Git加上一些CI/CD工具就可以很方便的設定起來，可以減少很大一部分的手工勞動，9102年了，大家可以嘗試一下Git配套的CI/CD服務了。
BTW，推薦閱讀 GitHub 為什麼免費了
溝通
溝通貫穿始終，無論是專案開始之初，亦或是開發正在進行時，舉個例子，作為開發，你需要和產品，設計，測試等角色溝通，而作為設計師，也同樣需要和各個角色溝通。
交付
生產從第一天就開始了。從第一天寫下第一行程式碼開始，我們就把軟體看作了已經投產，而不是遙遠的明天。通過持續整合，保證我們交付的程式碼已經生產就緒。
參考
- 測試
- 程式碼
- CI/CD
貢獻
Last but not least，分享你所學會的並且教會別人也是一件值得肯定的事情，在教的過程中也是在學習的過程，賣視訊，賣課程是可恥的，如果有心，知識是不需要付費的。 在分享之前，你需要對自己的knowledge base進行梳理歸檔，然後把它們寫下來，再進行分享，這樣對於自己所掌握的知識是一個很好的複習與鞏固。
最後
語言不是想通的，Lisp的程式碼與Java的程式碼看起來也是截然不同的，背後所體現的思想也是截然不同的，也許他們沒有好壞之分，但是你一個英語都學不好的人和我來說語言是相通的。
