做爲一個程序員要作的事

軟件開發中最艱鉅的任務其實並非代碼。寫代碼是一種鍛鍊，一種邏輯思惟上的鍛鍊，相比於開發人員在平常工做中要執行的其餘任務，它可顯得可愛多了。若是你以爲本身才剛剛跨入這個行業，只能算個業餘程序員，那麼爲了確保能躋身專業領域，有些障礙你必須得克服

一、解釋作了什麼
解釋軟件開發過程是很讓人崩潰的一件事。那些不會寫代碼的傢伙可能在這一行有所瞭解，可是正如定義所說的，他們不會寫代碼。在他們眼中，咱們就是一羣待在昏暗的房間中弓着背噼裏啪啦敲鍵盤的程序猿。搞很差你的朋友家人還有同事，甚至有可能會有編碼「不是正當職業」的想法呢，呵呵。
二、可視化解決方案假設給定一組簡單的——難聽點說就是考慮不周的——需求，你須要制定數據存儲庫、代碼結構、算法、通訊協議，以及只要能解決業務問題就得去完成的各類技術內容。而後，還須要用一種通俗易懂，哪怕是外行人也能明白的方式解釋出來，並在規按期限內交付給客戶。不多有開發人員能真正作好這一點。
三、預估交付時間
這是每一個開發人員的噩夢。試想一下，之前一點也沒有接觸過的任務，忽然要你肯定完成它所須要的時間，是否是有點天方夜譚呢？可能曾經也寫過相似的代碼，可是卻並非在有着相同問題和限制的同一個系統中，好吧！
這個時候，那真的只能靠經驗了。可是大多數程序員會低估時間，緣由多是由於他們只考慮了編碼這部分而忽略了其餘。
四、借鑑別人的代碼
條條大路通羅馬，解決方案也是。借鑑別人的代碼可能意味着要花上不少時間去研究上千行代碼以瞭解整個的思路。並且，要是恰巧原先的開發人員一點也不留註釋和文檔的話——甚至只是個半途而廢的半成品項目——那就更加使人頭大了
五、範圍蠕變和你自認爲神奇的功能
敏捷開發會形成範圍蠕變，這讓人既沮喪又無奈——特別是當你忽然心血來潮要加點什麼愚不可及的功能的話，更甚。結果如何你本身心知肚明，你的團隊也明白失敗沒商量。可是客戶其實知道得更清楚，因此要是失敗不可避免地降臨時，那麼就全都是你的責任，由於你竟然不相信客戶的眼光。
六、優化不足和過分優化之間的平衡
複雜的軟件永遠達不到完美的境界。咱們不可能無限制地優化，這也是爲何軟件項目從不在規定日期到來以前發佈的緣由。
另外一方面，不少人都會抱有「先就這樣吧——之後再來改進」的心態。如今這些代碼是能夠好好工做，可是這些人也明白這會成爲明日的煩惱和失敗。固然，你不會再來修復和調試了，它們會被留給下一個可憐的開發人員。
七、測試代碼
既能夠本身編寫單元測試，也能夠組團經過軟件來測試，不過不要妄想能發現全部bug……
複雜的軟件可能會包含成千上萬行代碼。系統可能有着數十億種可能的相互做用和路徑，想要所有測試是不可能的。一樣的，一個軟件在不一樣的條件下，不一樣的系統裏碰到的軟件不一樣，其交互的結果也不盡相同。咱們沒辦法測試全部可能的狀況。想要編寫出好的單元測試是一件既繁瑣又艱難的工做。在理想狀況下，測試應該在軟件開發項目開工以前就寫好——可是要是咱們先寫這個的話，咱們怎麼向客戶解釋四個星期過去了爲何一點進程都沒有？
單元測試不會突出顯示每個bug。雖然咱們都但願能有一個專門的小組來編寫測試而後積極去發現問題，可是因爲現實條件的限制——成本控制和時間限制，這對於不少項目而言都是奢望，因此大都須要開發團隊本身來編寫測試。而他們在編寫時老是會無心識地避免任何不穩當的邊界狀況。程序員會用一種邏輯方式去解決問題，可是用戶不多會這樣作；因此有時候用戶會幫咱們找到一些咱們本身察覺不出來或者根本想不到的問題。
八、寫代碼文檔
寫文檔的確是費時又費力。不多有開發人員擅長並願意花時間去寫/閱讀文檔。
九、處理硬件問題
咱們天天都須要處理各類技術問題，例如硬盤崩潰、驅動衝突、軟件故障等等。雖然這並不是是咱們軟件開發人員的工做，可是要是不解決這些的話，咱們是無法繼續工做的。
然而不少人卻會莫名其妙地認爲，搞IT的就應該懂全部關於電腦的東西。當他們碰到問題，他們第一時間想的就是聯繫咱們來解決，並且無論什麼問題都這樣，真心是讓人無語又崩潰。
固然這些中斷時間不該該對交付進度產生影響或者增長成本，可是這可能嗎？
十、和人打交道
上述任務統統能夠總結爲「如何與人打交道」。使人奇怪的是，非專業人士不會去指點飛行員應該如何駕駛飛機，也不會跑去和電工說個人房子須要從新佈線等等，可是他們卻很是喜歡在軟件開發上面指手畫腳，提供各類異想天開的點子。
關於這一點，我還真提不出什麼好的解決方法，因此，唉，各位，咱們仍是接受有一半的地球人他們的IQ低於平均值的事實吧！

還有更多豐富編程語言教程集合盡在e良師益友網。