丨流程和紅綠燈不是約束而是用來(lái)提高效率

以代碼的規(guī)范為例，對(duì)于技術(shù)高的程序員來(lái)說(shuō)，代碼可能會(huì)耽誤一點(diǎn)時(shí)間，但對(duì)整即使是水平高的程序員，也可能會(huì)被發(fā)現(xiàn)有錯(cuò)誤，代碼可以降低出錯(cuò)的概率，保障質(zhì)對(duì)于水平低的程序員，可以通過(guò)代碼學(xué)習(xí)和成長(zhǎng)，代碼被高水平程序員后，可以軟件項(xiàng)目中這樣的例子還有很多，類(lèi)似的還有像遇到Bug要提交到Bug系統(tǒng)，還需配合重現(xiàn)步驟說(shuō)明，看起來(lái)繁瑣，但是卻讓Bug可以有效，讓開(kāi)發(fā)人員可以重現(xiàn)和定位，從而高效的修復(fù)Bug。我們知道，在運(yùn)動(dòng)項(xiàng)目上，有些運(yùn)動(dòng)員特別有天分，總能拿好的成績(jī)，而這些運(yùn)動(dòng)員的動(dòng)如果我們站在流程規(guī)范的角度看軟件工程的開(kāi)發(fā)模式，它也是源自實(shí)踐過(guò)程中，有些厲害的項(xiàng)目經(jīng)理發(fā)現(xiàn)了好的、可以提升軟件質(zhì)量的開(kāi)發(fā)實(shí)踐，不斷總結(jié)改進(jìn)，最后變成了流程，讓普通的項(xiàng)目經(jīng)理按照這一套流程，也能做出不錯(cuò)的軟件。Sprint有計(jì)劃會(huì)、評(píng)審會(huì)。在《10|因?yàn)槿绻陧?xiàng)目管理中，過(guò)于依賴(lài)人的管理，項(xiàng)目經(jīng)理就會(huì)成為瓶頸，大事小事都需要項(xiàng)目經(jīng)理來(lái)決策。再說(shuō)項(xiàng)目經(jīng)理也不能保證每次決策的正確性，如果決策，會(huì)很可能導(dǎo)致一些。我以前工作過(guò)的一個(gè)項(xiàng)目組，一個(gè)項(xiàng)目持續(xù)了好多年，中間人換了一批又一批，甚至有時(shí)候連項(xiàng)目經(jīng)理都空缺，而項(xiàng)目一直井然有序的進(jìn)行著，沒(méi)有出什么問(wèn)題，靠的就是多年積累下來(lái)的適合項(xiàng)目組的流程規(guī)范。06|大廠都在用哪些敏捷方法？（上）》這篇文章中描述的那樣：項(xiàng)目成員日常板就知道什么，代碼、化測(cè)以有證質(zhì)項(xiàng)目可以保證新人加入時(shí)能快速上手，結(jié)對(duì)編程可以保證新人遇到問(wèn)題可以得到直接的幫助。還有一個(gè)常見(jiàn)場(chǎng)景就是需求變更，產(chǎn)品經(jīng)理想加一個(gè)緊急需求，這通常是讓項(xiàng)目經(jīng)理為難的事情：加吧，影響項(xiàng)目進(jìn)度，開(kāi)發(fā)人員有意見(jiàn)；不加呢，可能客戶或者產(chǎn)品經(jīng)理有意見(jiàn)。一個(gè)不就兩邊都得罪了。所以你看，如果說(shuō)在流程上規(guī)范起來(lái)，例如：數(shù)據(jù)庫(kù)操作之前先備份數(shù)據(jù)庫(kù)，事先寫(xiě)好SQL語(yǔ)句，需要有人，測(cè)試環(huán)境先測(cè)試通過(guò)，最后再生產(chǎn)環(huán)境執(zhí)行，那么就可以避免以后再出現(xiàn)不小比如說(shuō)服務(wù)器部署后出現(xiàn)問(wèn)題，高手可能就直接上服務(wù)器操作，直接修改代碼編譯解決，這是一個(gè)解決方法，但這不能成為一個(gè)流程規(guī)范，因?yàn)閾Q一個(gè)水平不行或者對(duì)代碼不熟悉的人來(lái)做，可能會(huì)搞出更大的問(wèn)題。這時(shí)候回滾操作就是一個(gè)相對(duì)普適的方法，可以變成一個(gè)部署后出現(xiàn)問(wèn)題的流程。敏捷開(kāi)發(fā)的流程：雖然你的項(xiàng)目不一定采用敏捷開(kāi)發(fā)的方式，但是敏捷開(kāi)發(fā)中一些好的流程是可以借鑒的，例如參考我之前文章提到的像看板、站立會(huì)議、持續(xù)集成，這些好的工作流程，都可以借鑒。代碼規(guī)范：其實(shí)很多公司都公開(kāi)了他們的代碼規(guī)范，可以直接基于這些規(guī)范制定團(tuán)隊(duì)的規(guī)范。例如說(shuō)前端的有Arbnb的代碼規(guī)范ArbnbJaaScriptteGuidJavaJavaStyleGuide，.Net的有.NETGuide，等等。源代碼管理流程：現(xiàn)在的源代碼主流是git，而基于Git的代碼管理已經(jīng)有很多成流程規(guī)范可以參考。例如阮一峰老師寫(xiě)過(guò)的《Git使用規(guī)范流程》、《Git工作流程》和《Git分支管理策略》，或者 的《Understandingtheflow》，Gitlab推薦的《IntroductiontoGitLabFlow》。部署流程：十年前，每日定時(shí)構(gòu)建還是很時(shí)髦的部署流程，而現(xiàn)在，主流的部署流程已經(jīng)變成了持續(xù)部署，每次代碼合并到主分支都可以觸發(fā)一次自動(dòng)部署，這樣一有問(wèn)題，就能馬上知道發(fā)生在哪個(gè)環(huán)節(jié)。如果說(shuō)，以前我還是人為去推動(dòng)一些流程規(guī)范的執(zhí)行，近些年，我越來(lái)越感覺(jué)到，能借助技術(shù)來(lái)推動(dòng)甚至替代流程規(guī)范。例如說(shuō)代碼規(guī)范，以前代碼規(guī)范的執(zhí)行，主要靠反復(fù)的教育宣傳和代碼中一個(gè)個(gè)去檢查。而現(xiàn)在，借助e這種強(qiáng)大的ID，以及Lnt（ContinuousIntegration，持續(xù)集成）Git，可以保證代碼必須在通過(guò)測(cè)“軟件工程”和“質(zhì)量工程”需要依靠架構(gòu)技術(shù)，而不是依靠M和QA管理流程。一切工程問(wèn)題，首先要思考能否通過(guò)技術(shù)解決，當(dāng)前技術(shù)無(wú)法解。流程和規(guī)范，就像紅綠燈一樣，不是一種約束，而是犧牲一點(diǎn)利益，提高團(tuán)隊(duì)效率；流程和規(guī)范將好的實(shí)踐標(biāo)準(zhǔn)化流程化，讓大家可以共享經(jīng)驗(yàn)；流程和規(guī)范，讓項(xiàng)目管理從人治。要制定好項(xiàng)目規(guī)范，先明確要解決的問(wèn)題，然后提出解決方案，看是否可以通過(guò)流程規(guī)范來(lái)解決，有了方案后需要團(tuán)隊(duì)成員一起達(dá)成一致，最后再推廣執(zhí)行。在執(zhí)行過(guò)程中需要持續(xù)的優(yōu)化，不斷改進(jìn)。 售賣(mài)。頁(yè)面已增加防盜追蹤，將依 其上一 11|項(xiàng)目計(jì)劃：代碼未動(dòng)，計(jì)劃先下一 13|白天開(kāi)會(huì)，加班寫(xiě)代碼的節(jié)奏怎么破言言 4性、成長(zhǎng)空間、既得利益是第一位。但怎么來(lái)控制這兩者之間的平衡，老師能否幫純潔的憎 作者回復(fù):??其實(shí)我沒(méi)說(shuō)啥，是你自己想到的思路 2放沒(méi)有統(tǒng)一路徑，還好放在一個(gè) 中你的運(yùn)維，一定要盡可能化自動(dòng)化，比如說(shuō)，規(guī)定好放在什 ，你不需要人工去 起而 Python我用的少，現(xiàn)在寫(xiě)js代碼，每次保存文件的時(shí)候vscode自動(dòng)把代碼格式的整整起而 2 1 作者回復(fù):已拜讀，寫(xiě)的非常好 …。小 敖天 老師說(shuō)的很對(duì)，目前我在推廣中也遇到了一些問(wèn)題。指正一點(diǎn)，VSCIDE作者回復(fù):謝謝指正 我去獵聘、51job作者回復(fù):那你可以 下，總不是壞事 作者回復(fù):ITIL的不了解，不好妄加評(píng)論天之大 戶也很有意見(jiàn)，認(rèn)為做事不專(zhuān)業(yè)。后面我們制定了更新包準(zhǔn)備、更新包驗(yàn)證作