隨著做軟體的時間越來越長，我發現，做軟體越來越難。難在哪？難在怎麼做出一個好的軟體。好的軟體標準是什麼？兩個詞，好用，好看！程式設計師的最大價值在於做出好用又好看的軟體的能力。因此，我覺得程式設計師的價值絕對不在於技術本身，而在於做出好用且好看軟體的能力。這是一個開放性的話題，每一個人都是菜鳥過來的，我希望和祝願每一個技術人員都能儘快成為高手，也希望更多老鳥來分享經驗。在這篇文章，我將根據自己的經驗來分享，期望能給人有更多的有幫助的資訊。在這裡，我只想從技術角度來分析，技術不一定和收入相關聯的。
1 命名
從程式程式碼的命名，我們就可以看出一個人的水平。最差的命名就是使用中文、拼音、拼音縮寫、中英混搭，接下來要麼是模仿式命名，要麼乾脆就隨意命名。模仿式命名典型的就是“××DAL”，說實話，我覺得類似於“UserDAL”這樣的名字，我覺得太不美觀了，一般這我就知道這是典型分層架構的模仿者，說明他是有些經驗的人了。隨意命名，就是寫程式碼的時候，名字壓根就沒有意義，比如var list = new List<User>，其實完全可以寫成var users = new List<User>的。想要命名的更有意義，你只需要將每一個類、每一個方法、每一個單詞的名字都用你開發時的意思直接描述出來就行了。
2 模型抽象能力
模型決定一個系統的可用性、穩定性、易用性、可維護性、可擴充套件性！
這個模型不是UML建模，而是軟體的核心。就是你設計一個軟體時，為其所抽象出來的原理性的描述。模型決定一個軟體的質量、易用性和擴充套件性。凡是優秀的軟體，都有一個共同特點，就是其模型構建的非常漂亮，當然也有不怎麼優秀的軟體，模型也很漂亮。微軟MEF，我個人覺得其模型構建非常的漂亮和優雅，有興趣同學可以看看《體驗Managed Extensibility Framework精妙的設計》這篇文章。MEF的核心就是組合基元，如下圖所示，它簡單的定義了動態組合的支援基礎，然後一層一層的進行擴充套件。
當然了，因為文章是我寫的，我也得得瑟的顯擺一下OSGi.NET的設計。可以說，OSGi.NET的設計。OSGi.NET的設計也是類似於MEF，核心很簡單，只是為了實現三大功能：動態外掛化、面向服務、擴充套件。不過，我們卻可以從簡單的OSGi.NET來支撐WinForm、ASP.NET、ASP.NET MVC等任意應用，從簡單控制檯擴充套件到iOpenWorks這樣的自動化部署與軟體生產線平臺。它的擴充套件方式是：
WinForm等桌面外掛應用 = OSGi.NET + 應用外掛
ASP.NET應用 = OSGi.NET + WebExtension + Web外掛
MVC應用 = OSGi.NET + WebExtension + MvcWebExtension + Web外掛
自動部署 = OSGi.NET應用 + iOpenWorksBundleRepository + iOpenWorksBootstrap + 自動升級外掛
遠端服務 = OSGi.NET應用 + 遠端服務宿主外掛
負載均衡 = OSGi.NET應用 + 遠端服務宿主外掛 + 負載均衡客戶端外掛
在OSGi.NET之上的任何應用，都是基於組合和擴充套件的方式，並沒有去不斷變更OSGi.NET核心本身的程式碼。此外，OSGi.NET核心能夠支援.NET Framework、Mono、.NET Compact Framework，因為它設計的模型非常小，沒有用過多的類庫支援。
3 謙虛隨和
我們的客戶都是一些大的企業，接觸了很多各種型別的技術人員。你可以發現一個非常有趣的現象，那些懂得尊重別人、比較謙虛的人經過深入接觸後，會發現他們的技術往往都很了不起；而那些說話刻薄無禮，覺得這個技術也不怎樣，那個技術沒什麼了不起的，這個技術沒有什麼用，我自己的東西已經挺好的，這樣的人水平、經驗和見識一般都不怎樣。軟體的問題，並不是簡簡單單解決一個技術問題，從技術的角度上看，只要學會了使用技術，那麼我們就已經掌握了技術，因此，單純的技術是很簡單的。相反的是，軟體的協作開發、管理，軟體的易用性，軟體是否美觀，這些東西才是最麻煩的，也往往是技術水平一般、經驗短缺的程式設計師意識不到的東西。我曾經接觸過不少一般的程式設計師，大體都是這一類，他們覺得軟體太簡單了，沒有什麼了不起的。對於什麼思想，也不屑一顧，他們已經覺得自己掌握了很多真正的技術。
4 異常處理與穩定健壯
通過異常處理可以看出一個程式設計師程式設計的嚴謹與紮實的基礎知識。對於Java開發人員而言，會發現每一個方法都有可能需要強制的處理異常和宣告這個函式需要處理的異常，這中強制的約束，會強迫開發人員來習慣性的考慮和思考它。不過，對於大部分人來說，它處理異常的方式就是簡單的使用try { … } catch(Exception anyException) { // 忽略異常 }，用這種方式來捕捉所有的異常資訊。這樣做的好處就是快，傻，缺點就是一旦出現問題，就不知道問題在哪發生，怎麼回事，如果有靠譜的QA還好一些，比如外企，他們都有規範的測試方法和測試流程，一旦發現問題，就會將重現捕捉完整的描述出來給開發者看。不過，在國內沒有嚴格的測試是很正常的，那麼出現問題時，就傻了。客戶是絕對不可能把出現問題的方式給你完整的Repro的，一旦出現問題，客戶會幹的就是急眼，那接下來怎麼辦？你就老老實實加班，老老實實的去猜去找問題。當“try { … } catch(Exception anyException) { // 忽略異常 }”這樣的程式碼充斥整個軟體系統時，你就可以想象有多可怕，這個軟體能穩定就怪了！
我曾經在一個熱電公司，在半夜12點，好幾個廠家的人聚在熱電，等待0點時刻資料採集，一旦資料少了，那麼你就麻煩了。我到現場之後，發現有很多開發人員拿個本子，需要不停的看資料庫，或者需要將軟體Debug開啟，然後看看每一個時刻資料是否正常上來。這真是讓我喜出望外，因為競爭對手太弱了！！你們的軟體在此之前，難道對它7×24小時不間斷穩定執行那麼沒有信心？我們的軟體，我通過系統執行過程的訊息和日誌，我就可以看出所有的東西，如下，訊息視窗能夠展示系統後臺執行的詳細過程。此外，還有非常完整的日誌，任何異常我都可以找到，並想辦法重現。
關於異常處理，另一面，就是菜鳥程式設計師在寫程式碼或者實現功能的時候，一般不考慮反面情況，一個軟體按照正常步驟可能能走通，但是一旦出點意外，就麻煩了。以下就是一個典型的程式碼。
If(*****)
{
// ….do something…
}
這個程式碼處理了if，但是萬一出現else的情況呢？可想而知，系統將會出現無法意料的情況。因此，這也是菜鳥程式設計師做的系統一般都非常不穩定的一個根源，做程式一般只考慮功能實現，忽略掉意外情況。
5 優雅與美觀
菜鳥程式設計師並不是缺乏審美，缺乏的是優雅和美觀的抽象能力。一個好的系統，要做到兩點，好用，好看！因此，這絕對不是單單功能上的堆砌。很多國產軟體都深深的烙上了技術人員設計的印子，一看就知道這個軟體是出自一個技術人員的設計和實現，一看就知道這個軟體的實現過程，這簡直是慘不忍睹，不過，各位看官，這就是你們的機遇啊。
菜鳥技術人員開發功能的時候，一般都是從實現的角度進行堆砌，怎麼簡單，怎麼來。不會去仔細分析，使用者在操作這個功能的時候，到底還會做什麼事情，各個功能之間怎麼進行有機結合來完整的進行結合。相反，一些技術比較好的程式設計師往往都要直面客戶，經常被客戶罵，罵著罵著，也有點覺悟了。
當然，也有一些程式設計師因為自尊，直接不幹了。不過，我覺得厲害的程式設計師基本都有使用者意識，也希望自己的軟體能有很好的評價，甚至能夠影響社會。好用，好看，是軟體能夠被普遍採用的前提，因此，我們需要學會抽象優雅。
6 基礎紮實
技術知識決定一個人能做的技術的層次。基礎的知識有計算機組成原理、計算機作業系統、網路原理、資料庫原理、計算機圖形學、編譯原理、資料結構、離散數學、人工智慧等等很高深的理論知識。
在這些基礎知識之上，就是軟體開發語言、類庫、框架，程式導向、物件導向、面向服務等程式設計思想，架構思想等等。
這些知識不一定會影響你現在的工作，但一定會影響到你的格局，那格局肯定也會影響到你自身的發展。我碰到過有些理論很差的人，但技術在公司內也是有些影響力的，因此，他們對技術原理就很不屑，甚至為自己不懂太多理論而擅長實戰而沾沾自喜。這些人會對那些懂理論，但動手能力一般的人顯示出由內而外的鄙夷，但是他們卻不知道那些既有基礎知識，也有動手能力的高手做出的東西是怎樣的。就像我本人，實在是想不通，那些技術天才是如何開發出一個資料庫、作業系統這樣的軟體。因此，如果你已經發覺自己基礎不夠紮實，那麼還是有空就修煉修煉自己的內功吧！
7 文件與表達能力
很多技術人員都寫不了文件。不過，坦白的將，如果要獲得更好的報酬，文件時絕對關鍵的因素。沒有文件就沒有溝通，就沒有交易。有人提了，“文件是第一生產力”，我非常之贊同。文件的型別有很多，針對的物件也各不相同。不同的人，對文件的理解能力也是完全不一樣的。因此，你的文件必須適應於你的目標。這個對於搞技術的人太難，他覺得還不如寫程式碼來得快。
表達能力決定了你所做的技術的影響範圍，決定了你的影響力，決定你的威信。因此，也絕對的影響到你的報酬。因為這個能力而影響到你的報酬，你可能會心裡覺得虧，但沒有辦法，這是硬傷，可不僅僅是我只是不擅長寫文件，但我擅長與搞技術。如果哪一天，有一個擅長忽悠，技術不如你的人，爬到你的上面並且領導你，那也是該的。千萬不要去怪別人擅長忽悠，而是要想辦法來彌補自己的硬傷。
8 積極的心態
技術好的人，一般人都壞不到哪去。很簡單的一句話，想要技術好，就要投入時間，有時間投入到技術，那麼就沒有時間投入到其它方面，特別是消極的坑蒙拐騙，因此，技術人員一般也都比較靠譜。
積極的心態，不僅僅對於技術，對於生活也是如此。一旦有了積極的心態，那麼菜鳥到高手的過程，僅僅是時間的問題！
9 覺得軟體不值錢
我特別煩的就是做一個軟體和一些水平不怎麼高的技術人員談費用的問題。只要是想要做好，每一個哪一個事情是簡單的。凡是靠良心和能力謀生的，都是依靠自身的實力來獲取合適的報酬，我們每一個人都需要有收入。我也一樣的，況且，我還是在技術人員骨子裡面認為的那種見錢眼開的“老闆”，因此，這就很頭大。不過，好在，和我見面的人，都能看出來，我也是做技術的。但是，這依然不能改變一些技術人員認為軟體不值錢的想法，他們的理論是，這個功能放我身上，我一天就搞定了，憑什麼你要那麼多錢？
可是，我們們的做法一樣嗎？一個功能的實現方法有很多種，就像我說的資料採集。如果你的資料採集實現沒有以下“1、2、3”這些輔助的功能，後臺的實現要簡單的多。
如果沒有指令重試，沒有多執行緒，沒有非同步重新整理，沒有7×24小時穩定執行，沒有采集資料丟失，沒有指令優先順序排列，沒有多執行緒和分散式叢集採集，沒有支援1天1GB資料採集等等這些非功能性的需求。那麼這個軟體會更簡單，我也見過有人用一個控制檯，用一個單執行緒，顯示的資訊都是完全看不懂的二進位制數字，執行一會CPU就100%，記憶體不斷升高的採集軟體。這個也算得上是採集軟體。
不過，菜鳥程式設計師一般都會按照自己的做事方法來對軟體進行評估，如果沒有好的經驗，一般都會認為軟體很不值錢。事實上，做好看的、好用的軟體非常難，做好看、好用、還要好維護以擴充套件的軟體那就是難上加難。
還有一個幾年前碰到的軟體定製，有一個人直接說了，這是簡單的CRUD，一個頁面200元，你算算這個系統值多少吧，我現在都害怕跟這些人打交道，也害怕做業務軟體定製了。曾經也見到一個資料採集軟體，軟體負責人說，他們這個軟體一個月3個人就實現了，而我告訴他我們需要更多人手，更多時間，然後他非常不屑。最後，我就想看看他們的軟體，他開啟讓我看看，我在一個TextBox裡面沒有輸入資訊就點選一個按鈕，然後系統竟然直接崩潰，丟擲異常。看完我就笑著說了，我們不做這種通過拖拉控制元件直接資料繫結的軟體，我們需要做出一個好用且好看的軟體，能夠容易追溯、容易跟蹤狀態且支援多執行緒和分散式叢集部署的軟體。
軟體是一個充滿智慧結晶的勞動成果，如果說的高尚一點，有些軟體時無價的，當然我做的軟體不是這樣的層次！
10 工資
這點顯而易見！工資是價值的體現，我祝福每一個點“贊”的人，很快都能漲工資！那些不點“讚的”……，呵呵，你還是點“贊”了吧！
如果你還有更好的想法，歡迎補充，我將會在以下小節整理你的觀點的。