在沒有體驗過一整個軟件開發(fā)過程并參與其中的工程師是很難說自己是一個合格全棧工程師或者說是獨立開發(fā)者的。在工作了整整四年后，我可以說我已經(jīng)是一個合格的獨立開發(fā)者了。這其中踩過了無數(shù)的坑，也付出了很多精力去解決這些問題。

在各個群里面，其實我也遇見了很多覺得自己很厲害的php工程師或者nodejs工程師，覺得自己能夠?qū)懀ˋpp，Web，Backend，Desktop）當中任意排列組合的兩三個后就會覺得自己很厲害，覺得自己是一個全棧工程師了，并且也被很多不明覺厲的小白稱贊兩句，哇好厲害。

然，php5。With all my respect, well, I allege that you guys thoroughly suck.

私以為一個完整且健壯的產(chǎn)品是應該涵蓋以下八個方面的：

• 規(guī)劃
• 設計
• 代碼
• 測試
• CI/CD
• 溝通
• 交付
• 貢獻

規(guī)劃

我們并不是大師，但是我們是一群為了理想而奮斗終身的敏捷武士，我們堅持精益的理念：通過不斷的學習和有價值的用戶反饋，對產(chǎn)品進行快速迭代優(yōu)化。

在項目開始之初，就需要對整個項目所涉及的行業(yè)有一個大概的了解，也需要去了解一些專有名詞，并熟記于心。不同的行業(yè)可以共用很多模塊，但是在細節(jié)的處理上就能夠體現(xiàn)出一個優(yōu)秀的程序員所具備的素質(zhì)。
這個階段最重要的角色并不是Programmer而是一個Planner，在這里你需要給User和Client講故事，并把寫好的故事做成一個Storyboard，然后讓Client以及User自己挑選符合自己口味的Story以及Timeline，沒錯，就是讓User和Client演繹自己的故事。與此同時，你需要根據(jù)你的經(jīng)驗并且用“恰當”的方式去引導他們的觀點，我把“恰當”拿出來單獨講是因為很多時候，一個Planner的角色是由產(chǎn)品經(jīng)理或者項目經(jīng)理去擔當?shù)?，但是作為一個全棧的程序員，這里就要求不要把自己的角色固定住。只是覺得自己是一個程序員，而不去思考產(chǎn)品的本身是對與錯，在任何時候，用“恰當”的方式去據(jù)理力爭是卓有成效的，但也不要盲目的更具自己的經(jīng)驗去據(jù)理力爭，你需要去了解這個矛盾背后產(chǎn)生的原因，這需要調(diào)查，收集一些信息，不能盲目的下結(jié)論。
實踐是檢驗真理的唯一標準。

設計

很遺憾，我不是設計師，但是我見過太多設計師了。
我依舊不能設計出一款好看的產(chǎn)品。
其實很多工科生的審美是奇怪的，特指做出來的東西，他們的愛好可能很文藝很清新，或是很有藝術細胞，那么為什么做出來的東西會一塌糊涂呢，這個也是我反思了很久的問題，究其原因我覺得應該是我把很多固有的思維生搬硬套進來，然后做出了一個四不像，盡管能夠從各種渠道去怎么完成一個效果，但是由于缺乏專業(yè)人士的指導，所以做出來的東西往往是更符合自己的審美，但卻不是一個普遍美觀的產(chǎn)品。
在推薦使用Sketch以及一些設計協(xié)作相關的產(chǎn)品搭配使用。

代碼

在交付軟件的過程中，代碼其實只是其中的一個小環(huán)節(jié)，說到底就是把你解決掉問題的方法翻譯成電腦能夠理解出來的語言。
而如何Ship Better Code呢？
需要考慮很多邊界條件？沒錯。
需要寫更優(yōu)雅的代碼？沒錯。
需要動腦？沒錯。
在寫代碼之前，你要思考這樣寫是不是很"得體"，如果你用了很多層很多次循環(huán)反復繞自己，那么你完了，也不要噴別人的代碼差了，反思一下自己。
常言道，三思而后行，代碼本身并不是一個體力活，一味的堆砌一些shit code并沒有什么作用，就是傳說中屎糊的代碼；作為一個腦力勞動，寫出來的每一行代碼都是需要提現(xiàn)出自己思考的價值的。

測試

測試其實是一個老生常談的問題，無論是從Unit Test到Integration Test還是到Acceptance Test，從任何一個地方增加測試都可以讓你更有信心的寫代碼以及方便的修改代碼，因為測試結(jié)果會告訴你，Everything is under control。

很多人一開始會偷懶不寫測試，只是一個很小的功能，或者說不知道如何去寫一個測試，我就是這樣的，隨著項目的code base增大，你每一次很小的修改都會帶來不知道會發(fā)生什么的結(jié)果，比如程序崩潰，比如少了一個值等。這些都可以通過測試來給你解決掉。

這些比單純地調(diào)用Postman查看結(jié)果會更加的優(yōu)秀，代碼可以使你更加自由的組合你需要的測試工具，比如每次測試完你都需要clean database，在某一個模塊面前，你需要mock一些數(shù)據(jù)，或者stub一些第三方的返回。

CI/CD

如果說在上一部分是讓你更加自信的寫，修改代碼，那在這一塊就是讓你更加自信的交付代碼，可以保證軟件在各種各樣的環(huán)境下面盡可能的統(tǒng)一起來。通過Git加上一些CI/CD工具就可以很方便的設置起來，可以減少很大一部分的手工勞動，9102年了，大家可以嘗試一下Git配套的CI/CD服務了。

Coding.net

無論是Github，Coding，BItbucket這些提供Git服務的供公司，其實都會提供配套的持續(xù)集成服務，畢竟代碼不能跑起來就是一坨代碼，而不是一個產(chǎn)品而已，而一個好的產(chǎn)品是需要不停的打磨的，與此同時持續(xù)集成顯得尤為重要。

BTW，推薦閱讀
GitHub 為什么免費了

溝通

溝通貫穿始終，無論是項目開始之初，亦或是開發(fā)正在進行時，舉個例子，作為開發(fā)，你需要和產(chǎn)品，設計，測試等角色溝通，而作為設計師，也同樣需要和各個角色溝通。

image.png

所以大家在這張強連通圖里面，更多時候是需要扮演各種各樣的角色，去交流，而不是Play your part well就夠了。

交付

生產(chǎn)從第一天就開始了。從第一天寫下第一行代碼開始，我們就把軟件看作了已經(jīng)投產(chǎn)，而不是遙遠的明天。通過持續(xù)集成，保證我們交付的代碼已經(jīng)生產(chǎn)就緒。

參考

• 測試
• 代碼
• CI/CD

貢獻

Last but not least，分享你所學會的并且教會別人也是一件值得肯定的事情，在教的過程中也是在學習的過程，賣視頻，賣課程是可恥的，如果有心，知識是不需要付費的。
在分享之前，你需要對自己的knowledge base進行梳理歸檔，然后把它們寫下來，再進行分享，這樣對于自己所掌握的知識是一個很好的復習與鞏固。

最后

語言不是相通的，Lisp的代碼與Java的代碼看起來也是截然不同的，背后所體現(xiàn)的思想也是截然不同的，也許他們沒有好壞之分，但是你一個英語都學不好的人和我來說語言是相通的。

Go home