想成為優秀的程序員這些碼德不能缺

我把這些看成是作為一個程序員的基本素質，多數是編碼之外的事情：

●代碼每天備份；（預防意外導致的任何損失）

●上傳代碼時寫清楚log信息；（為維護這個模塊的人著想，有可能是你自己）

●提供接口時不要把問題拋給使用接口的人，升級或者變更接口時不要刪掉原來的接口；（為使用你接口的同事著想）

●變量命名要見名知意；（起碼不能誤導別人）

●在工程中新建一個doc文件夾將項目相關的文檔放在該目錄下，方便后面維護的人員理解項目和代碼；（為維護這個模塊的人著想，有可能是你自己）

●簽署bug或者轉辦bug時寫明分析結果和轉辦原因；（讓測試員知道你的改動是否對其它功能有沒有影響，讓改這個bug的人知道你的分析結果和轉給他的原因）

●向身邊的同事或者在網上提問時，先要有自己的分析和思考；（不要浪費他人的時間）

●不私自接受功能變更，不私自增刪功能；（做一個執行者，決策會有該做決策的人去做）。

●離職或者換崗的時候做好工作交接；（善始善終）

回答者：鄔wlf，一切問題的根源都是交流障礙

作為一個在碼工界干過15年的人來說，最有碼德的事情我認為應該是絕不加班。

---------------

可能對于剛干這行不久的碼工來說，絕不加班就是逃避工作的代名詞。但是作為過來的老人很明確的告訴你，想做到這點還能安心的拿錢公司還不能對你嗶嗶啥是沒那么容易的。

一般來說，要加班趕工的項目，問題其實都出在最開始的階段，要么目標不明，要么跟用戶交流不暢，要么夸大海口結果給自己惹來一堆麻煩。而開始一旦出問題，造成的錯誤會形成累計效應，越到后面很可能越麻煩，甚至驗收后都無法收場。

剛 開始工作的時候，項目的談判都是由商務組的家伙去談的，這些家伙基本沒有什么節操，他們的收成只跟項目提成有關系，所以他們在談判的時候會答應不現實或者 很扯淡的技術要求，主動跳進對方給出的售后服務陷阱（比如說并沒寫明售后服務范圍和時間范圍）只為求快速簽署合同。甚至根本沒明白對方說了啥就拿回來一個 離題萬里的需求，反正只要工程驗收后他們就能拿到提成，所以他們并不在乎會帶來多大麻煩。這樣的干法就只會帶來無窮無盡的加班，哪怕你代碼寫的再好再利于 維護加班到猝死，都沒任何意義，因為從一開始就錯了。

后 來在我工作一段時間后，干掉了幾個難以驗收的項目。我這時候覺得不能放任那幫根本沒有軟件思維的家伙去跟客戶胡扯，我對boss表示開發人員應該參與商務 談判。而且事實證明本公司商務對客戶的思維理解經常都是離題萬里的，boss也早已被各種爛尾搞的頭痛不已。但是出于傳統（不讓技術人員跟客戶接觸，以避 免技術人員挖了客戶自己玩）他開始并沒有采納意見。但是有一次在大連做項目，本地的軟件公司已經做了客戶一部分的工作，boss利用關系半路截胡。本地公 司當然不愿意，然后兩邊開始撕比，本地公司要求我們完全包容他們的系統，而客戶急著趕快完工趕奧運的趟。這時候商務開始干瞪眼了，因為牽涉到了軟件問題， 這爛事丟在了我頭上。我去后跟對方客戶交流，客戶要求1個月內系統上線工作，而boss對我說的是你得讓客戶相信這破事一個月肯定做不完，這樣我們就能成 功的趕跑本地公司。我跟本地公司的技術總監胡扯了一晚上，對方年紀有些大了，最后被侃暈了承認1個月搞不完。然后這事就變成了本地公司出硬件，直接上咱們 的成熟軟件，一個月完成。

從 這事以后，boss才算看明白商務談判不能缺乏技術的重要性，后來數次工程，都先讓我去跟客戶談判。在清晰的了解客戶的需求，有了完整完善的前期設計和完 備清晰的驗收項目合同后，基本再也沒加過班。對于這種談判能力，其實是碼工的一個很好的轉型，畢竟代碼民工是不能長期干的，而這種跟人打交道的技術工作， 其實很適合碼工轉型。當然，你要是你很靦腆，見人就臉紅那就沒招了。我參與技術談判有幾點心得：你得完全了解你所在公司的軟硬件實力，明白有那些弱點和特 長，在談判的時候你得敏銳的分析出客戶的想法有那些可能會很難搞又沒有多大意義。你得引導客戶往本公司擅長的技術上去思考。你得引導客戶，而不是只聽客戶 怎么說你就怎么做。在我朝現在做軟件應用，3分看技術7分看人，應用性的軟件一般不追求技術上的頂級高端，出的問題多半在于人與人的交流錯誤上。你得做一 個擅長與人交流的碼工才能真正應付。

當然，你要是是做手機軟件之類玩人氣吸眼球的項目，我這套并不太適合。