今天突發(fā)奇想決定開(kāi)一個(gè)文集把最近負(fù)責(zé)的項(xiàng)目進(jìn)行的整個(gè)過(guò)程記錄下來(lái)，主要記錄在跟需求時(shí)學(xué)到的東西，寫代碼遇到的問(wèn)題以及解決的方法，也會(huì)寫一點(diǎn)小功能點(diǎn)的代碼。
近期跟的這個(gè)項(xiàng)目比較大一點(diǎn)，遇到的問(wèn)題也更多，寫這些主要是幫助自己回顧總結(jié)以及進(jìn)步。
需求
經(jīng)過(guò)這次項(xiàng)目總結(jié)出了幾點(diǎn)
- 前期一定要頻繁的溝通開(kāi)會(huì)，這樣不僅僅不會(huì)浪費(fèi)時(shí)間，而且會(huì)很大程度上避免返工和減少bug。一定要不厭其煩的和他們溝通，確保每個(gè)人都對(duì)自己的模塊很了解。
- 文檔，一定要寫文檔，文檔很重要。需求一定要寫文檔發(fā)郵件，接口也必須要有接口文檔。
- 和甲方討論需求之前自己一定要理清楚需求，對(duì)于理不清楚的需求自己要先想出幾個(gè)可能的點(diǎn)和處理方式，不然到時(shí)候就會(huì)被甲方帶跑偏，說(shuō)不定還加了一堆工作量。
分工
- 給組員分工作的時(shí)候，自己要對(duì)組員有足夠的了解，這樣才會(huì)效率最大化。
- 自己要對(duì)需求足夠了解，這個(gè)時(shí)候懂后臺(tái)開(kāi)發(fā)就很有利了，大致能知道這個(gè)模塊是否很難搞定，對(duì)工作量的把握很有用
開(kāi)發(fā)
- 平臺(tái)架構(gòu)搭建，這個(gè)代碼最好只由一個(gè)人動(dòng)，省的平臺(tái)改的亂七八糟。其他組員可以在分支進(jìn)行迭代，由負(fù)責(zé)人有選擇的進(jìn)行merge
- 每周或者每?jī)芍芏家徒M員一起進(jìn)行代碼review，不然你永遠(yuǎn)不知道他們寫的是什么樣子
測(cè)試
- 先單個(gè)功能點(diǎn)進(jìn)行測(cè)試，測(cè)試到不再報(bào)錯(cuò)，頁(yè)面樣式調(diào)整的最好看，然后再單個(gè)模塊進(jìn)行測(cè)試，最后整個(gè)流程進(jìn)行測(cè)試。整體測(cè)試主要就是看數(shù)據(jù)是否對(duì)的上
- 測(cè)試發(fā)現(xiàn)的問(wèn)題，只要是覺(jué)得有一點(diǎn)點(diǎn)不爽的，都要全部改。因?yàn)槟阋粋€(gè)程序員一個(gè)對(duì)自己寫的東西很寬容的人都覺(jué)得不爽了，那客戶的感想可想而知，可能就是把你的不爽放大100倍吧。
- 細(xì)心細(xì)心細(xì)心真的很重要，往往你不在意的點(diǎn)可能就有問(wèn)題
最后
一定要有耐心，不能發(fā)火，因?yàn)榘l(fā)火根本沒(méi)有卵用
目前就想到這么多，暫時(shí)寫這么多吧。
