看到這個話題題目，文率科技的小編不禁想轉(zhuǎn)載，天津網(wǎng)站建設大部分以銷售為路線，而文率科技證實走著技術路線，幫助企業(yè)或者個人解決更多技術方便的問題，也正是做著沒有問題的技術。所以文率科技的程序員相對比較多，而程序員也是一個可愛的群體，也是一個比較特殊的群體，他們因為長期和電腦打交道所養(yǎng)成的性格和脾氣也是比較相近的。當然，既然是人，當然是會有性格的，也是會有脾氣的。下面讓我們看看讓程序員比較抓狂的事情吧；
第十位 程序注釋
程序注釋本來是一些比較好的習慣，當程序員老手帶新手的時候，總是會告訴新手，一定要寫程序注釋。于是，新手們當然會聽從老手的吩咐。只不過，他們可能對程序注釋有些誤解，于是，我們經(jīng)常在程序中看到一些如下的注釋：
每當看到這樣的注釋——只注釋是什么，而不注釋為什么，相信你一定會被惹火，這是誰寫的程序注釋?。坎徽襾砹R一頓看來是不會解氣了。程序注釋應該是告訴別人你的意圖和想法，而不是告訴別人程序的語法，這是為了程序的易讀性和可維護性，這樣的為了注釋而注釋的注釋，分明不是在注釋，而是在挑釁，惹毛別人當然毋庸置疑。
|
1
2
3
4
5
6
7
|
r = n/2; // r 是 n 的一半
//循環(huán)，僅當 r- n/r 不大于 t
while((r-n/r) <=t){
//… …
r = 0.5 * (r-n/r);// 設置 r 變量
}
|
第九位 打斷
正當程序沉浸于編程算法的思考，或是靈感突現(xiàn)正在書寫程序的時候，但卻遭到別人的打斷，那是一件非常痛苦的事情，如果被持續(xù)打斷，那可能會讓人一下子就煩躁起來。打斷別人的人在這種情況下是非常不禮貌的。被打斷的人就像函數(shù)調(diào)用一下，當其返回時，需要重新恢復斷點時的現(xiàn)場，當然，人不是電腦，恢復現(xiàn)場通常是一個很痛苦的過程，極端的情況下可能需要從頭開始尋找思緒，然后一點一點地回到斷點。
因此，我看到一些程序員在需要安靜不被打擾的時候，要么會選擇去一個沒人找得到的地方，要么會在自己的桌子上方高掛一個條幅以示眾人——“本人正執(zhí)行內(nèi)核程序，無法中斷，請勿騷擾，謝謝！”，可能正在沉浸于工作的程序被打斷是多么大的開銷。自然，被打斷所惹毛了的人也不在少數(shù)了。
第八位 需求變化
這個事情估計不用多說了。只要是是程序員，面對需求變化的時候可能總是很無奈的。一次兩次可能還要吧接受，但也頂不住經(jīng)常變啊。據(jù)說敏捷開發(fā)中有一套方法論可以讓程序員們享受需求的變化，不知道是真是假。不過，今天讓你做一個書桌，明天讓你把書桌改成餐桌，后天讓你把餐桌改成雙人床，大后天讓你把床改成小木屋，然后把小木屋再改成高樓大廈。哎，是人都會被惹毛了的。那些人只用30分鐘的會議就可以作出任何決定，但后面那幾十個程序員需要搭上幾百個小時的辛苦工作。如果是我，可能我也需要神獸草泥馬幫助解解氣了。
不過，這也正說明了，程序員并不懂得怎么和用戶溝通，而用戶也不懂得和程序員溝通，如果一個項目沒有一個中間人（如：PM）在其中協(xié)調(diào)的話，那么整個項目可能就是“雞同鴨講”，用戶和程序員都會被對方所惹毛了。如果要例舉幾個用戶被惹毛的事情，估計程序員的那種一根筋的只從技術實現(xiàn)上思考問題的方法應該也能排進前5名。
第七位 經(jīng)理不懂技術
外行領導內(nèi)行的事例還少嗎？領導一句話，無論對不對，都是對的，我們必需照做，那怕是多么愚蠢多么錯誤的決定，我們也得照做。程序員其實并不怕經(jīng)理不懂技術，最怕的就是不懂技術的經(jīng)理裝著很懂技術。最可氣的是，當你據(jù)理力爭的挑戰(zhàn)領導權威的時候，領導還把你視為異類。哎，想起這樣的領導別說是罵人了，打人的沖動都有了。
其實，經(jīng)理只不過是一個團隊的支持者，他應該幫助團隊，為團隊排憂解難。而不是對團隊發(fā)號施令。其實管理真的很簡單，如果懂的話，就幫著做，如果不懂的話，就相信下屬，放手讓下屬做。最怕的就是又不懂技術，還不信任下屬的經(jīng)理了。哎，這真是程序員的痛啊。
第六位 用戶文檔
用戶文檔本來不應該那么的令人害怕。這些文檔記錄了一切和我們所開發(fā)的軟件有關的一些話題。因為我們并不知道我們所面對的用戶的電腦操作基礎是什么樣的，所以，在寫下這樣的文檔的時候，我們必需假設這個用戶什么也不懂。于是，需要用最清楚，最漂亮的語言寫下一個最豐富的文檔。那怕一個拷貝粘貼的操作，可能我們都要分成五、六步來完成，那怕是一個配置IP地址的操作，我們也要從開始菜單開始一步一步的描述。對于程序員來說，他們在開發(fā)過程中幾乎天天都在使用自己開發(fā)的軟件，到最后，可能都有得有點吐了，但還得從最簡單的部份寫這些文檔，當然容易令他們煩燥，讓程序員來完成這樣的文檔可能效果會非常不好。所以，對于這樣的用戶文檔，應該由專門的文檔人員來完成和維護。
第五位 沒有文檔
正如上一條所說的，程序員本來就不喜歡寫文檔，而因為技術人員的表達能力和寫作能力一般都不是太好，所以，文檔寫的也很爛?？纯撮_源社區(qū)的文檔可能就知道了。但是，我們可愛的程序員另一方面最生氣的卻是因為沒有文檔。當然，讓面說是的用戶的文檔，這里我們說的是開發(fā)方面的文檔，比如設計文檔，功能規(guī)格，維護文檔等等。不過，基本上都是一樣的。反正，一方面，我們的程序員不喜歡寫文檔，另一方面，我們的程序又會被抱怨沒有文檔，文檔太少，或者文檔看不懂。呵呵。原來在抱怨方面也有遞歸啊。據(jù)說，敏捷開發(fā)可以降低程序開發(fā)中的文檔，據(jù)說他們可以把代碼寫得跟文檔和視圖似的，不知道是真是假。不過，我聽過太多太多的程序員抱怨沒文檔太少，文檔太差了，這個方面要怪還是怪程序員自己。
第四位 部署環(huán)境
雖然，程序員們開發(fā)的是軟件，但是我們并不知道我們的程序會被部署或安裝在什么樣的環(huán)境下，比如，網(wǎng)絡上的不同，RAID上的不同，BIOS上的不同，操作系統(tǒng)的不同（WinXP和Win2003），有沒有殺毒軟件，和其它程序是否兼容，系統(tǒng)中有流氓軟件或病毒等等。當然，只要你的軟件出現(xiàn)錯誤，無論是你的程序的問題，還是環(huán)境的問題，反正都是你的問題，你都得全部解決。所以，程序員們并不是簡單地在編程，很多時候，還要當好一個不錯的系統(tǒng)管理員。每當最后確認問題的原因是環(huán)境問題的時候，可能程序員都是會心生怨氣。
第三位 問題報告
“我的軟件不工作了”，“程序出錯了”，每當我們聽到這樣的問題報告的時候，程序員總是感到很痛苦，因為這樣的問題報告等于什么也沒有說，但還要程序員去處理這種錯誤。沒有明確的問題描述，沒有說明如何重現(xiàn)問題，在感覺上，當然會顯得有點被人質(zhì)問的感覺，甚至，在某些時候還摻雜著看不起，訓斥的語氣，當然，程序員基本上都是很有個性的，都是軟硬不吃的主兒，所以，每當有這樣的語氣報告問題的時候，他們一般也會把話給頂回去，當然，后面自己然發(fā)生一些不愉快的事情。所以，咱們還是需要一個客服部門來幫助我們的程序員和用戶做好溝通。
第二位 程序員自己
惹毛程序員的可能還是程序員自己，程序員是“相輕”的，他們基本上都是持才傲物的，總是覺得自己才是最牛的，在程序員間，他們幾乎每天都要吵架，而且一吵就吵得臉紅脖子粗。在他們之間，總是被自己惹毛。
程序員，長期和電腦打交道，編寫出的代碼電腦總是認真的運行，長期養(yǎng)成了程序員們目空一切的性格，卻不知，這個世界上很多東西并不是能像電腦一樣，只要我們輸入正確的指令它就正確地運行這么簡單。程序員，什么時候才能變成成熟起來……
⑴位 程序員的代碼
無論你當時覺得自己的設計和寫的代碼如何的漂亮和經(jīng)典，過上一段時間后，再回頭看看，你必然會覺得自己的愚蠢。當然，當你需要去維護他人的代碼的時候，你一定要在一邊維護中一邊臭罵別人的代碼。是否你還記得當初怎么怎么牛氣地和別人討論自己的設計和自己的代碼如何如何完美的？可是，用不了兩年，一剛從學校畢業(yè)的學生在維護你的代碼的過程當中就可以對你的代碼指指點點，讓你的顏面完全掃地。呵呵。當然，也有的人始終覺得自己的設計和代碼就是較好的，不過這是用一種比較靜止的眼光來看問題。編程這個世界變化總是很快的的，很多事情，只有當我們做過，我們才熟悉他，熟悉了后才知道什么是更好的方法，這是循序漸進的。所以，當你對事情越來越熟悉的時候，再回頭看自己以前做的設計和代碼的時候，必然會覺得自己的膚淺和愚蠢，當然看別人的設計和代碼時，可能也會開始罵人了。
補充一條，程序員是一個高度工作壓力的群體，一個愛好技術的程序員更是如此，對于技術的專注是常人無法理解的，甚至有時候外人讓他們休息休息 對于他們都可能士讓他們煩得事情，因為當他們專注于一件事的時候，難以自拔。
