慎于說Yes

　　在沒有搞清楚開發需求、任務工作量、團隊期望值之前，有前途的程序員不會輕易答應。特別是對于新人來說，比較急于表現自己，對于同事或者老板的工作安排來者不拒，精神可嘉，方法不可取。承諾太多，會出現自己無法按時完成的情況，即使按時完成，也可能沒有達到別人的期望值，長期以往別人對你的失望會越來越多。

　　敢于說No

　　看起來和第一條雷同，其實細究起來不一樣。第二條執行起來比第一條難得多。當遇到明顯不合理的要求時，可以考慮拒絕，前提是準備好了全面充分的理由。不要經常說No，但是一旦說了，就要切中要害。有前途的程序員不會悶頭干活，知道自己的定位和團隊期望，分清楚哪些是不合理的要求，哪些是合理的要求，然后把明顯不合理的要求和領導溝通下，取得支持。

　　構建自己的知識體系

　　在信息爆炸的年代，碎片化的知識很多，系統學習的時間越來越少，如果沒有自己的知識體系，很容易被淹沒在知識的海洋中，而且難以記憶。100分程序員推薦的做法，通過Wiki或者其他知識管理工具構建一個知識框架，大的分類可以包括軟技能、架構、語言、前端、后端等，小的分類可以更細化。

　　培養大局觀

　　程序員比較容易陷入的困境是專注于自己的一畝三分地，不關心團隊的進度和業績，也不關心軟件的整體架構和其他模塊。這種狀態長期下去沒有好處，特別是在大公司中，逐漸成長為一顆螺絲釘。100分程序員會在工作之余，多看看其他在做什么，看看團隊的整體規劃，看看軟件系統的架構和說明文檔。對自己的工作更理解，而且知道為什么這個產品應該這樣設計，為什么領導應該這樣做規劃，這種大局觀非常有利于自己的職業生涯。

　　代碼規范

　　程序員在新手時期需要培養良好的代碼規范。最直接的辦法，遵循公司已有的代碼規范(如果沒有類似的規定，也是醉了)，從簡單的變量命名到模塊劃分，有些規則可以導入到編碼工具中，更多的部分需要自己體會和遵守。關于此方面的知識，最權威的書籍是《代碼大全》，別誤會，書名是個美麗的錯誤，里面不是代碼集錦。對于新手來說，養成一個統一的編碼風格非常重要，是基礎一步。

　　代碼審查

　　把這個單獨拎出來說，是因為對于程序員來說很重要。很多快速成長的公司沒有這個步驟，建議大家能夠堅持下來。讓別人審查自己的代碼，可以得到更多的反饋，也是和同事交流的好機會;審查別人的代碼，可以借鑒別人的經驗和思路。通常情況下，代碼審查比自己寫代碼的收獲更大，對于新手來說更有價值。只要你想做，不論形式是不是正規，都可以執行下去，最好形成團隊的習慣。

　　一個時間段內只專注于一種類型的語言

　　如果你正在設計或開發網站，你將需要同時熟悉多種不同的語言。你可能會想同時學習所有的這些語言，特別是考慮到它們是如何相互關聯的。

　　我想，在某種程度上，這是不可避免的。但如果你真的想快速提高，我建議你專注于一個特定領域的專業知識。你想更好地利用CSS?把你的重點放在這一點。嘗試使用一個單一的HTML文檔只使用CSS實現不同的布局。 CSS Zen Garden 是一個使用相同布局實現不同頁面樣式非常棒的例子。你也可以通過查找元素的列表，并把精力集中在里面。舉個例子來說，你熟悉CSS2，但想提升對 CSS3 的理解，你可以學習CSS3屬性并逐一的實現它們。你可以閱讀當前的 CSS3規范 ，還可以通過每個模塊的學習來了解它在瀏覽器上能(或不能)做什么。

　　通過注釋來寫邏輯

　　說到編碼，我有堅持很多原則和想法。其中一個就是，代碼中95%都是邏輯。另一個就是從人類語言到編程語言，邏輯并沒有改變。

　　這也就是意味著，如果你能在代碼中寫出來，也就可以用英語或者其他語言寫下來。

　　良好的時間管理

　　遲到對于任何一家公司都是個頭痛的問題。作為一個程序員，有時候為了完成任務常常不得不熬夜，從而導致第二天上班就遲到了。但是我們忽略了這一點，我們的工作時間至關重要，因為在這段時間里我們要和客戶同步，也要與團隊其他成員一齊協作。

　　深入理解客戶需求

　　僅僅了解單一用戶的表面意思是遠遠不夠的。一個偉大的程序員應該具備能把繁瑣的要求理解并分解成項目的技術任務或子任務的能力，并且最后拿到的成果應精確滿足客戶的需求。

　　絞盡腦汁還是“NO”

　　假如抓耳撓腮還是找不出解決辦法，我們該如何是好?一個偉大的程序員應該足智多謀，能靈活應對困境。他們會去詢問同事，或者是向團隊領導者請教;在互聯網上面搜索，然后耐下心來一遍又一遍地試驗。相信山窮水盡疑無路，柳暗花明又一村，投降兩個字從未出現在他們的字典上。

　　編程之前準備好全套算法

　　親~還記得我們老師逼我們畫的流程圖嗎?還記得一個個案例和偽代碼嗎?他們都是灰常重要的軟件開發手段。一個偉大的程序員如果木有事先準備好算法，那他會不會像個傻小子似的只顧寫代碼呢?所以，在開工之前，做好全套的算法是必須的。

　　理解and幫助定義驗收標準

　　是否需要高成次測試腳本是產品所有者決定的，但是，作為一個偉大的程序員必須能夠編寫技術測試腳本，并且也要認識到如果跳過了這一步驟可能會帶來的后果。

　　主動一點點

　　一個優秀的程序員不需要別人告訴他該做什么，他的主動性要比別人強一些，他可以自覺的關注流程，提高應用程序的靈活性以及快速的解決開發過程中出現的Bug。