程序員怎樣避免高強度的工作？

01-04

如題

排除那些粗暴管理、強制加班的因素，如果要避免高強度的工作，那就只能work smart，我之前寫過一個軟體開發人員的作戰手冊，裡面寫到一些東西，應該能夠幫助你提高工作效率:

1. 可做可不做的功能都不要做。

2. 如果笨方法可以解決問題，這個方法就不算笨。

3. 想辦法把重複性的工作給自動化起來，使用BAT、Shell、Python還有一些專用的自動化小工具都可以，比如打包、部署、測試、還有日常的一些周期性工作。

4. 把你的工作按優先順序排序，排序方法：如果一個功能做不完要砍頭，另一個功能做不完要砍掉胳膊，先做砍頭的那個。

5. 把你每天的工作任務分隔為小時級別的任務，一條一條的列出來，做完一個勾一個。

6. 盡量不要製造BUG，因為寫有BUG 的代碼和寫沒有 BUG 的代碼花費的時間差不多。

7. 問產品或者客戶需求問題的時候，不要問怎麼辦，而是問這麼辦行不行，或者問這幾種方案哪種最好。

8. 不要提交沒有編譯過的代碼，回頭的坑都得自己填。

9. 不要提交沒有測試過的代碼，回頭的坑都得自己填。

1、等需求確定後再做

2、確定開發了一定要和產品經理認真過需求

2、不要隨便改線上代碼包括配置文件，甚至緊急bug

3、有規劃性的寫代碼，鬆散耦合，不然自己挖坑自己填

4、雖然很多代碼真的很稀爛，但是不要輕易重構他們

5、不要輕易承諾這個肯定沒問題，交給我了

6、加入一個靠譜的團隊，避免絕大多數的拍腦袋開發工作

7、不緊急卻不重要的工作都放TODO吧，因為最終你也不會做它們

不要去有加班文化的單位。。。

比如國企。。。

我覺得這都不關工作方法什麼事兒，主要的還是要去靠譜的公司和跟靠譜的老闆

早日財務自由。

當領導或不當程序員

兩個方向：

1、代碼寫得極好，極有想法：公司捨不得拿你去做高強度基礎工作，轉而讓你做高級的，有難度的關鍵事情。

2、代碼寫得極爛：公司實在無人可用的時候才會用你。

方法一需要你努力，方法二有失業風險。

長遠來看的方案，是提高自己的編程能力，讓以前困難的變得遊刃有餘．

短期來看，要正確認識自己，評估出自己的生產力．

多數程序員看到一個新功能，會覺得半天就能搞定，然後就接下來做了．然而事實是這個評估多數是這個程序員是最理想情況下的時間開銷，他沒有考慮寫代碼總會有一定概率出亂子，或是思維陷進死胡同，花費很長時間才相通之類的．我覺得這些問題並不是程序員自身能力的問題，而是人本來就有這樣的缺陷，我們在評估工作量和做事的時候也要把這些問題充分考慮進來．

記得人月神話中，似乎是說開發人員評估出來的時間要乘以４才是近似的真實話費的時間，當然可能有些誇張．但可以說明程序員低估工作量是一種常態．因此我覺得通過正確的認識自己的能力，正確的評估工作量，通過質量去取得工作上的成績，而不是數量，應該可以一定程度上降低工作強度，達到一種平衡．

多想多說少干；多實驗，多討論，少提交。

轉行！

首先當然是有個靠譜的產品經理。

下面是關於自己能做的:

1 任何時候清楚自己在做什麼，想清楚再做。

2 優先順序，你不可能做所有的事情，先做優先順序最高的，學會適當拒絕。

3 代碼寫完，不要急著編譯調試，先在腦子裡運行一遍，很多時候調試半天發現是一個很簡單的問題，很浪費時間，關鍵是還會影響心情。

4 在工作量相差不是特別大的情況下，盡量不要將就用很挫的方法，出來混遲早是要還的，寫代碼也一樣。

5 堅持鍛煉身體，這個最重要。

這會能想到的就是這些，開始吃飯

面試的時候問能不能接受加班的別去給錢少的別去公司技術人員大部分頭髮油膩邋遢的別去

講道理，先按正常員工水平預估時間，然後高效率完成。

不過程序員還是很難避免高強度工作的，合作項目里不僅取決於你，還要考慮其他人

多分享讓別人看到自己的工作，而不是埋頭苦幹。

理性分析問題，不要強行裝逼，強行裝逼==挖坑埋自己，不要感覺任何問題都很簡單，不要相信產品

DRY(Don"t repeat yourself)原則

K.I.S.S(Keep It Simple, Stupid)原則