簡(jiǎn)單談?wù)勯_(kāi)發(fā)流程和管理中幾個(gè)一般性的原則。

?

1.? 前松后緊原則
??? 做事情有時(shí)候真的要看好方向。方向錯(cuò)了，會(huì)嚴(yán)重影響項(xiàng)目進(jìn)度和投入產(chǎn)出比，你努力工作的成果也許幾乎無(wú)用，這也是很多項(xiàng)目失敗的根本原因之一。所以，負(fù)責(zé)任的PM們總是小心翼翼地反復(fù)評(píng)審著需求文檔和設(shè)計(jì)文檔，因?yàn)檫@是項(xiàng)目或產(chǎn)品成型的前提，是開(kāi)發(fā)的最原始驅(qū)動(dòng)力。從項(xiàng)目時(shí)間分配的角度來(lái)講，這就存在一個(gè)前松后緊原則。多預(yù)留點(diǎn)時(shí)間在此處要害，總比做完了又推翻來(lái)得有余地。不愿意花功夫在這上面，早晚必自食惡果。
??? 由此也衍生出來(lái)一個(gè)架構(gòu)設(shè)計(jì)的行當(dāng)，它完成系統(tǒng)和平臺(tái)選型、總體方案設(shè)計(jì)、關(guān)鍵業(yè)務(wù)邏輯分析和風(fēng)險(xiǎn)點(diǎn)評(píng)估等重方向的工作。然而架構(gòu)設(shè)計(jì)不是憑空而來(lái)的，它需要長(zhǎng)期產(chǎn)品優(yōu)化和改進(jìn)積累起來(lái)的寶貴經(jīng)驗(yàn)，需要迅速搭建模型驗(yàn)證方案關(guān)鍵技術(shù)的實(shí)施能力。所以一般來(lái)講，優(yōu)秀的架構(gòu)師首先是優(yōu)秀的產(chǎn)品優(yōu)化人員。沒(méi)有做過(guò)系統(tǒng)的性能優(yōu)化，你都不好意思說(shuō)你是架構(gòu)師。

?

2.? 分離原則
??? 談到性能調(diào)優(yōu)，首先要重視程序結(jié)構(gòu)和業(yè)務(wù)邏輯，其次才是程序細(xì)節(jié)。如果程序的架構(gòu)都有問(wèn)題，優(yōu)化不知從何談起。
??? Daemon進(jìn)程是一種比較普遍的設(shè)計(jì)，但是也會(huì)帶來(lái)一些隱患，比如內(nèi)存泄露的話(huà)就會(huì)一直泄露，直到系統(tǒng)內(nèi)存耗盡。解決的辦法之一是分解daemon程序，只將監(jiān)聽(tīng)和接收部分留下，繁雜的具體業(yè)務(wù)處理另由其它程序處理，只在需要時(shí)才調(diào)用它，用完了馬上銷(xiāo)毀。這是通常說(shuō)的分離原則應(yīng)用場(chǎng)景之一。
??? 還有一個(gè)結(jié)構(gòu)性的問(wèn)題也應(yīng)重視，那就是主機(jī)的應(yīng)用種類(lèi)。應(yīng)用不同，決定了性能調(diào)整的方向不同；而對(duì)于不同的調(diào)整方向，調(diào)優(yōu)使用的方法和工具也可能大不相同。比較常見(jiàn)的有兩種典型應(yīng)用，服務(wù)器（server）型和終端（terminal）型。不要迷惑于某些優(yōu)秀的工具為什么你一直用不上，也許你的環(huán)境和資源本就不允許。
??? 回到研發(fā)流程管理方面來(lái)說(shuō)，一般的IT研發(fā)過(guò)程是：需求分析-系統(tǒng)設(shè)計(jì)-詳細(xì)設(shè)計(jì)-編程實(shí)現(xiàn)-單元測(cè)試-集成測(cè)試-交付使用-產(chǎn)品服務(wù)，再加上編程設(shè)計(jì)與測(cè)試的反復(fù)迭代。很顯然，研發(fā)流程的按步就班本身就是分離原則的一種體現(xiàn)。對(duì)某些關(guān)鍵步驟的再分解，細(xì)化一些業(yè)務(wù)和分工，跳開(kāi)傳統(tǒng)PM的一個(gè)人一條龍到底的觀(guān)念，做出有針對(duì)性的部署和處理，會(huì)大大地提高研發(fā)效率和團(tuán)隊(duì)的創(chuàng)新視野。

??? 分離原則在很多地方在默默地應(yīng)用著，各有說(shuō)法。但相信所有的分離，都是為了更好的整合。?

?

3.? 前緊后松原則
??? 如果設(shè)計(jì)與編程是程序員的主要工作的話(huà)，那么接下來(lái)的Debug調(diào)試（Test測(cè)試則重點(diǎn)不同，由Integration Test專(zhuān)業(yè)人員完成），也許是產(chǎn)品化過(guò)程之中交付成果之前，程序員的臨門(mén)一腳了。此步看似簡(jiǎn)單，實(shí)則暗流涌動(dòng)。對(duì)于一個(gè)真正的項(xiàng)目來(lái)講，沒(méi)有哪份代碼可以直接通過(guò)，而是必須經(jīng)歷一段不輕松的Debug歷程。而且即使交付給Test人員后，反饋回來(lái)的必將是一堆問(wèn)題，仍然要繼續(xù)De-bug。有經(jīng)驗(yàn)的PM一般將調(diào)試與編程的任務(wù)時(shí)間比例定得很高（2~5），這叫做前緊后松原則。
??? 當(dāng)然在中國(guó)，特殊的發(fā)展階段和豐富廉價(jià)的人才使得Boss們將Debug時(shí)間定得很緊，至于Test反饋問(wèn)題后的Debug時(shí)間一般不在項(xiàng)目規(guī)劃內(nèi)，碼農(nóng)們只能通過(guò)無(wú)窮無(wú)盡的免費(fèi)加班來(lái)完成。這是閑話(huà)，還是少說(shuō)為妙。

??

????最后簡(jiǎn)單說(shuō)，如果想一個(gè)項(xiàng)目成功，請(qǐng)PM們重視需求和調(diào)試，而不僅僅是完成編碼，不然害人害己。當(dāng)然，說(shuō)說(shuō)總是容易，而且沒(méi)有一成不變的原則，有些具體事務(wù)的處理總是相對(duì)的。比如模塊和業(yè)務(wù)分離，在資源相對(duì)緊張的情況下，過(guò)度的分離也許會(huì)拖慢程序的啟動(dòng)速度。

總結(jié)

以上是生活随笔為你收集整理的前松后紧和前紧后松——想起PM的点滴的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。