程式設計思想之——"人是活的，程式是死的"

追隨微笑發表於2017-03-03
程式設計

　　"人是活的，程式是死的"這句話我時常提起，可能很多人不是很理解我為什麼會這樣說，下面我就簡單來談談我對這句話的理解。

　　一、不要因為技術而技術，技術選型的初衷是需求。

　　現在很多人在做專案的時候，開口就提專案用的NoSql、大資料處理、分散式系統等等技術。技術真的這麼重要嗎？

　　技術在軟體開發過程中的地位是不言而喻的，但是一個專案選擇合適的技術去實現是很有必要，也是一個很好的學習機會。

　　比如做一個簡單的人事管理系統，簡單的說就是對資料的新增、刪除、修改。

　　但是隨著NoSql的普及和運用，很多人在設計的時候可能會想用快取可以減輕資料庫壓力，增加資料的讀取速度等等優點。

　　從設計圖可以看出基本的設計，設計之初就想到NoSql的好處，但是很多問題都沒有考慮到，比如：資料的同步策略、簡單資料用NoSql效率真的比直接用資料庫高，高好多等等問題？

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

　　二、做功能之前請不要先說效率，請先完成功能在進行優化效率。

　　編碼的執行效率直接影響到系統的執行速度是非常重要的，但是當你遇到一個問題的時候，一起討論問題的時候。你是否最先想到的如果去解決問題，而不是看別人意見的缺點（這樣效率高不高、影響效能高不高、安全性等問題）？

　　我這裡不是說考慮這些不好，而是當你在想到一個比較的成熟的處理辦法之後，你在去想這些問題。可能會有人提出質疑，這樣做是不是太片面了、不利擴充套件性等等問題？是這邊必須承認有這樣的問題，但是一個功能都沒有做出來，想這些問題有用？

　　比如在遇到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();

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

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

　　三、太過死板，不懂靈活。

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

　　比如一個如下的簡單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等等

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

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

相關文章