第3篇·時間黑洞

爲何你總在加班？爲何你下班後身心俱疲，但又感受一天沒作什麼？你的時間都去哪兒了？如何才能早點下班回家？今天，咱們來探討一下這個現在很是廣泛現象背後的緣由。

辦公環境

不知道你有沒有這樣的經歷：你的旁邊是電話銷售或者售後服務，當你準備將構思好的一段代碼寫下來時，他們的一通電話讓你的構思像被一陣龍捲風襲擊同樣，再也想不起來。你感受本身就像置身於菜市場同樣，根本沒法寫出什麼像樣的代碼。

如今開放式辦公愈來愈受歡迎，看起來彷佛讓同事間的溝通更加的高效、同事的關係也更加融洽，但事實倒是你常常被旁邊同事與他人的討論打擾，忍受着視覺與聽覺的污染，讓你沒法集中注意力。本來半小時就能夠完成的任務，你須要常常停下來從新捋一下思路，你花費了更長的時間來完成任務，質量還打了折扣。

開放式辦公與格子間辦公各有利弊，前者更便於溝通，讓員工沒法在上班時間娛樂；後者給員工一個相對獨立的空間，能更加專一高效處理事件。兩者彷佛難以抉擇，正如沒有最好的方式，只有合適的方式同樣，能夠爲員工提供兩種辦公環境，讓員工自由選擇。若是採用開放式辦公只是爲了防止員工上班「摸魚」，你或許應該改善的是招聘標準，而不是讓工做效率下降的工做環境。

會議

你可能也有過這樣的經歷：被邀請參加一個會議，進去以後發現不少的參會者，認真聽了一下子後，發現彷佛和你沒有什麼關係。當你正想看一下以前收藏的博客時，又忽然被提問。眼看會議室時間就要到了，組織者彷佛對本場會議不是很滿意，又約定兩天後繼續討論。

毫無疑問，會議是一種高成本的高效溝通方式，但不少人將這種溝通方式濫用，反而浪費了不少的時間。所以，這種形式須要組織者在會前認真作不少準備工做，如：明確會議主題、必要與會人員、參會者會議前須要瞭解的內容、會議所要達到的效果等。

需求評估

產品需求的合理性，需求與系統間的平衡，投入產出比等，這是咱們每一個開發者在需求評估時都須要考慮的問題。產品經理與開發者應該站在各自的角度評估需求，並給出合理的解釋。對於那些收益較少，但會對系統穩定及維護形成很大沖擊的需求，請嚴辭拒絕，若是產品經理用領導向你施壓，而領導又沒法給出使人信服的理由，你或許應該考慮換一個團隊了。

一個畸形的需求會像核輻射同樣污染整個項目。到時你不得不天天充當救火隊員，即便在下班時間也會經常收到報警提醒。

若是你評估後認爲需求合理，但產品要求你3天完成一個不可能完成的任務，請不要高估本身的能力，說明你的真實狀況。要麼延長開發時間，要麼增長人手。說明本身在不可能的時間完成任務並不丟人，承諾失信才更加丟人。

拼湊代碼

你編程的方式是否是在不停的試驗，尋找一種看上去能工做的組合？即便你這樣隨意的開發過程可以產生出一個正確的程序，但你真的清楚你寫的代碼是如何運行的嗎？清楚其中所隱藏的 bug 嗎？你須要真正理解你的代碼是如何工做的，而不是瞎猜。

相比與拼湊代碼的程序員，優秀程序員會首先理解需求，而後在腦海中模擬程序的執行，再將執行過程用僞代碼的方式記錄下來，檢索邏輯是否存在漏洞，是否有值得優化的地方。當他們肯定好以後，再轉換爲代碼語言。在這個過程當中，他們用80%的時間思考，用20%的時間寫出高質量的代碼，而他們大多數時間看起來並非那麼忙。他們用僞代碼來檢查本身的整個代碼，也確保本身在編寫代碼過程當中不會走偏而浪費時間。

在編寫完成後，差的程序員本身跑一遍代碼就提交給測試，而優秀的程序員會從新審視本身剛寫的代碼，這個過程當中又能發現80%的錯誤，諸如拼寫錯誤，判斷邊界條件等。不經審視的代碼在測試後收到一大堆的問題反饋，如需求不符，數據顯示錯誤等顯而易見的問題，在來回反饋問題、處理問題的溝通中，時間又在不知不覺間來到了下班時間，但如今的問題還不少，意味着你今晚要加班解決了。

在這個過程當中，咱們發現好的開發過程並不會提高你的工做時間和工做量，反而會讓你更早下班，安心休息。

• 認真評估與理解需求
• 用僞代碼檢查可行性與常見問題
• 將僞代碼轉換爲編程語言
• 審視本身的代碼，你一般能找到80%的錯誤，從而節省大量時間

調試 bug

你可能在工做中常常會聽到這樣的話：

• 這問題不多是個人，我什麼也沒改
• 昨天還好好的，怎麼今天忽然就不行了呢？
• 我本地跑的好好的，爲何一到線上就不行了？

要知道，若是你寫的程序出了問題，那就是你的緣由，不是計算機的，也不是編譯器的。程序不會每次都產生不一樣的結果。它不是本身寫出來的，是你寫的，因此，請對它負責。

咱們可能還會在工做中遇到這樣的一種人：

• 查找bug時不停的在程序中散佈print，若是print沒有找到緣由，那就隨便修改點什麼，讓程序看起來好像正常了
• 出現的問題不值一提，要解決它們並不須要完全弄懂程序。只要能讓程序看起來正常運行就好了
• 不須要重寫這段本身兩個月前的爛代碼，只要能讓這段程序跑起來就行

在大多數狀況下，查找並理解 bug 一般佔用了整個調試工做的 90%。所以，若是你已經在查找 bug 中花費了太多的時間，你或許應該優化你的異常處理，可以快速定位到問題所在；也應該優化你的代碼，不要讓那些難以閱讀的代碼花費太多時間。治標不治本的問題處理方式一樣會讓你和這個問題糾纏在一塊兒，浪費更多的時間，

質量

不讓蒼蠅煩擾你的最好方式就是消滅蒼蠅，所以，咱們須要高質量來減小咱們在 bug 中所花費的大量時間。而質量保障在項目中又是一個設計面很普遍的話題，更詳細的內容可閱讀《代碼大全》等經典書籍，也能夠查看個人《代碼大全》筆記。

軟件質量大致包括如下方面：

• 需求調研
• 產品設計
• 技術架構(是否包含取悅老闆的部分？)
• 項目實施人員配置(《人月神話》)
• 數據表設計
• 開發規範
  • 高質量的類
  • 高質量的子程序
  • 防範式編程
• 質量保障是否全程關注
• 自動化測試
• bug 追蹤
• bug 分析統計

經驗告訴咱們：錯誤越早引入軟件當中，問題就會越複雜，修正這個錯誤的代價也就越高，由於錯誤會牽涉到系統的更多部分。所以，保障開發質量並不會讓你作不少工做，而會讓你節省不少時間。那些爲了追求速度而放棄質量的決策者是愚蠢的。提升質量不只能縮短開發週期、下降開發成本，也讓工做與生活的平衡成爲可能。

遠離老好人領導

這樣的領導大包大攬一大堆，不清楚職責邊界。看似作了不少工做，但又有不少問題。這不會給你增長成就感，反而徒增挫敗感：天天的問題如洪水猛獸吞噬着每一個人的時間，你和他反饋現狀，他只會讓你放棄你的想法；你和他討論問題的解決方案，他的方案是權宜之計。請遠離這樣的領導，他只會不停吞噬你寶貴的時間。

---

那些常常哭訴本身天天從早幹到晚的人不值得同情，抱怨解決不了任何問題，只會浪費更多的時間。

最後，我想引用一段知乎用戶在類似問題下的回答：

爲何幾十年前，不少思想家都幻想過。

隨着科技發展，人們天天只須要工做3-5小時。

人們能夠享受生活，享受自由，享受家庭，享受大天然。

爲何科技愈加展，人們越無法享受科技發展的紅利？

人們不只無法天天工做3-5小時，996還成了福報，35歲被裁人成了標配。

爲何科技愈加展，勞動者越痛苦，勞動時間越長。

爲何如今的絕大部分勞動者，都養不活兩個孩子？

科技真的進步了嗎？社會真的發展了嗎？

若是科技進步了，社會發展了，文化繁榮了。

那麼是什麼奪走了人們的生活，時間，孩子？