1. 程式人生 > >寫給工程師的幾條精進原則

寫給工程師的幾條精進原則

我們大多數同學在工作中缺乏原則的指導。原則,猶如指引行動的“燈塔”,它連線著我們的價值觀與行動。不久前,橋水基金創始人雷·達里奧在《原則》一書中所傳達的理念,引爆了朋友圈。每個人都應該有自己的原則,當我們需要作出選擇時,一定要堅持以原則為中心。但是在現實生活中,我們往往缺少對原則的總結,對於很多人來說這是一門“只可意會不可言傳”的玄學,是屬於老司機的祕密,其實不然。

原則一:Owner意識

“Owner意識”主要體現在兩個層面:一是認真負責的態度,二是積極主動的精神。

認真負責是工作的底線。首先,要對我們交付的結果負責。專案中每一個設計文件、每一行程式碼都需要認真完成,要對它的質量負責。如果設計文件邏輯混亂,程式碼沒有註釋,測試時發現一堆Bug,影響的不僅僅是RD的工程交付質量,還會對協同工作的RD、QA、PM等產生不好的影響。久而久之,團隊的整體交付質量、工作效率也會逐步下降,甚至會導致團隊成員之間產生不信任感。其次,我們要對開發的系統負責。系統的架構是否需要改進,介面文件是否完善,日誌是否完整,資料庫是否需要擴容,快取空間夠不夠等等,這些都是需要落地的事情。作為系統Owner,請一定要認真履行。

積極主動是“Owner意識”更高一級的要求。RD每天要面對大量的工作,而且很多並不在計劃內,這就需要具備一種積極主動的精神。例如我們每天可能會面對大量的技術諮詢,如果客戶提出的問題很長時間得不到迴應的話,就會帶來不好的客戶體驗。很多同學說忙於自己的工作沒有時間處理,有同學覺得這件事不是很重要,也有很多同學是看到了,但是不知道怎麼回答,更有甚者,看到了乾脆裝沒看見。這些都是缺乏Owner意識的體現。正確的做法是積極主動地推動問題的解決,如果時間無法排開或者不知道如何解決,可以直接將問題反饋給能解決的同學。積極主動還可以表現在更多方面。比如很多同學會自發地梳理負責服務的現狀,根據介面在效能方面暴露的問題提出改進意見並持續推動解決;也有同學在跨團隊溝通中主動承擔起主R的角色,積極發現問題、暴露問題,推動合作團隊的進度,保證專案順利推進。這些同學無一不是團隊的中堅力量。所以,我們在做好自己份內工作的同時,也應該積極主動地投入到“份外”的工作中去。一分耕耘一分收穫,不要給自己設限,努力成為一個更加優秀的人。

原則二:時間觀念

相信大家都有時間觀念,但是真正能執行到位的可能並沒有那麼多。網際網路是一個快速發展的行業,RD的研發效率是一個公司硬實力的重要體現。專案的按期交付是一項很重要的執行能力,在很大程度上決定著領導和同事對自己靠譜程度的評價。大家可能會問:難度幾乎相同的專案,為什麼有的同學經常Delay,而有的同學每次都能按時上線?一個很重要的原因,就是這些按時交付的同學往往具備如下兩個特質:做事有計劃,工作分主次。

工作安排要有計劃性。通常,RD在設計評審之後就能預估出精確的開發時間,進而再合理地安排開發、聯調、測試計劃。如果是專案負責人,那麼就會涉及協調FE、QA、PM等多個工種的同學共同完成工作。凡事預則立,不預則廢。在計劃制定過程中,要儘可能把每一項拆細一點(至少到pd粒度)。事實證明,粒度越細,計劃就越精準,實際開發時間與計劃之間的誤差就會越小。此外,務必要規定明確的可檢查的產出,並在計劃中設定一些關鍵的時間點進行核對。無數血淋淋的事實告訴我們,很多專案延期都是因為在一些關鍵交付點上雙方存在分歧造成的。例如後臺RD的介面文件計劃在週五提供,FE認為是週五上午,而RD認為是週五下班前提交,無形中會給排期帶來了1pd的誤差。所以,我們要做到計劃粒度足夠細,關鍵時間點要可檢查。

工作安排要分清楚主次。我們每天要面對很多的事情,要學會分辨這些工作的主次。可以嘗試使用“艾森豪威爾法則”(四象限法則),把工作按照重要、緊急程度分成四象限。優先做重要緊急的事情;重要不緊急的事情可以暫緩做,但是要持續推進;緊急不重要的事情可以酌情委託給最合適的人做;不重要不緊急的事情可以考慮不做。很多專案無法按期交付的原因,都是因為執行人分不清主次。比如在開發中需要使用到ES,一些不熟悉ES的同學可能想系統性地學習一下這方面的知識,就會一頭扎進ES的汪洋中。最後才發現,原本一天就能完成的工作被嚴重拖後。實際工作中,我們應當避免這種“本末倒置”的工作方式。在本例中,“系統性地學習ES”是一件重要但不緊急的事情。要學會分辨出這些干擾的工作項,保證重要緊急的事情能夠按時交付。

原則三:事不過二

“事不過二”,是我們團隊一貫堅持的原則,它可以解讀為兩層含義。

一層含義是“所有的評審與問題討論,不要超過兩次”。之所以有這樣的要求,是因為我們發現,很多RD都把時間花費在一些無休止的評審與問題討論中,真正投入到實際開發中的時間反而很少。在實際工作場景中,我們經常會遇到一些不是很成熟的需求評審。這些需求文件,要麼是背景與目標含糊不清,要麼是產品方案描述不夠細化,或者存在歧義。RD與PM被迫反覆進行討論,我曾經遇到過一個需求評審,進行了三次還被打回。同樣的問題,在設計評審中也屢見不鮮。方案固然需要經過反覆的討論,但是如果遲遲不能達成一致,就會耗費很多RD與PM的寶貴時間,這就與提升研發效率的理念背道而馳。因此,我們團隊規定:所有的評審最多兩次。通過這種方式,倒逼利益相關方儘可能地做好需求與方案設計。評審會議組織前,嘗試與所有相關人員達成一致,詢問對方的意見,並進行有針對性的討論,這樣能夠大大提升評審會議的效率和質量。如果在第一次評審中不通過,那麼就只有一次機會進行復審。一旦兩次不通過,就需要進行Casestudy。

“事不過二”原則的另一層含義,是“同樣的錯誤不能犯第二次”。每次故障之後,Casestudy都必須進行深刻的總結覆盤,對故障原因進行5Why分析,給出明確可執行的To Do List。每次季度總結會,大家自我反省問題所在,在下個季度必須有所改善,不能再犯類似的錯誤。孔子云:“不遷怒,不貳過”,在錯誤中反思與成長,才能讓我們成為更優秀的人。

原則四:設計優先

“設計優先”這條原則,相對來說更加具體一些。之所以單列一項,是因為架構設計太重要了。Uncle Bob曾說過:“軟體架構的目標,是為了讓構建與維護系統的所需人力資源最小化。”

架構設計,並不僅僅關係到系統的質量,還關乎團隊的效能問題。很多團隊也有明文規定,開發週期在3pd以上的專案必須有設計文件,開發週期在5pd以上的專案必須有設計評審。在具體的執行過程中,由於各種原因,設計往往並不能達到預期的效果。究其原因,有的是因為專案週期緊,來不及設計得足夠詳細;有的是因為RD主觀上認為專案比較簡單,設計草草了事。無數事實證明,忽略了前期設計,往往會導致後續開發週期被大幅拉長,給專案帶來了很大的Delay風險。而且最可怕的是,不當的設計會給專案帶來巨大的後期維護成本,我們不得不騰出時間,專門進行專案的優化與重構。因此,無論什麼時候都要記住“設計優先”這一原則。磨刀不誤砍柴工,前期良好的設計,會給專案開發以及後期維護帶來極大的收益。

“設計優先”這一原則,要求寫別人看得懂的設計。我們瞭解一個系統最直接的途徑就是結合設計文件與程式碼。在實際工作中,很多同學的設計文件讓大家看得一頭霧水,通篇下來,看不出系統整體的設計思路。其實,設計的過程是一種智力上的創造,我們更希望它能成為個人與集體智慧的結晶。如何才能讓我們的設計變得通俗易懂?我個人認為,設計應該儘量使用比較合理的邏輯,進而把設計中的一些點組織起來。比如可以使用從抽象到具體,由總到分的結構來組織材料。在設計過程中,要以需求為出發點,通過合理的抽象把問題簡化,講清楚各個模組之間的關係,再詳細分述模組的實現細節。做完設計之後,可以發給比較資深的RD或者PM審閱一下,根據他們的反饋再進行完善。好的設計,一定是邏輯清晰易懂、細節落地可執行的。

原則五:善於提問

“善於提問”,首先要勤於提問。求知慾源於好奇心,是人類的一種本能。在工作中要養成勤於提問的好習慣,不懂就問,不要因為自己一時懶惰或者礙於情面,就放棄提問的機會。當遇到不同的觀點時,也要禮貌地問出來。波克定理告訴我們,只有在爭辯中,才可能誕生最好的主意和最好的決定

在設計評審、程式碼評審這類體現集體智慧的活動中,遇到有問題的地方一定要提出來。我經常看到,很多同學評審全程一言不發,這就是浪費大家的時間。設計評審的目的,是讓大家針對方案提出改進意見並達成一致,如果全程“打醬油”,那就失去了評審的意義。我們鼓勵大家多提問,把自己內心的疑惑表達出來,然後通過交流的方式得到答案。

“善於提問”,還要懂得如何提問。為什麼同樣是參加設計評審,有的同學就能提出很好的問題,而有的同學卻提不出任何問題?除了知識儲備、專業技能、經驗等方面的差異外,還有一點很重要:批判性思維。

批判性思維主張通過批判性思考達到理性思維,即對事物本質的認知和掌握。關於如何進行批判性思維,大家可以參考一些經典的圖書如《批判性思維》、《學會提問》等。在工作中面臨一項決策時,會有各種各樣的意見擺在你面前,所以我們必須要學會使用批判性思維來進行分析,每個人的論據是否可靠,論證是否合理,是否有隱含的立場。同樣,在閱讀一篇技術部落格的時候,也要使用批判性的思維,多問幾個為什麼,作者得出的結論是否合理?論據是否充分?只有這樣,才能不斷地獲取真正的知識。

原則六:空杯心態

“滿招損,謙受益”,“空杯心態”是最後一項原則。我覺得這也是一個人能夠持續成長的前提。做技術的人,骨子裡通常有股傲氣,並且會隨著資歷、成績的提升而不斷增加。初入職場的小白,可能會非常謙虛,但是工作幾年之後,專業技能逐步提升,可能還取得了一些小成就,人就會越來越自信。這時候,如果不能始終保持“空杯心態”,這種自信就會逐步演變為自滿。自滿的人,往往表現為工作中把別人的建議當成是批評,不接受任何反對意見,學習上也缺乏求知的動力,總是拿自己的長處去跟別人的短處做比較。其實每個人多少都會有一些自滿,可怕的是不知道甚至不願承認自滿。

保持“空杯心態”這一原則要求我們時刻進行自我檢視與反省。在工作中,多去跟不同級別的同學聊一聊,或者做一個360度評估,這有助於我們更加客觀地評價自己。在橫向對比中,多向那些優秀的同學看齊,學習他人的優點。很多同學在設計評審或者程式碼review過程中,針對別人提出的問題與建議,往往都採用一種對立的態度。錯誤地認為別人是在挑刺,是在針對自己。誠然,在某些方面,我們可能確實比其他人想得深入,但是這不代表在所有方面都能考慮周全。對於別人的建議,建議使用“善於提問”原則裡提到的批判性思維仔細分析一下,虛心地吸取那些好的建議。

工作學習就像“練級打怪”,技能儲備的越多,就越容易走到最後。保持空杯心態,可以讓我們發現很多以前注意不到的新能力,我們要做的就是努力學習它,將它們轉化為自己能力庫的一部分。

最後我要說的是:工作過程中始終保持一顆學習上進的心,無論學到的什麼,也許現在沒有任何作用,但是堅信它一定會給你的未來某一刻時帶來決定性作用的。