軟體開發人員的“七重苦”

　　軟體開發這個行業無疑的是有快樂的，但這篇文章裡，我們先不關注這些，而是要來看看那些讓人痛苦的地方。

　　有時候想想，人作為一種生物還是挺有意思的。

　　快樂的東西快樂過了，也就忘了，牢牢記住的反倒是些讓人不快樂的東西。

第一重：垃圾程式碼

　　佛家總講成住壞空，軟體亦莫能外。

　　唯一有點特別的是，軟體“住”的階段短，“壞”的階段來的快。

　　要想軟體保持不“腐敗”，其實要花的精力遠比想的多，這導致在商業利益比較強勢的世界裡，大多時候有的只是“能用就行”的軟體，而不是“好”的軟體。

　　“能用就行”的軟體裡，大多時候到處都是垃圾程式碼。　

　　如果說超過100行的方法/函式讓人痛苦的話，那麼時有出現的超過200行的方法/函式就是讓人絕望了。

　　不改不行，改了不知道對錯，一旦錯了很可能被抱怨。這就是垃圾程式碼帶來的痛苦。

　　軟體行業已經存在超過30幾年了，現存的軟體很多。所以軟體開發人員遇上垃圾程式碼的可能性絕對高於50%。

　　開源的世界要好很多，只可惜很多時候開源和飯碗的關聯有點艱難。

第二重：莫名其妙的加班

　　很多日程是把程式設計師的工作時間作為變數的。

　　簡單來講就是，要完成的工作是不確定的，但日程是確定的。

　　這樣一來，軟體開發人員必須加班。

　　但關鍵是一個人每天能寫的既定質量水平的程式碼大概就那麼多，一旦逼急了，只能放水，少想多做，進而貢獻更多的垃圾程式碼。

　　因此說，這類加班很莫名其妙：目的可能是節約成本，縮短工期，但實際上垃圾程式碼一出，大多時候是適得其反。

　　可以10人月做完的專案，只計劃投入5個人月，最終投入了15個人月的例子其實不少。

　　專案越複雜，越容易出現這種情況。

第三重：需求變化下的無用功

　　沒什麼比，費了很大力氣完成一項功能，結果收到的反饋是“這不是我們想要的”或“這個功能不需要了”更讓人洩氣了。

　　需求變化是正常的，迭代也是正常的，可無用功太多一定是不正常的。

　　但軟體這個行業中，這事似乎沒法根絕。

　　這也許根本就不是個技術問題，或者說不只是技術問題。

　　人有偏好，偏好在變化。世界有走勢，走勢在變化。這些都會傳導到軟體裡來，進而使無用功成為一種宿命。

第四重：選擇太多

　　在很多工程領域裡，確定性的東西比較多。但軟體開發裡恰恰相反，確定性較少，選擇太多。

　　這也許是好事，但有的時候確實也讓人痛苦。

　　假設說，我們要從頭開發一款軟體，那麼至少要做這些選擇：

　　▲用什麼語言？這好像很簡單，但如果真要很理智的去分析和選擇，其實很難，C++，C#，Java那個沒有自己的優勢呢。

　　▲用什麼框架？選新技術，可能支援不到位，也可能很快被淘汰；選老技術，可能會有些已知的限制。

　　▲是買還是自己造？買的話省時間，但一旦出問題，很可能導致專案卡殼。自己造的話，有可能時間上來不及。
　　… …

　　每次面臨這類問題時，都讓人感覺，世界很大，自己不過是一隻小小鳥。

　　其實選擇讓人難受的主要原因是自身知識與未知世界間的矛盾，但軟體的世界真的很大，一個人要想了解所有事情完全不可能。

　　所以痛苦的選擇題就總在那裡，不管你愛或不愛。

第五重：技術變化快，積累上不去

　　設想一下，一個10年前的高手，這10年他什麼也不學，那他今天會是什麼樣的一個狀況。

　　我個人估計是快被淘汰了。

　　這是個極端的例子，但回顧一下軟體的發展歷程你會發現，新技術的出現是爆炸式的。

　　在DOS的時代裡，軟硬體的距離非常近，你只要會一種語言，瞭解基本演算法和資料結構，再瞭解計算機硬體的知識，你就可以寫大部分的程式。

　　接下來軟體和硬體間的層次越來越多，Windows加上一層，Java虛擬機器加上一層，瀏覽器加上一層，Flash等再加上一層，諸如此類。

　　每多一層技術的種類就增加一些。這就導致軟體開發人員同時面對兩類壓力：一是專案上的時間壓力，一是技術更迭上的學習壓力。但偏偏一個的時間是有限的。

　　很多時候特定工作崗位會限定關聯技術的範疇，如果自身不做點安排，那就真成吃“青春飯”的了。

第六重：究竟誰幹的好，誰幹的不好

　　大多時候，考評不能每個人都打A，否則就成了吃大鍋飯的。

　　可在軟體的世界裡，一旦要分個你好他差，難度就出來了。

　　根據實績判斷，一個人很難全面理解很多人的工作。如果團隊規模少於10人，這類的判斷還存在可能性；如果超過10人，那麼誤判的機率會直線上升，除非是天才。

　　根據資料，大多資料真的不能用來評價軟體開發人員。生產率、Bug率這些是一定不行的，圈複雜度這類歧義性很小的指標勉強可用，但說明的問題會比較片面。

　　根據感覺和印象的話，多少有些草菅人命的感覺。

　　於是考評大多時候總是天怒人怨的考評，而天怒人怨的程度很多時候取決於當事人的在意程度。

第七重：弟兄們意見很多，統一很難

　　軟體很重要的一個特質就是仁者見仁，智者見智。

　　觀點的差異有的時候是是非問題，但大多時候是視角問題，是橫看成嶺側成峰式的。

　　而軟體團隊大多時候在兩個極端間徘徊：要麼沒意見，要麼很多意見。

　　很少有團隊會是在合適的時候有合適的意見—這是政治家乾的事，程式設計師不大做的來。

　　沒意見的團隊實是兵無戰心的團隊，其實更差，這裡不去說他。

　　有意見的團隊協調起來比較很辛苦。

　　程式設計師群體裡大致上是越優秀的越容易固執己見，所以大致上越優秀的團隊吵得越多，越凶。

　　但不管怎麼樣，最終的選擇只有一個。這時候，不能只靠行政力量去拍，要在理解各種想法後，結合外部需求，時間壓力，人員狀況去協調。

　　這事其實很不容易。

小節

　　一定程度上講，這七重苦很難根絕。

　　好多即將做軟體的或做的時間不長的同仁大多時候關注的是新技術，是創造性；但就和陽光下總有陰影一樣，不管方法如何更迭，總有些東西無法徹底改善。

　　所以想做軟體的，並想堅持做軟體的，要有點心理準備，不能夢想的太美，那樣回頭會比較失落。

　　風光的活是有的，髒活累活也很多，有了這樣的心理預期，才能在做軟體中找到快樂。

　　說了這麼多，倒不是悲觀。

　　有些問題即使沒法徹底解決，但程度上還是不一樣的。

　　痛苦在那種程度上是事在人為的主戰場，這點上做和不做差別很大。

　　假如一個人不把眼光只侷限於某個專案，而是把視野擴充套件到整個軟體開發所對應的方法論，那麼關注現實中的痛苦，則是有所得得前提。

來源：leezy_2000