編程思想之——"人是活的，程序是死的"

"人是活的，程序是死的"這句話我時常提起，可能不少人不是很理解我爲何會這樣說，下面我就簡單來談談我對這句話的理解。

1.不要由於技術而技術，技術選型的初衷是需求。

如今不少人在作項目的時候，開口就提項目用的NoSql、大數據處理、分佈式系統等等技術。技術真的這麼重要嗎？

技術在軟件開發過程當中的地位是不言而喻的，可是一個項目選擇合適的技術去實現是頗有必要，也是一個很好的學習機會。

好比作一個簡單的人事管理系統，簡單的說就是對數據的添加、刪除、修改。

可是隨着NoSql的普及和運用，不少人在設計的時候可能會想用緩存能夠減輕數據庫壓力，增長數據的讀取速度等等優勢。

從設計圖能夠看出基本的設計，設計之初就想到NoSql的好處，可是不少問題都沒有考慮到，好比：數據的同步策略、簡單數據用NoSql效率真的比直接用數據庫高，高好多等等問題？

因此說技術和需求是相輔相成的，單一的需求或者技術就是咩有意義的，那麼在需求變動過程當中選擇恰當的技術解決問題很重要、很重要？

2.作功能以前請不要先說效率，請先完成功能在進行優化效率。

編碼的運行效率直接影響到系統的運行速度是很是重要的，可是當你遇到一個問題的時候，一塊兒討論問題的時候。你是否最早想到的若是去解決問題，而不是看別人意見的缺點（這樣效率高不高、影響性能高不高、安全性等問題）？

我這裏不是說考慮這些很差，而是當你在想到一個比較的成熟的處理辦法以後，你在去想這些問題。可能會有人提出質疑，這樣作是否是太片面了、不利擴展性等等問題？是這邊必須認可有這樣的問題，可是一個功能都沒有作出來，想這些問題有用？

好比在遇到webapi請求後，根據actionID去判斷執行對應的fun時候

1.用if去完成

if(ActionID==1)
   functioin1();
else if(ActionID==2)
  functioin2();
else 
   functioin3();

可能就會有人說這樣寫，萬一ActionID太多不利於擴展性，不夠靈活。

2.好吧我換成swith

Swith（ActionID）
  case 1：
    Function1();
    break;
  case 2:
     Function2();
     break;
  default:
    break;

可能仍是會有上述的問題。

3.好吧我再換一種吧

Dictionary<int,Action> fun =new Dictionary<string,Action>():
fun.add(1,function1);
fun.add(2,function2);
fun.add(3,function3);
if (Fun.ContainsKey(protoid))
        Fun[protoid].Invoke();

可能會有說這樣用影響性能啥的。

其實最後我只想說一句，這些方法你都用過，嘗試過？曉得會影響擴展、安全、性能？若是真有，你有更好的解決辦法？若是有更好，若是沒有那麼仍是建議你先一步一步的先去解決當前的問題，那麼在考慮下一步的其餘問題吧？

3.太過死板，不懂靈活。

當遇到一個問題的時候，一味的去新的方法或者新的東西上面去想辦法，不能仔細的回看本身原來作過的東西是否能夠修改/重用？

好比一個以下的簡單div組裝的TREE樹形結構圖

<div id=‘SF’>
    <div id='1001'>四川省<div>
<div>
<div id='SJ'>
    <div id='10010'>成都市<div>
<div>
<div id='SJ'>
    <div id='10011'>綿陽市<div>
<div>
<div id='SJ'>
    <div id='10012'>德陽市<div>
<div>

當知道一個市級的ID去查詢省級的ID

不少人以爲按照規範應該是根據市級DIV而後去查詢父級的DIV而後在查詢ID，這個方法可行的，可是若是樹N多層數，不是須要查詢父級的父級...

其實認真觀察以後會發現每一個市級的ID 和父級ID 是有關係的，能夠直接操做ID變化，組裝父類ID，可是若是父類和子類沒有關係...

一個div標籤其實不但能夠ID，還能夠用其餘屬性表示其關係或者對應的ID，而後根據其餘屬性查詢，可是可能在規範性會有點小問題...

在初始化的時候 ID 能夠是 SJ+ID這樣組合，而後切割ID就能夠查詢組裝...

若是上述都不行，能夠不用DIV組裝用JqTree等等

這個例子其實就是想表達一個其實解決一個問題的辦法多種多樣，一種不行換一種，條條大路通羅馬。

 

上述都是我的的認識和理解，僅僅表明我的觀點，有更好觀點歡迎斧正，謝謝！