1、以終為始：價值是一切的起點。
技術的表面上看是職能線，但技術的本質不是完成需求，而是在一起創造價值。有個二八原則，說的是80%需求都沒啥用，其實這個數字實際可能更大。因此業務上要從起點考慮。
2、重視資料。
但凡不能被資料考量的，基本都沒啥價值。這不是乙個絕對的判斷，但實際上適合大多數場景。
之前我發現做很多事，看似出不來資料，譬如服務化等。後來仔細想想，做得太早了。指標很難弄出來的技術專案，一般都是形式化、漂亮的，好看不好吃。
3、打不打、打**比怎麼打更重要。
這句話是英文do right thing，right do thing的翻譯。實際上是在談選擇。why、what都沒想清楚，一定是在瞎忙。
4、技術方案的前提是問題實際存在，是個問題、是個大問題。
很多技術方案之所以看上去很好看、但不好吃，是因為這個問題是人主觀上創造出來的，或者問題不夠大、不夠疼。
5、業務、技術兩條腿走路。
做底層一般都靠技術一條腿，做業務一般都靠業務這條腿。沒有業務壓力，就容易划水。而業務壓力大的，很容易被業務需求爆倉，欠很多技術債。一瘸一拐的走路，最後的結果不是走得慢、而是系統被推倒重建。
6、重視系統運營。雪崩面前沒有一片雪花是無辜的。
如果乙個團隊的系統掛了，這個團隊裡頭的人沒有乙個是無辜的。一定要有系統運營的思維，還有責任心、owner感在裡頭。
7、邊幹活邊優化。
技術和業務的比例一般應該在20%、30%。投入少了就有問題。如果沒資源怎麼辦？
有乙個很重要的思維是把一件事做完整、做漂亮，而不是用最快的臨時方案交付。把技術成本平攤在日常需求裡去，這就像民兵組織一樣、散到每個人頭上。
8、對於歷史包袱要敢於亮劍。膽子要大、心要細。
如果是很有歷史的系統，但凡沒有演進思維去運營的，一定包袱很重。
這裡有乙個膽量問題。敢不敢動？收益如果大，別怕改、別怕變化。問題在哪，早一天解決困難少一點，責任、風險總要有人背的。
9、拒絕做重複的事情。重複的事情讓機器做。
產品讓程式猿幹活，程式猿讓機器幹活。復用這是降低成本十分有用的乙個思維。它的困難不在於技術方案有多複雜，而在於有沒有這個意識，有沒有將事情做得更好的意望。
10、學會用基本原則去構建技術的大廈。
其實軟體設計上真正基本的原則沒有幾條。沒有原則，就沒有判斷。推薦的幾個基本原則：高內聚、低耦合，或簡單性原則，solid原則，還原與整體綜合原則等。
程式設計的一些思考
以後對程式設計的一些感觸，再次彙總總結，不斷迭代完善。b 如何衡量乙個產品或需求的價值？b 能幫助多少人，能幫助多大的忙 能持續幫助多長時間 b 如何衡量乙個產品設計的好壞？b 隨著產品的發展，增加乙個需求需要的時間越來越少，反之要重新設計了！b 為什麼設計比較難？b 總被忽略糊弄過去，沒有配套制度...
網路程式設計 一些思考
1.在學習網路程式設計的時候，我通過網上的了解，買了不少書，但是在學習的過程中，仍有不少的困惑！我買了以下書籍 unix網路程式設計，卷一 unix網路程式設計，卷二 c 網路程式設計 基於ace框架復用 2.由於我總不能憑空去捏造一些框架，我開始閱讀，一些現有的，網路服務程式的 希望能夠從中獲得靈...
關於程式設計的一些思考
1 其實高階語言和面向過程的語言最求的目標都是一致的，高可復用性，另外，封裝性。我發現自己在寫c語言的時候，總是不自覺地就引入了高階語言的一些封裝性的思想 如以下 段1所示 而我的同學卻總是按著最原始的方式對函式進行命名。學過編譯原理的同學就會知道，最原始的c 編譯器其實就是將c 轉化成c語言，然後...