開發人員容易陷入這樣一種魔怔的狀態：技術為大，編碼為重，其他都是浮雲。但其實縱觀軟體的生命週期，從需求分析到後期維護更新，每一步都有講究。編碼，並不是唯一。這個感受在我拜讀了鄒欣老師的《構建之法》後更為深刻。
萬事開頭難，需求分析作為軟體開發的開始，自然也是令人頭疼。說真的在學校做課設時，我十分反感小組成員嘩啦啦扯一大堆亂七八糟的跟想象作文似的需求分析。但進了公司，做實際專案的時候，需求分析有助於快速定位使用者，定位功能，因而十分必要。
做軟體總不能漫無目的吧？你得搞清楚目標使用者是什麼人，才能逐步明確軟體要做成什麼樣。設計出幾個典型使用者，我們就對潛在使用者的年齡、工作、習慣、喜好等一系列特徵有了乙個初步的認識。
而且不同的典型使用者可能會有不同的潛在行為。舉個例子，以某款動作類遊戲來說：玩家a是個畫面黨，那麼遊戲最好精美一些，如果人物建模和裝備設計得相當好看，即使是付費道具，玩家a也可能心甘情願地買單；玩家b爭強好勝，在很多遊戲的排行榜中名列前茅，如果推出數值強勁的角色和裝備，那麼玩家b為了追求更靠前的名次很大可能會掏錢。但不同的典型使用者都要使用你這款產品，證明典型使用者也是存在共同點的——玩家都是動作類遊戲愛好者。不管怎麼說，你這款遊戲是動作類遊戲，那就要求人物動作要流暢連貫自然，這一核心不能丟失。
但典型使用者畢竟還是單方面意淫的產物，在實際生活中，使用者所想可能與你有很大出入。
那麼如何蒐集使用者需求呢？比較常用的方法是問卷調查。目前問卷調查的題型以多選題和順位選擇題為主，畢竟沒有多少人願意浪費自己的時間打字來回答開放式問題。但選擇題不一定能覆蓋所有可能的使用者需求，因而調查問卷的設計也十分重要。
怎麼讓別人乖乖填調查問卷呢？獎勵——比如說贈送會員，贈送軟體內通用貨幣。我玩過的一款遊戲很雞賊，每次玩家填寫調查問卷後都會得到數量可觀的水晶——這個遊戲中十分難以獲取的貨幣，而水晶又是能換取強力角色和裝備的唯一途徑。這樣，變強是你的最終目標，獲取水晶是你的中間目標，你自然而然就會去填寫問卷了。
採集到資料，問題又來了——怎麼確保資訊的真實性？如果使用者只是為了拿到獎勵，那他(她)完成問卷花費的時間可能不超過十秒。。。這樣不經思考的資料有價值嗎？所以也許要借助一些技術手段，判斷使用者是認真完成還是隨手一填。需要注意的是，這一步絕不能放到使用者填寫問卷的過程之中。如果使用者填寫完發現拿不到獎勵，那十有**也不會再用你的軟體了。
使用者是核心，因而設計要回歸到使用者角度。使用者是些什麼人？十有**是不太懂開發的，他們只想借助軟體實現自己的目標，所見即所得，你不能整出個按開發人員思維操作的軟體把普通使用者看的一愣一愣的，那就直接勸退使用者，拱手送人了。所以私認為把使用者當傻子的設計理念就很好，軟體的介面越清晰，操作越簡單，使用者的認知阻力就越小，體驗也就越棒。
對使用者而言，軟體好看、好用就行了。而好用是建立在好看的基礎上的，開發人員實現了許多炫酷的功能並暗自得意，但使用者看到你這亂七八糟綠的發慌的ui恨不得一手機呼你臉上。ui的各個部件之間應有明顯區分，但整體在大小、顏色、形狀上要和諧統一。這裡主要強調乙個美觀的ui有多麼重要，不過多贅述。
應用市場裡形形色色的軟體那麼多，你這款軟體release之後要能get並消除使用者痛點，使用者靠你的產品切實能解決問題，靠別人的不行，這就形成了人無我有的優勢。如果大家都有，那就做到最好，這也是優勢。
拿小公尺來說，早期發家靠的是什麼？旗艦機的配置卻只要旗艦機一半的**，搭載了相同的旗艦soc，小公尺幾乎總是售價最低的那個。再後來，小公尺有了自己的生態，公尺家推出的各種智慧型家居物美價廉。極致價效比，完善的生態。這就是小公尺的優勢。
類似於寫作文時每段首行要縮排兩格，敲**前也要規定好格式規範，所有開發人員都要按照這個規範來編碼。機器不用管**格式，只要語法邏輯無誤就可以執行，但程式設計師是人，過於難看的排版會讓人逐漸失去耐心。誰都不想對著一堆i，j，a，b猜測變數和方法的含義，這就對程式設計師的英語水平提出了要求。寫字好看能給人留下好的印象，好的命名習慣亦是如此。
每個人思考問題的方式不同，**寫得再清楚，有時也容易產生錯誤理解。所以，為了有助於他人理解，注釋是一定要寫的。這樣後期維護時也會節約不少時間，沒有人能清楚地記得幾個月前敲了些什麼。注釋具有時效性，一定要隨著專案更新而更新，乙個錯誤的注釋比沒有注釋更具誤導性。
雖然不是每個公司都有比較完備的團隊，但整個公司只有乙個開發人員的情況應該並不多見。如果和同事關係還不錯，可以試試兩人合作的開發模式：一人敲**，一人在旁檢查錯誤，如此輪替。這樣思路出現問題時可以及時得到糾正(兩人都具備一定實力的情況下)，不會出現完成乙個模組後才發現問題又要大規模修改的情況，減少了修改和重構的時間。但結對程式設計也容易加深矛盾，如果乙個人巴拉巴拉說個不停，那正在編碼的同事絕對想一鍵盤呼過去。。。因此，交流頻率和交流時長都要適當控制。在予以他人反饋時，應盡量對他人的行為和後果作出客觀評價，避免對他人的本質和固有屬性進行攻擊。
國內一直有這樣的誤區，覺得最新的技術就是最好的。其實不同的技術各有所長，適用於不同的領域。python是近幾年的產物嗎？並不是，只是時代發展到恰好需要它而已。很多時候，已經發布幾年的成熟技術才是更好的選擇。結合自己的經驗，選擇合適的技術才是王道。
需求是千變萬化的，可能今天是根據使用者心情改變手機殼顏色，明天就是根據使用者髮色改變桌布。做好需求文件再開發顯然已經不適應瞬息萬變的時代。因此，即刻開始->每日開會討論變動情況->根據變動修改**的「敏捷」開發模式成為了主流。編碼人員要預留位置來應對可能的需求變動和增加，同時保證專案處在乙個隨時可交付的狀態。隨時變動，隨時交付，更強調適應性而非預見性，這是「敏捷開發」的優勢所在。
上面提到的這些，提高**可讀性也好，敏捷開發應對變動也好，都是為了能夠第一時間將專案交付給客戶。如果每天的開會流於形式，這對加快進度起不到任何作用。同理，如果乙個公司的績效根據**行數來評定，那趁早離開比較好。每一行**都要盡可能高效地完成它的任務。只要你願意，一行**可以拆成五行來寫，但這真的有意義嗎？
「千里之堤毀於蟻穴」，就算是測試中無法復現的bug和影響較小的bug，私認為仍有必要盡早解決。上面已經提到，在解決bug的同時要注意更新注釋。有些人喜歡給發現的bug打上標記，然後繼續其他工作，但時間一長，誰還能記得這個bug是待解決還是已解決？不如發現乙個，消滅乙個，這也是效率的體現之一。
程式設計師所寫的**應盡量交給他人複審和測試，在你敲打鍵盤時，你已經預設自己的思路沒有問題，所以，找自己的bug是最為困難的，但是分析他人**時，我們往往會更加客觀一些。
有條件的話，程式一定要有beta版(公測版)。帶入使用者的角色進行操作，很多人開發或測試做久了，這一能力會漸漸喪失。這也體現出乙個好的測試人員是多麼難得：工作需要時，能把自己突然變成乙個完全不懂技術的人。既然產品最終服務於使用者，那麼使用者所做的測試才最為真實。
在《構建之法》裡，處處體現著匠心。軟體開發是一項工程，更是一項藝術。在技術足夠的情況下，付之以匠心，輔之以方**，把產品當作藝術品去完成，個人能力將得到極大的提公升。
Android筆記之 以JSON方式與伺服器通訊
1.json資料結構 在json 中有兩種資料結構 物件和陣列。1.1物件 在json 中，乙個物件以 右括號 結束。每個 名稱 後跟乙個 冒號 冒號後是該名稱的值，多個 名稱 值 之間使用 逗號 分隔開來。名稱需要使用雙引號括起來，值如果是字串則必須用雙引號括起來，如果是數值型則不需要。其結構示意...
動態建立控制項及以迴圈賦值之四
來自本論壇問題的答覆 for int i 0 i 4 i i 1 zh.location new point 100 i,17 this.controls.add zh this.refresh control.controlcollection 文字框 this.controls foreach ...
DSC模組之Modbus通訊（以PLC為例）
主要軟體 labview modules labview dsc module 主要軟體版本 2011 sp1 主要軟體修正版本 n a 次要軟體 driver software comedi drivers 問題 我有幾台自動化裝置，通過modbus通訊的，我可以用labview來做上位機程式控制...