隨著做軟件的時間越來越長，我發(fā)現(xiàn)，做軟件越來越難。難在哪？難在怎么做出一個好的軟件。好的軟件標準是什么？兩個詞，好用，好看！程序員的最大價值在于做出好用又好看的軟件的能力。因此，我覺得程序員的價值絕對不在于技術本身，而在于做出好用且好看軟件的能力。這是一個開放性的話題，每一個人都是菜鳥過來的，我希望和祝愿每一個技術人員都能盡快成為高手，也希望更多老鳥來分享經驗。在這篇文章，我將根據(jù)自己的經驗來分享，期望能給人有更多的有幫助的信息。在這里，我只想從技術角度來分析，技術不一定和收入相關聯(lián)的。

1 命名

從程序代碼的命名，我們就可以看出一個人的水平。最差的命名就是使用中文、拼音、拼音縮寫、中英混搭，接下來要么是模仿式命名，要么干脆就隨意命名。模仿式命名典型的就是“××DAL”，說實話，我覺得類似于“UserDAL”這樣的名字，我覺得太不美觀了，一般這我就知道這是典型分層架構的模仿者，說明他是有些經驗的人了。隨意命名，就是寫代碼的時候，名字壓根就沒有意義，比如var list = new List<User>，其實完全可以寫成var users = new List<User>的。想要命名的更有意義，你只需要將每一個類、每一個方法、每一個單詞的名字都用你開發(fā)時的意思直接描述出來就行了。

2 模型抽象能力

模型決定一個系統(tǒng)的可用性、穩(wěn)定性、易用性、可維護性、可擴展性！

這個模型不是UML建模，而是軟件的核心。就是你設計一個軟件時，為其所抽象出來的原理性的描述。模型決定一個軟件的質量、易用性和擴展性。凡是優(yōu)秀的軟件，都有一個共同特點，就是其模型構建的非常漂亮，當然也有不怎么優(yōu)秀的軟件，模型也很漂亮。微軟MEF，我個人覺得其模型構建非常的漂亮和優(yōu)雅，有興趣同學可以看看《體驗Managed Extensibility Framework精妙的設計》這篇文章。MEF的核心就是組合基元，如下圖所示，它簡單的定義了動態(tài)組合的支持基礎，然后一層一層的進行擴展。

當然了，因為文章是我寫的，我也得得瑟的顯擺一下OSGi.NET的設計。可以說，OSGi.NET的設計。OSGi.NET的設計也是類似于MEF，內核很簡單，只是為了實現(xiàn)三大功能：動態(tài)插件化、面向服務、擴展。不過，我們卻可以從簡單的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 謙虛隨和

我們的客戶都是一些大的企業(yè)，接觸了很多各種類型的技術人員。你可以發(fā)現(xiàn)一個非常有趣的現(xiàn)象，那些懂得尊重別人、比較謙虛的人經過深入接觸后，會發(fā)現(xiàn)他們的技術往往都很了不起；而那些說話刻薄無禮，覺得這個技術也不怎樣，那個技術沒什么了不起的，這個技術沒有什么用，我自己的東西已經挺好的，這樣的人水平、經驗和見識一般都不怎樣。軟件的問題，并不是簡簡單單解決一個技術問題，從技術的角度上看，只要學會了使用技術，那么我們就已經掌握了技術，因此，單純的技術是很簡單的。相反的是，軟件的協(xié)作開發(fā)、管理，軟件的易用性，軟件是否美觀，這些東西才是最麻煩的，也往往是技術水平一般、經驗短缺的程序員意識不到的東西。我曾經接觸過不少一般的程序員，大體都是這一類，他們覺得軟件太簡單了，沒有什么了不起的。對于什么思想，也不屑一顧，他們已經覺得自己掌握了很多真正的技術。

4 異常處理與穩(wěn)定健壯

通過異常處理可以看出一個程序員程序設計的嚴謹與扎實的基礎知識。對于Java開發(fā)人員而言，會發(fā)現(xiàn)每一個方法都有可能需要強制的處理異常和聲明這個函數(shù)需要處理的異常，這中強制的約束，會強迫開發(fā)人員來習慣性的考慮和思考它。不過，對于大部分人來說，它處理異常的方式就是簡單的使用try { … } catch(Exception anyException) { // 忽略異常 }，用這種方式來捕捉所有的異常信息。這樣做的好處就是快，傻，缺點就是一旦出現(xiàn)問題，就不知道問題在哪發(fā)生，怎么回事，如果有靠譜的QA還好一些，比如外企，他們都有規(guī)范的測試方法和測試流程，一旦發(fā)現(xiàn)問題，就會將重現(xiàn)捕捉完整的描述出來給開發(fā)者看。不過，在國內沒有嚴格的測試是很正常的，那么出現(xiàn)問題時，就傻了。客戶是絕對不可能把出現(xiàn)問題的方式給你完整的Repro的，一旦出現(xiàn)問題，客戶會干的就是急眼，那接下來怎么辦？你就老老實實加班，老老實實的去猜去找問題。當“try { … } catch(Exception anyException) { // 忽略異常 }”這樣的代碼充斥整個軟件系統(tǒng)時，你就可以想象有多可怕，這個軟件能穩(wěn)定就怪了！

我曾經在一個熱電公司，在半夜12點，好幾個廠家的人聚在熱電，等待0點時刻數(shù)據(jù)采集，一旦數(shù)據(jù)少了，那么你就麻煩了。我到現(xiàn)場之后，發(fā)現(xiàn)有很多開發(fā)人員拿個本子，需要不停的看數(shù)據(jù)庫，或者需要將軟件Debug打開，然后看看每一個時刻數(shù)據(jù)是否正常上來。這真是讓我喜出望外，因為競爭對手太弱了！！你們的軟件在此之前，難道對它7×24小時不間斷穩(wěn)定運行那么沒有信心？我們的軟件，我通過系統(tǒng)運行過程的消息和日志，我就可以看出所有的東西，如下，消息窗口能夠展示系統(tǒng)后臺運行的詳細過程。此外，還有非常完整的日志，任何異常我都可以找到，并想辦法重現(xiàn)。

關于異常處理，另一面，就是菜鳥程序員在寫代碼或者實現(xiàn)功能的時候，一般不考慮反面情況，一個軟件按照正常步驟可能能走通，但是一旦出點意外，就麻煩了。以下就是一個典型的代碼。

If(*****)

{

// ….do something…

}

這個代碼處理了if，但是萬一出現(xiàn)else的情況呢？可想而知，系統(tǒng)將會出現(xiàn)無法意料的情況。因此，這也是菜鳥程序員做的系統(tǒng)一般都非常不穩(wěn)定的一個根源，做程序一般只考慮功能實現(xiàn)，忽略掉意外情況。

5 優(yōu)雅與美觀

菜鳥程序員并不是缺乏審美，缺乏的是優(yōu)雅和美觀的抽象能力。一個好的系統(tǒng)，要做到兩點，好用，好看！因此，這絕對不是單單功能上的堆砌。很多國產軟件都深深的烙上了技術人員設計的印子，一看就知道這個軟件是出自一個技術人員的設計和實現(xiàn)，一看就知道這個軟件的實現(xiàn)過程，這簡直是慘不忍睹，不過，各位看官，這就是你們的機遇啊。

菜鳥技術人員開發(fā)功能的時候，一般都是從實現(xiàn)的角度進行堆砌，怎么簡單，怎么來。不會去仔細分析，用戶在操作這個功能的時候，到底還會做什么事情，各個功能之間怎么進行有機結合來完整的進行結合。相反，一些技術比較好的程序員往往都要直面客戶，經常被客戶罵，罵著罵著，也有點覺悟了。

當然，也有一些程序員因為自尊，直接不干了。不過，我覺得厲害的程序員基本都有用戶意識，也希望自己的軟件能有很好的評價，甚至能夠影響社會。好用，好看，是軟件能夠被普遍采用的前提，因此，我們需要學會抽象優(yōu)雅。

6 基礎扎實

技術知識決定一個人能做的技術的層次。基礎的知識有計算機組成原理、計算機操作系統(tǒng)、網(wǎng)絡原理、數(shù)據(jù)庫原理、計算機圖形學、編譯原理、數(shù)據(jù)結構、離散數(shù)學、人工智能等等很高深的理論知識。

在這些基礎知識之上，就是軟件開發(fā)語言、類庫、框架，面向過程、面向對象、面向服務等編程思想，架構思想等等。

這些知識不一定會影響你現(xiàn)在的工作，但一定會影響到你的格局，那格局肯定也會影響到你自身的發(fā)展。我碰到過有些理論很差的人，但技術在公司內也是有些影響力的，因此，他們對技術原理就很不屑，甚至為自己不懂太多理論而擅長實戰(zhàn)而沾沾自喜。這些人會對那些懂理論，但動手能力一般的人顯示出由內而外的鄙夷，但是他們卻不知道那些既有基礎知識，也有動手能力的高手做出的東西是怎樣的。就像我本人，實在是想不通，那些技術天才是如何開發(fā)出一個數(shù)據(jù)庫、操作系統(tǒng)這樣的軟件。因此，如果你已經發(fā)覺自己基礎不夠扎實，那么還是有空就修煉修煉自己的內功吧！

7 文檔與表達能力

很多技術人員都寫不了文檔。不過，坦白的將，如果要獲得更好的報酬，文檔時絕對關鍵的因素。沒有文檔就沒有溝通，就沒有交易。有人提了，“文檔是第一生產力”，我非常之贊同。文檔的類型有很多，針對的對象也各不相同。不同的人，對文檔的理解能力也是完全不一樣的。因此，你的文檔必須適應于你的目標。這個對于搞技術的人太難，他覺得還不如寫代碼來得快。

表達能力決定了你所做的技術的影響范圍，決定了你的影響力，決定你的威信。因此，也絕對的影響到你的報酬。因為這個能力而影響到你的報酬，你可能會心里覺得虧，但沒有辦法，這是硬傷，可不僅僅是我只是不擅長寫文檔，但我擅長與搞技術。如果哪一天，有一個擅長忽悠，技術不如你的人，爬到你的上面并且領導你，那也是該的。千萬不要去怪別人擅長忽悠，而是要想辦法來彌補自己的硬傷。

8 積極的心態(tài)

技術好的人，一般人都壞不到哪去。很簡單的一句話，想要技術好，就要投入時間，有時間投入到技術，那么就沒有時間投入到其它方面，特別是消極的坑蒙拐騙，因此，技術人員一般也都比較靠譜。

積極的心態(tài)，不僅僅對于技術，對于生活也是如此。一旦有了積極的心態(tài)，那么菜鳥到高手的過程，僅僅是時間的問題！

9 覺得軟件不值錢

我特別煩的就是做一個軟件和一些水平不怎么高的技術人員談費用的問題。只要是想要做好，每一個哪一個事情是簡單的。凡是靠良心和能力謀生的，都是依靠自身的實力來獲取合適的報酬，我們每一個人都需要有收入。我也一樣的，況且，我還是在技術人員骨子里面認為的那種見錢眼開的“老板”，因此，這就很頭大。不過，好在，和我見面的人，都能看出來，我也是做技術的。但是，這依然不能改變一些技術人員認為軟件不值錢的想法，他們的理論是，這個功能放我身上，我一天就搞定了，憑什么你要那么多錢？

可是，咱們的做法一樣嗎？一個功能的實現(xiàn)方法有很多種，就像我說的數(shù)據(jù)采集。如果你的數(shù)據(jù)采集實現(xiàn)沒有以下“1、2、3”這些輔助的功能，后臺的實現(xiàn)要簡單的多。

如果沒有指令重試，沒有多線程，沒有異步刷新，沒有7×24小時穩(wěn)定運行，沒有采集數(shù)據(jù)丟失，沒有指令優(yōu)先級排列，沒有多線程和分布式集群采集，沒有支持1天1GB數(shù)據(jù)采集等等這些非功能性的需求。那么這個軟件會更簡單，我也見過有人用一個控制臺，用一個單線程，顯示的信息都是完全看不懂的二進制數(shù)字，運行一會CPU就100%，內存不斷升高的采集軟件。這個也算得上是采集軟件。

不過，菜鳥程序員一般都會按照自己的做事方法來對軟件進行評估，如果沒有好的經驗，一般都會認為軟件很不值錢。事實上，做好看的、好用的軟件非常難，做好看、好用、還要好維護以擴展的軟件那就是難上加難。

還有一個幾年前碰到的軟件定制，有一個人直接說了，這是簡單的CRUD，一個頁面200元，你算算這個系統(tǒng)值多少吧，我現(xiàn)在都害怕跟這些人打交道，也害怕做業(yè)務軟件定制了。曾經也見到一個數(shù)據(jù)采集軟件，軟件負責人說，他們這個軟件一個月3個人就實現(xiàn)了，而我告訴他我們需要更多人手，更多時間，然后他非常不屑。最后，我就想看看他們的軟件，他打開讓我看看，我在一個TextBox里面沒有輸入信息就點擊一個按鈕，然后系統(tǒng)竟然直接崩潰，拋出異常。看完我就笑著說了，我們不做這種通過拖拉控件直接數(shù)據(jù)綁定的軟件，我們需要做出一個好用且好看的軟件，能夠容易追溯、容易跟蹤狀態(tài)且支持多線程和分布式集群部署的軟件。

軟件是一個充滿智慧結晶的勞動成果，如果說的高尚一點，有些軟件時無價的，當然我做的軟件不是這樣的層次！

10 工資

這點顯而易見！工資是價值的體現(xiàn)，我祝福每一個點“贊”的人，很快都能漲工資！那些不點“贊的”……，呵呵，你還是點“贊”了吧！

如果你還有更好的想法，歡迎補充，我將會在以下小節(jié)整理你的觀點的。

園友精辟補充：

1 亂舞春秋

有思維和沒有思維。