技術交流

菜鳥工程師的反思

更新於

可能最近的工作生活過的有些淩亂,甚至混亂,在聽部門提升計畫中講的認識自我的課程之後,也重新引發了已經暫停有一些時間的思考,在流覽了一些書籍博客後,總結到以下的幾點:

軟體開發如同木匠做桌子

一張桌子(一個打快的四方形木板、四個等長的木頭柱子、四個釘子和一個錘子);一張桌子(討論用途和功能、材料、風格、動工打磨、鑿眼、黏合、著色、封蠟、拋光)。

我們在工作當中會碰到很多類似的問題,當客戶提出一個需求(一張桌子)的時候,客戶想到的大部分都只是第一種,他們會說「這只需要你花幾個小時的時間…」、「你可以這樣做…這樣更簡單」或「你只需要簡單的把它改成…」,更甚之會指點你該如何做。殊不知在拿到一個需求之後,我們還需要再瞭解確認準確的需求,要用在什麼地方、資料量如何等等,然後才會花大量的時間搭建架構,確保能夠承受使用者和資料負載壓力,要能夠處理大資料量情況;然後需要花費更多的時間寫出有品質、可讀的、可維護的代碼,然後測試修正等等。至少要確認最終交付的是一個完整、可信賴、符合需求的產品。

千萬不要告訴我們這樣多簡單,多容易,Easier said than done,除非你自己做過。如果你真的認為能既迅速又簡單的做出來,你自己試試,幹吧,拼裝出一個搖晃的桌子。如果你希望得到一個好的產品,你要理解明白開發需要時間和技能,有很多你根本想像不到的問題在裡面。

工作狀態

和作家一樣,需要的是一種入靜的狀態。他們需要整段的不被打擾的時間才可以很好的工作。一個下午三點鐘的會議,哪怕僅僅持續 15 分鐘,一個下午就會因此廢了。問題不是會議佔據的時間,關鍵問題是會議把一個下午分成了兩塊,讓每塊都不夠大,都不足以入靜。因為對於下午廢掉的擔心,上午的工作也受到影響,不太敢開始解決真正困難的問題。所以整天都在一種心神不寧的狀態。

我們經常會覺得能夠有一整天的時間可以用來開發一個東西是多麼幸福的事情,這樣做事的效率也會成倍的高於時不時的被打擾一下的工作模式。

預估項目的時間

或許我現在還是個只工作了兩三年的小菜鳥,每每需要預估交貨日期、專案完成時間時,總有點像是要簽賣身契的感覺,究其原因在於無法完全估計項目過程中可能會出現的所有 X 因素。

其實對於軟體的複雜度,唯一有效的推測方法是依據經驗,而且這還不是時時都好用。若是開發與之前相似的功能,還可以根據之前的開發大概估計整個專案需要的大致時間。然而,事實情況中,每個專案在開發過程中都遇到瓶頸,更不用說針對全新的需求。這些瓶頸會消耗工程師的大量時間,你在遇到它們之前根本不會有所預見。它們會拖住整個項目,致使工期延後數周甚至數月。

今日的問題源於昨日的解決方案

在日常工作中我們會經常碰到這樣的問題,之前已經處理過的問題、BUG 或者開發的程式,很有可能在後續的時間裡被提出還存在著問題。有一個笑話是用來調侃“你的代碼有問題”、“你這個程式和預期的有點不一致,你看看是不是我的使用方法有點問題”這兩種在出現問題之後對程式師說的話,相信九成的工程師都會選擇聽後面這句話,然後會想到程式是不是還存在BUG。但是問題點是一樣的,就是程式可能存在 BUG。

所以在處理問題的時候儘管它是如此的簡單,也要有完整的處理方案流程,不然可能會有隨之而來的很多附加問題,浪費更多的時間。

拖延成災

或許絕大多數的人都有碰到過這個問題吧,對於一件事情,我們很多時候會選擇盡可能的在限期內的最後時刻去完成交付,長此以往的結果就是會無可避免的出現越來越多的延誤。

其實之所以拖延,除了人的惰性,還可能因為有那麼一件或者多件 X 事件在阻擾我們做該做的事,正是這些事導致了大部分的拖延行為。解決方法就是把它們寫下來,列一個清單,並且放到你常常能夠看到的地方。這樣就可以做好整理分類,按照事情的輕重緩急,緊急優先程度處理。

閱讀更多