寫在前面：「難怪這幫程式設計師這樣讓人瞧不起！做的東西直接反映人品！」
前段時間與公司同事分享過一篇文章叫做《阿里軟體資深架構師談：開發者的人品問題》( )，本來目的是引導程式設計師用心為使用者寫**，結果沒有起到任何可見的效果。以前開會我反覆強調，以使用者的角度和身份為使用者寫**而不是理所當然的去憑自己感覺瞎寫，「把自己的**當作自己的孩子」，真正的為使用者解決問題，少給使用者製造麻煩。也不知道開發人員的leader們有沒有認真去落實，似乎開發和運維的矛盾與生俱來，自己也不願意過多的干涉他們的事情。我自己感覺乙個優秀的程式設計師不用別人一直強調**質量，自己就能從某一點上得到啟示不斷改進和完善。
做乙個有原則性、嚴格要求自己的程式設計師。我雖然不是乙個專業從事寫**的程式設計師而是乙個ops，但也以程式設計師的身份寫過許許多多的shell指令碼和無法計數的命令列，但幾乎很少出錯（甚至使用過程中沒出過錯），為什麼？拋開所使用的程式語言的簡單和過程化講原因是在寫的過程中我既是coder又是使用者，我是在為自己寫**，寫完了自己要先用，直接測試，有問題直接解決問題，決不會使用乙個有明顯可見bug的指令碼。
拿bug的必然性逃避自身的問題是堅決不能容忍的！雖然我的php水平還停留在面向過程，不懂得如何使用框架和物件導向進行提高程式設計效率縮短研發週期，但我深深的明白php coding的簡單。凡是程式就有bug，bug在所難免，出現問題並不可怕，可怕的是推卸責任和強調理由，這種態度無法容忍。
開發人員自身要擔當起qa的角色。我們雖然是有qa，但說白了那是不會開發甚至不懂開發的qa，她們對qa的理解甚至還沒有程式設計師們了解的透徹，程式設計師自己寫**從來不進行單元測試麼？寫出的**不親自測試一下嗎？更有甚者，開發不建模，不進行產品規劃，沒有研發方案，沒有使用手冊，沒有公升級修訂記錄，沒有bug記錄，這聽起來多麼可怕啊，簡直是被一道春雷驚嚇了的感覺！相信公司內很多人的軟體工程是白學了！
辦法總是有的。解決辦法不是沒有，程式設計師首先必須清醒認識到問題，端正態度積極解決問題，不要怕別人提出批評，充分發揮自己的主觀改進意識完善自我。leader們要積極參與引導工作，做好團隊建設，反覆強調**質量的重要性，哪怕是減少功能甚至導致專案滯後也要保證產品的可用性。我們不怕裁員，現在還有近40個研發人員，程式設計師不合適的裁掉程式設計師，leader不合適的乾掉leader，辦法總是有的！
此外程式設計師也要進行績效考核，主要一條就要規定根據bug的嚴重程度要扣除相應的績效得分，儘管這樣很殘酷很影響團隊和個人情緒，但也是沒辦法的辦法。現在這種產品出錯不算什麼，既不是金融計算也不是電子商務，但一旦不進行適當引導和約束就不能生產出符合使用者需要的產品。
尾記：先前跟qa團隊討論，「你們認為什麼是程式設計的第一要素？」當時有一位小姑娘說是「產品的可用性」，最終也沒有乙個確定的答案，我給的答案是「一切以使用者為中心」。不知道大家如何看待此問題，歡迎提出各位自己的看法！ps：我寫文章不能像省委書記的秘書一樣字字斟酌反覆修改，但我也會努力靠近他們的寫作水準，甚至努力擁有像省委書記一樣的胸懷，各位權當是看笑話了，有不當之處請批評指正！
最後以佛語中我認為最著名最核心的一詞結束此文章，謹牢記「因果報應」！
做乙個更好的程式設計師
1.做最壞的打算 不管你工作中使用哪種程式語言，第乙個任務就是你應該寫乙個用於列印錯誤的函式。2.為忘記做好準備 寫程式時，同時也寫好完整的注釋，以備你六個月後重新來讀這段程式還能再讀懂，並且你能夠通過它告訴所有人你的程式是如何實現的。3.文件 在你的程式 檔案中包含文件，並把它放到程式 的相應目錄...
做乙個程式設計師的條件
曾經，我以為做乙個程式設計師是最輕鬆而有趣的。程式設計師們擁有和計算機同樣的神秘感，並可以控制計算機做自己想做的事。但實際情況已經和數十年前不同了，那個整台計算機只有64k ram的時代已經遠去了，我們正在日益被瘋長的 與程式所淹沒，從而變成計算機的奴隸。所以說現在做程式設計師可不是一件簡單的事，至...
做乙個真正的程式設計師！
大學學習的是軟體程式設計專業，都快畢業了，其實給我的感覺，也就學到了點皮毛，大學老師估計也有諸多矛盾，開課學習計算機深層次的東西吧，學生畢業又不是搞學術研究的，總不能一畢業就失業 學習流行的吧，那大學和培訓機構的差別在 流行的開發技術老師好些都沒有碰過，還沒有培訓機構講的使用。所以大學深的沒有深入，...