軟件開發(fā)人員的“七重苦”(1)
作者:網絡轉載 發(fā)布時間:[ 2012/2/8 10:29:34 ] 推薦標簽:
軟件開發(fā)這個行業(yè)無疑的是有快樂的,但這篇文章里,我們先不關注他,而是要來看看那些讓人痛苦的地方。
有時候想想,人作為一種生物還是挺有意思的。
快樂的東西快樂過了,也忘了,記的牢的的反倒是些讓人不快樂的東西。
第一重:垃圾代碼
佛家總講成住壞空,軟件亦莫能外。
有點特別的是,軟件“住”的階段短,“壞”的階段來的快。
要想軟件保持不“腐敗”,其實要花的精力遠比想的多,這導致在商業(yè)利益比較強勢的世界里,大多時候有的只是“能用行”的軟件,而不是“好”的軟件。
“能用行”的軟件里,大多時候到處都是垃圾代碼。
如果說超過100行的方法/函數(shù)讓人痛苦的話,那么時有出現(xiàn)的超過200行的方法/函數(shù)是讓人絕望了。
不改不行,改了不知道對錯,一旦錯了很可能被抱怨。這是垃圾代碼帶來的痛苦。
軟件行業(yè)已經存在超過30幾年了,現(xiàn)存的軟件很多。所以軟件開發(fā)人員遇上垃圾代碼的可能性高于50%。
開源的世界要好很多,只可惜很多時候開源和飯碗的關聯(lián)有點艱難。
第二重:莫名其妙的加班
很多日程是把程序員的工作時間作為變量的。
簡單來講是,要完成的工作是不確定的,但日程是確定的。
這樣一來,軟件開發(fā)人員必須加班。
但關鍵是一個人每天能寫的既定質量水平的代碼大概那么多,一旦逼急了,只能放水,少想多做,進而貢獻更多的垃圾代碼。
因此說,這類加班很莫名其妙:目的可能是節(jié)約成本,縮短工期,但實際上垃圾代碼一出,大多時候是適得其反。
可以10人月做完的項目,只計劃投入5個人月,終投入了15個人月的例子其實不少。
項目越復雜,越容易出現(xiàn)這種情況。
第三重:需求變化下的無用功
沒什么比,費了很大力氣完成一項功能,結果收到的反饋是“這不是我們想要的”或“這個功能不需要了”更讓人泄氣了。
需求變化是正常的,迭代也是正常的,可無用功太多一定是不正常的。
但軟件這個行業(yè)中,這事似乎沒法根絕。
這也許根本不是個技術問題,或者說不只是技術問題。
人有偏好,偏好在變化。世界有走勢,走勢在變化。這些都會傳導到軟件里來,進而使無用功成為一種宿命。
第四重:選擇太多
在很多工程領域里,確定性的東西比較多。但軟件開發(fā)里恰恰相反,確定性較少,選擇太多。
這也許是好事,但有的時候確實也讓人痛苦。
假設說,我們要從頭開發(fā)一款軟件,那么至少要做這些選擇:
用什么語言?這好像很簡單,但如果真要很理智的去分析和選擇,其實很難,C++,C#,Java那個沒有自己的優(yōu)勢呢。
用什么框架?選新技術,可能支持不到位,也可能很快被淘汰;選老技術,可能會有些已知的限制。
是買還是自己造?買的話省時間,但一旦出問題,很可能導致項目卡殼。自己造的話,有可能時間上來不及。
... ...
每次面臨這類問題時,都讓人感覺,世界很大,自己不過是一只小小鳥。
其實選擇讓人難受的主要原因是自身知識與未知世界間的矛盾,但軟件的世界真的很大,一個人要想了解所有事情完全不可能。
所以痛苦的選擇題總在那里,不管你愛或不愛。
相關推薦

最新發(fā)布
性能測試之測試環(huán)境搭建的方法
2020/7/21 15:39:32軟件測試是從什么時候開始被企業(yè)所重視的呢?
2020/7/17 9:09:11Android自動化測試框架有哪些?有什么用途?
2020/7/17 9:03:50什么樣的項目適合做自動化?自動化測試人員應具備怎樣的能力?
2020/7/17 8:57:06幾大市面主流性能測試工具測評
2020/7/17 8:52:11RPA機器人能夠快速響應企業(yè)需求,是怎么做到的?
2020/7/17 8:48:05Bug可以真正消滅嗎?為什么?
2020/7/17 8:43:03軟件測試基本概念是怎么來的?軟件測試生命周期的形成歷經了什么?
2020/7/16 9:11:10