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

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

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

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

• 規(guī)劃
• 設(shè)計(jì)
• 代碼
• 測(cè)試
• CI/CD
• 溝通
• 交付
• 貢獻(xiàn)

規(guī)劃

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

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

設(shè)計(jì)

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

代碼

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

測(cè)試

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

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

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

CI/CD

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

Coding.net

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

BTW，推薦閱讀
GitHub 為什么免費(fèi)了

溝通

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

image.png

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

交付

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

參考

• 測(cè)試
• 代碼
• CI/CD

貢獻(xiàn)

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

最后

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

Go home