? ? ? ? 這應(yīng)該是這次項目的總后一篇總結(jié)文章了溢吻，Winner Club作為三月演武堂成立來完成的第一個商業(yè)項目铆铆，于7月28日正式交付建车，項目組人員也在當(dāng)晚進行了總結(jié)。

? ? ? ? 下面是會議總結(jié)的要點：

? ? ? ? 1. 學(xué)長之后可能就不再參與代碼環(huán)節(jié)了裳凸。

? ? ? ? 確實這次學(xué)長參與了項目很多重要代碼部分贱鄙。比如小桑學(xué)長主要負責(zé)后端環(huán)境的搭建和一些比較難的接口的開發(fā)。騰飛學(xué)長負責(zé)了一些關(guān)鍵組件的開發(fā)姨谷。這幾天我從一些書中也了解到在客戶逗宁、項目負責(zé)人與程序員之間的分工，項目負責(zé)人正常來說是不負責(zé)代碼的開發(fā)的梦湘。不過有了第一次整體的流程和項目結(jié)構(gòu)瞎颗，我相信之后我們就可以步入正軌蹈胡。

? ? ? ? 2. 時間評估

????????一開始我與小桑學(xué)長定的后端接口時間就是一個星期咱揍，大體的開發(fā)速度基本上和我們規(guī)劃的一致，差不多用了6天就完成了第一版接口的開發(fā)礼华，雖然部分接口不完美并存在一定的bug翩伪，但是沒有影響春塌、耽誤前端的使用凳忙。但是前端方面確實時間評估上都有些失算疫赎，不過前端的難度也確實挺大的，因為界面要不斷的修改完善檬姥。

? ? ? ? 但是時間上的評估還是要精算（花一定的時間去計劃曾我、計算），否則一直延期是很不好的一件事穿铆。定的什么時間完成您单，就應(yīng)該在什么時間完成，為此我們還熬了一次夜荞雏。

? ? ? ? 3. 可交付的認(rèn)知程度? ? ? ??

????????我們以前做一個項目可能大多采用螺旋的開發(fā)模式，盡量為客戶出第一版平酿，項目整體的流程跑通凤优，可以有部分不致命的bug，但是這次學(xué)長對我們的要求是比較高的蜈彼，特別是對于前端筑辨，可以說是一直在改，一直在美化幸逆」髟可交付的狀態(tài)在我看來就是可以交付給甲方進行商用了，正常情況下前后端已經(jīng)是不能再出現(xiàn)bug了还绘。

????????所以要對自己的任務(wù)和整體的進度情況有清晰的認(rèn)識楚昭。

? ? ? ? 4. 不要總看自己那一塊，多交流拍顷，看總體

? ? ? ? 由于后端在后期都只由我一個人進行維護了抚太，所以后端交流的部分比較少，主要是前期和學(xué)長交流了一些參數(shù)格式和方法規(guī)范昔案，后端的總體后期也是我一個人把控了尿贫。小程序界面是3個人開發(fā)，他們的交流是遠多于我的踏揣，因為他們的頁面相互影響庆亡，可能需要其他人所做的組件等等，所以要不斷交流捞稿，我能做的就是在空余時間多去關(guān)注他們的進度又谋，看能否幫上什么忙钝尸。

? ? ? ? 關(guān)于看總體，我覺得前端的各個人員的進度要保證一致搂根，不能太快也不能太慢珍促，因為大多頁面之間互相影響，所以前端一定要保證進度的一致性剩愧，即看總體猪叙。

? ? ? ? 5. 需求文檔看仔細

? ? ? ? 這個問題前端、后端都有仁卷，一開始過文檔還是有些草率穴翩，部分情況沒有考慮清楚，就例如后端最嚴(yán)重的問題就是文件存儲的設(shè)計锦积，一開數(shù)據(jù)庫在這方面沒有設(shè)計好芒帕，導(dǎo)致后期影響了好多的表，而且目前更改過的還不好擴展丰介。前端的肯定也會有背蟆，但是更改起來相較于后端會輕松一些。

? ? ? ? 文檔如果沒有看仔細哮幢，可能會多些一些冗余功能或者少寫一些必要功能带膀，這其實都是小事，要避免對其他模塊的影響橙垢，和方便后期的擴展垛叨，反正看需求是十分重要的一個階段，這是毋庸置疑的柜某。

? ? ? ? 6. 代碼質(zhì)量

? ? ? ? 可能這里又會牽扯到好多小細節(jié)嗽元，例如規(guī)范、可擴展性喂击、可維護性剂癌、集成程度、耦合程度惭等、設(shè)計模式等等珍手。由于這是第一由兩個學(xué)長帶著做，所以代碼質(zhì)量這一關(guān)還是拿捏的死死的辞做。后端我是寫第一個接口十分謹(jǐn)慎琳要，寫完之后讓學(xué)長看規(guī)范邏輯等等，又改了好幾次后終于才算合格秤茅，之后的接口都要按著這個規(guī)范來稚补。

? ? ? ? 前端就更可怕，學(xué)長后期甚至把某一模塊的代碼全部重寫框喳，就是因為質(zhì)量课幕。前端還要將代碼組件化厦坛，意“即插即用”的設(shè)計思想。

? ? ? ? 總之功能不是實現(xiàn)了即可乍惊，要考慮諸多因素杜秸，這也就是為何技術(shù)越深反倒開發(fā)某一模塊的速度相對較滿（不絕對），因為要考慮的因素多润绎。

? ? ? ? 7. 不斷評估自己? ? ? ??

? ? ? ? 在做項目的時候可以反映出來自己的真實水平撬碟，借此也可以看出自己的不足，協(xié)作開發(fā)的時候也可以看出自己與他人的差距莉撇。那后端來說呢蛤，搭建環(huán)境這塊我確實比較弱，我需要吸收這次學(xué)長搭建的環(huán)境棍郎，相比學(xué)長的學(xué)習(xí)能力其障，我也是自愧不如。

? ? ? ? 所以涂佃，在做項目的同時励翼，也要不斷評估自己，對比他人來找到不足巡李。

? ? ? ? 8. 自己再封裝

? ? ? ? 別人寫的好的組件當(dāng)然可以拿來用，自己也可以對其再封裝侨拦，我覺得這也是對應(yīng)著java的三大特性辐宾。當(dāng)然在我看來也不是集成度越高越好狱从，能最優(yōu)化的方便自己和他人才是最好的封裝叠纹。

? ? ? ? 9. 可以將github上的開源框架拉下來季研，修改、提PR誉察。

? ? ? ? 其實之前我還真的不知道可以這樣子做，知道這次項目學(xué)習(xí)了git flow流程之后才恍然大悟持偏。學(xué)長同時也說如果自己代碼有合進去，這對之后的面試是非常加分的鸿秆，這不僅是對自己實力的認(rèn)可酌畜，也能反映出自己對代碼的理解與思考。

? ? ? ? 但是這一項對自身實力的要求還是非常的大的卿叽，所以還是要不斷提升自己才行桥胞。

? ? ? ? 10. 多看好的代碼

? ? ? ? 這一點很早之前學(xué)長就教導(dǎo)我們要看好的代碼，但是我們可能最多只能看個規(guī)范贩虾，因為大多數(shù)好的代碼以前根本看不懂其中的設(shè)計思想。目前我認(rèn)為我要做的就是先吸收兩個學(xué)長在項目中所貢獻的代碼伊群，先把自己的代碼質(zhì)量向兩個學(xué)長靠近。

? ? ? ? 11. 前端的分工

? ? ? ? 這一塊雖然這次我沒有參與前端的開發(fā)在岂，但是我也能感受到前端不好分工蛮寂。這次我和小桑學(xué)長在開發(fā)后端的時候蔽午，幾乎在代碼上是0沖突酬蹋，因為后端基本上都是面向接口開發(fā)，一個接口一個人骄恶，不同開發(fā)人員之間不參與他人編寫的接口匕垫，所以后端開發(fā)相對獨立。

? ? ? ? 但是前端這一塊我感覺無論是按頁面分工還是按功能分工象泵，都很有可能會造成兩個人、或多人參與一個頁面的制作偶惠，所以這次前端開發(fā)造成的沖突就非常的多，一定程度上也影響了整體的進度绑改。

? ? ? ? 讓我們來分析一下造成的原因無外乎就是大量的代碼堆積到了一個頁面中兄一。解決這種沖突的有效方法我認(rèn)為還是組件化開發(fā)，一個組件僅由一個人開發(fā)瘾腰，頁面只是一個容器皆的，去引用這些組件蹋盆。

? ? ? ? 通俗的來說就是硝全，把一個頁面分成view合component楞抡，view就像一個無限長的排插，component就是一個個的電器召廷，他們就像是一個個的component連接/插到了view上一樣，view的代碼量很少先紫，便于維護筹煮，而component僅由一個人開發(fā)，避免了沖突败潦。所以說還是這種即插即用的思想本冲，極大的降低了耦合劫扒，減少了沖突的出現(xiàn)。

? ? ? ? 有關(guān)前端的設(shè)計模式合代碼結(jié)構(gòu)還有待細細挖掘添怔。

? ? ? ? 12. 遇到問題的解決思路

? ? ? ? 我個人覺得我自己面臨問題時解決流程還是比較清晰的贤旷，如果我自己的代碼出了bug澎灸，首先看控制臺輸出定位代碼遮晚，再思考邏輯拦止。還沒有解決就開始調(diào)試，一步步定位問題汹族。還不行就把錯誤復(fù)制放到百度上查，如果最后還沒有解決就得問其他人了夸政。

? ? ? ? 學(xué)長建議的解決思路和這個差不多榴徐，不過在百度上查之前應(yīng)該再加上兩個流程匀归，一個是看官方文檔耗帕，看看是不是方法要求參數(shù)沒有看仔細，哪里的調(diào)用邏輯或是配置有誤仿便，如果還是沒有幫助再去所使用框架的社區(qū)或是對應(yīng)問題的相關(guān)社區(qū)搜尋答案，最后再在百度上搜索（主要還是因為百度上的答案太雜荒勇，真正有效的并不多）闻坚。

? ? ? ? 13. 后端api要先開發(fā)出來

? ? ? ? 這個又和我以前的認(rèn)知大相徑庭沽翔。學(xué)長說接口要一開始和前端溝通好鲤氢，例如商量要寫什么接口，這些接口要有什么參數(shù)哨颂，要先把接口定好相种，并讓前端review，之后可能就不會在接口上出現(xiàn)協(xié)商不一致的情況了寝并。

? ? ? ? 而我現(xiàn)在開發(fā)接口就是自己先寫，前端發(fā)現(xiàn)缺什么接口和說參數(shù)我再補再改斤蔓，現(xiàn)在看來確實很不規(guī)范镀岛。? ? ?

? ? ? ? 這也就是為什么造成項目delay的原因大多數(shù)情況下并不是因為個人自身的能力問題，而是一開始前后端協(xié)商不一致導(dǎo)致后期的大改漂羊。

? ? ? ? 14. 聯(lián)調(diào)

????????我認(rèn)為聯(lián)調(diào)不應(yīng)該集中到一個時間點整體聯(lián)調(diào)，聯(lián)調(diào)應(yīng)該放在平時椭豫，小規(guī)模的聯(lián)調(diào)可以在平時就發(fā)現(xiàn)彼此之間的問題。如果所有模塊都堆在一起集中聯(lián)調(diào)赏酥，有bug基本上是100%的，而且還有可能因為某些前置bug導(dǎo)致某些隱藏的bug無法發(fā)現(xiàn)算柳，進而導(dǎo)致下一次集體聯(lián)調(diào)又出現(xiàn)bug姓言。

? ? ? ? 15.?卓越的工程師

? ? ? ? 一個卓越的工程師不僅是技能過硬，同時也要能夠把控總體何荚。我認(rèn)為前端這次缺少的就是一個能夠把控整體的人，缺少一個可以做領(lǐng)頭羊的人妥衣。一個卓越的工程師在自己模塊開發(fā)過程中，要不斷聯(lián)系項目組的其他成員税手，統(tǒng)計進度需纳、做總結(jié)，及時發(fā)現(xiàn)問題不翩、更改計劃等等，簡而言之就是開發(fā)組的組長器钟。

? ? ? ? 16. 做一個靠譜的人

????????這也是學(xué)長最后一直強調(diào)的事情——做一個靠譜的人妙蔗。這可能要從多方面考慮，首先在項目進度上不能掉鏈子眉反，自己的模塊不能出問題影響整體。其次自己要對自己的代碼負責(zé)，就像上面說的代碼質(zhì)量孵睬，不能做出結(jié)果就完事了，不僅自己要便于維護秘狞，以后也要讓他人便于維護。如果自己的模塊真的出問題了也要能快速反映想到問題所在并及時解決烁试，這一點前端后端都要具備。

? ? ? ? 最后靖诗，還是騰飛學(xué)長的那句話：以目標(biāo)為導(dǎo)向支示，承諾即交付。

? ? ? ? 不是面向需求開發(fā)颂鸿，而是面向需求變更開發(fā)。（玉寶學(xué)長）