導語：
最近看了極客時間上面的 10X程式設計師工作法 專欄，作為一個剛入職不久的程式設計師，感觸頗深，其中一點就是工作高效與否和意識有很大的關係，這裡的意識要和技術技能分開來，前者更多的是做事策略，包括做事順序、大局觀，以及怎樣溝通等等，後者只是專業能力。今天來講講在一個專案開始之前，也就是寫程式碼之前，有哪些東西是需要做的，以及為什麼要做，做這些東西能夠為工作效率帶來什麼樣的改變，這篇文章就結合自己真實情況，講講看過專欄之後的感想與總結。
很多時候我們會帶著一種急於求成的心態去開始一個專案，我們常常告訴自己，問題只有在做專案的過程中才會被發現，不去做，永遠不會發現問題。這樣認為其實並沒有錯，但是，是不是所有的錯誤或者問題只有自己犯過才能避免下次再犯？別人的經驗有沒有借鑑的意義？提前計劃能不能避免一些可能會遇到的問題？行業裡面有沒有一些比較好的實踐？這些都是值得深思的問題。
我工作這一年裡發現其實工作上面很多問題，並不是專業能力方面的問題，而是做事策略上面的問題。2017 年年底畢業後，由於地域原因，在一家小公司上班，職位是軟體開發工程師，公司沒有很好的管理制度，很多在大公司裡面約定俗成東西，在這裡都需要自己去琢磨，去和同事和領導討論，時常要考慮自己本職工作以外的東西，像似運維，產品等等。有些時候真的挺迷茫，不知道怎麼做才是好的，沒有經驗的積累，也沒有資深軟體工程師的指點，心裡面就更沒底了。但是現在想想，痛苦的經歷是值得珍惜和思考借鑑的，這其實也是成長的必經之路，與此同時，也會感嘆，當初如果早知道該多好。
下面列出來幾個點是我覺得在接手一個專案前，或者做一個專案前，必須弄清楚的東西，不然的話，你會發現周圍都是坑。
以終為始
這標題其實是鄭曄老師專欄的一個模組，意思是開始之前需要考慮到最後的結果，如果你發現這個專案做下去，即使最後做完了，使用者也不會滿意，那麼這個專案就沒有做的必要，或者說是設計上面必須有些調整；比如說，你發現自己對這個專案需要用到的技術比較陌生，心裡沒有底，那也得想想有沒有可以替代的技術，或者是否有足夠的時間和能力去學習；還有就是這個專案牽扯到哪些人，哪些團隊，他們分別負責的是哪個部分，出問題或者開會討論你應該去找誰。總的來說是，做一個專案，不能夠順著思維想，而是要倒著想，從結果反推策略方法，這麼做是因為我們要先確保我們的工作是有保障的，出了問題是有解決方法的，我們的工作成果是有價值的。
多問些為什麼
在公司有些時候確實是會哭的孩子有奶吃，很多時候機會擺在那裡，因為種種原因你不去爭取，那機會就會失之交臂，工作也會困難很多。很多時候，在別人提出了不合理的要求，就得說出自己的真實想法，不要怕不好意思，例如說我的領導叫我用我不熟悉的技術去做一個專案，那麼我就得問他，為什麼一定要用這個技術？其他的技術行不行？我對這個技術不熟悉，可能不能勝任這個專案，有沒有其他人能夠勝任？如果一定需要我來做，那我會告訴他，我需要花 XXXX 的時間，之所以花這些時間，是因為我要去學習這項技術，當然我會拆分的更加細緻些，這樣也會有說服力些。
有一個經典的法則 5 Whys，這裡的 5 只是一個參考數字，實際情況可多可少，但是這個原則的主要目的就是為了找到 root cause，也就是根本原因。開始專案之前多問些為什麼有助於自己瞭解上級和其他人的想法，這樣在這個專案中，會清楚地給自己一個比較準確的定位，同時也能夠排除很多不必要的擔憂，問題永遠是越早發現越好。這裡預設所有的需求都不做，直到弄清楚為什麼要做這件事，省時省力，幫助了別人，也成長了自己。
分解，定義要做的部分
做一件事情，分的越細就越容易做，還有就是，越牛逼的人，時間單位就越小，例如每 15 分鐘做什麼，甚至每 5 分鐘做什麼；一般的人可能會說今天做什麼，明天做什麼；沒有目標，沒有計劃的人甚至會說這段時間做什麼。你如果能夠把一個專案要寫的程式碼劃分成一堆任務，每個任務用幾句簡單的程式碼就能夠完成，而且和不會影響其他的任務，那麼這樣的分解就是好的，但是這些東西確實需要平時的刻意練習，難點永遠在於怎麼分，怎麼計劃，而不是怎麼做。我現在就是函式寫的很長，但是每次回來都會靜下心來改改，做做重構，刪去程式碼中的壞味道，每次都會比之前的寫的更加的簡潔，看著這些程式碼的改變其實都是對自己的鼓勵。
另外就是如何定義這些任務，怎麼樣才叫完成？有什麼樣的驗收標準？如果你和其他人在這些問題上面意見不一樣就開始專案的構建，那麼遲早會出問題，往往是你認為可以了，他卻認為不行，最後沒做好不說，還憋了一肚子的火，還不如提前就把它們定義好。比較好的策略是從使用者的角度出發，寫 user stories，也就是使用者使用產品的整個過程，幫助分析使用者是怎樣使用這個產品的，這樣能夠更好地發現設計上面的問題，沒有寫任何程式碼就能夠發現設計的缺陷，是最好不過了。
定義一些數字來反應一些客觀事實
數字相比其他的東西更有說服力，比如說要求在 1 月 1 號 產品上線，那麼多一天都是延期；測試覆蓋率必須 100%，那麼 99.99% 也是不合格的程式碼。如果在做專案之前，給專案的要求裡面加上一些數字，可能最後的評審會相對來說輕鬆不少，達不達的到，心裡面也會有一杆秤，也會合理分配精力時間。
說了這些，我相信這不是全部，這些都是意識上面的問題，也就是知道和不知道的區別，但是有些時候想做到還真不是那麼容易，但是我相信痛苦就在開頭，學習了，成長了，後面才會長期受用。