技术选型的一些考虑
一個創業公司，在開始一個項目，往往涉及一個技術選型的事情。即便是大公司，開新項目，也涉及技術選型的問題。
這個話題往往會引發很多沒有結論的糾紛，因為不同的技術路線愛好者都有自己的判斷，不過我還是那句話，脫離場景談技術都是耍流氓。
微信公眾號不能修改已經發布的內容，這個很不爽，其實我挺希望寫一些開放式話題讓大家參與討論，然后一點點修訂增補，形成一個真正的知識庫文檔，然而微信現狀是不能這樣的，所以我還是拋磚引玉說點自己的一些看法吧。
1、盡可能不重復造輪子，但也要根據實際情況而定。
我挺喜歡開源社區，我覺得很多優秀的項目和優秀的代碼都可以拿來主義，比如做游戲，客戶端有cocos2d-x，可以一次開發，多平臺發布，減少很多開發成本，而且效果也不錯，干嘛不用。 服務端有大牛 云風的 skynet開源，我能招到比云風牛的程序員么？顯然不能，差一點的能不能？差一半的都招不到，云風的代碼免費在這里，而且完全開放授權，我干嘛不用。
不重復造輪子需要滿足幾個前提，第一是市場上提供的代碼和系統基本滿足你的需求；第二是授權和使用成本（如果涉及商業軟件）和預期收益相比非常的低。第三是盡可能在遇到問題的時候可以找到技術支持，包括官方的，或者哪怕官方不提供支持但是第三方使用很廣，你可以方便找到熟悉的人來解決使用中的問題。
第三條很容易被忽略，但出問題和狀況的時候特別頭疼，實話說，絕大部分人選用第三方技術方案或開源系統的時候，是不會去做源代碼分析的，這就導致一旦出現詭異的技術問題，自己去分析和跟蹤的難度極高，往往需要官方支持，而有些開源系統早就找不到官方，這就麻煩大了。
有些情況也必須硬著頭皮自己造，比如市場上沒有符合你基本需求的代碼，或者雖然有但是改動成本過高，或者無法得到有效的技術支持，有時候我們會發現一些特別簡單特別小的開發任務，因為選擇了一套復雜龐大的第三方架構，結果是比自己從頭開始做還要可怕。
這里要特別強調幾個選擇誤區
誤區1是求全，選擇功能最多的開源軟件，其實你根本不需要那么多功能，而其性能可能極為糟糕，又或者二次開發的難度太復雜。 這個錯誤我也經歷過。
誤區2是需求定義過于自我，某些場景下，你的業務模式的競爭力并不在幾個細微的產品設計上，但為了滿足某些你自以為不錯的產品設計，放棄了某些本來比較好的開源系統或選擇了對原有代碼做較為復雜的二次開發，結果發現得不償失，耽誤大量的時間成本和開發成本，而對業務其實并沒有幫助。
?
2、不要為過于長遠的東西考慮過多。
大家都希望自己的系統低耦合，通配性好，可以完成任意的后續功能的組合，但這也要有個度，當然這話題要是討論起來就沒完沒了。
簡單說，如果你技術架構能力很強，（主觀判定），知道代碼在編寫中低耦合高擴展，你可以在設計的時候，在滿足現有需求的基礎上，以不額外增加開發成本為前提，（注意這個前提！！！），做一些擴展預留的考慮。
如果你技術架構能力不強，滿足現有需求即可，盡量做到低耦合，代碼要盡可能簡潔，并寫好代碼注釋。
我有個觀點，與其做一套通配的結構，不如讓自己的代碼更容易被修改。特別是對于技術架構能力不是特別高的開發者。
我特別佩服一些草根創業者，明明沒什么技術背景也能把一些我認為很頭大很復雜的問題處理掉；有些處理方法你可以認為是很low或者說是很粗糙的，但是管用人家就把業務做起來了，也從來不強調說自己是技術產品；但很多技術創業者反而容易因為自我感覺太好在一些很小的細節把自己陷進去，為了追求技術的完美或擴展性，消耗大量的時間和精力，拖累整個項目。
?
3、因人而異選擇技術路線
有什么人，做什么事，有些技術方案很好，你的技術人員不擅長，你也只能看著。 技術方案，在相差不大的情況下，盡量選擇你所信任的技術合伙人擅長的領域。
說個秘密，直到現在，我直接主導的項目還都是用apache做web server，而不是性能指標更勝一籌的 nginx，為什么呢？因為我發現nginx+php 在高負載的時候會偶爾出一些500錯誤，而這個問題的原因直到現在我都沒搞明白。 在沒有能明確這個問題之前，我就只有選擇apache，因為我確信apache用了這么多年沒出過這個問題，而且我知道apache參數如何調優，至少單臺線上每秒鐘跑了1000次php請求是抗的住呢。其實我也不用擔心性能是個瓶頸。（技術評測往往夸大了不同平臺的性能差異，這是另一個話題，今天不展開，實際上在常用的動態網站處理中，apache和nginx的性能差異并不會特別大。）
說這個秘密啥意思呢，因為很多人都說nginx比apache好，性能卓越，這必須承認，但問題沒搞清楚之前我是不會用的，如果有人說他能搞定或者肯教我我也愿意換過去對不對。
對你的開發也是如此，有些技術方案或者技術平臺確實不錯，但是如果你的人只是覺得不錯想去嘗試，那么他作為技術人員，他嘗試當然會有收獲，下一份簡歷多一項技能，但是對于公司而言，這個風險成本是要仔細斟酌的。
你說java好，我說php好，這事永遠扯不完，但是如果你身邊有一個高手就是java的，那你還是選java比較保險。
?
4、參照標桿選擇技術方案
如果你團隊還沒有技術合伙人或者技術合伙人是個多面手，并沒有明確的方案偏好，或者你希望團隊未來不依賴于單一技術合伙人，那么建議參照你們所處領域大多數企業或者領先企業所選擇的技術方案。
這個參照標桿，只是參照一些常規的技術方案，你說你一個準備開個網店賺點錢的你非要照搬淘寶的技術方案是不是有點扯。
所以，這個參照別真陷進去了，巨頭的開發邏輯和一般的創業公司或二線公司差異是杠杠的，你多看看和你近期目標類似的企業大部分用什么技術方案就好了。
這個參照還有一個好處，因為在人力資源方面，你挖人，招人也容易招，既然同行很多用這個技術方案的，那么這樣你招人相對比用冷門方案的會好招一點。
?
5、數據結構建議請專家看一眼
這一條大概有點離題，嚴格來說不是技術選型，但是基本上你技術選型后下一步就是定義數據結構，具體的技術問題我之前有系列文章，這里不贅述，但是想說一個概念，數據結構是整個產品非常重要的一個支撐結構，即直接體現了需求的滿足度，也是未來擴展性的一個重要考量，不是說你數據結構做的特別靈活就是擴展性好，而是如果你數據結構做的特別死，以后可能改起來就特別的累。
做過研發的應該很多都知道，一旦數據結構要調整，沒有小動作，改的地方大了去了，所以數據結構這塊要特別引起重視，前期結構不一定需要考慮太多擴展，但是有些靈活的考慮要做到，未來有擴展盡可能不要改前期結構，比如用新增結構擴展需求。
我以前的習慣是，新項目可能代碼我不會去看，數據結構一般都要先看一眼，沒有大問題再讓團隊做開發，最近比較偷懶了。
希望一些非技術創業者理解一句話，數據結構出錯的改動成本比代碼出錯要大的多的多的多！
?
6、非業務核心可外包
中國很多公司不太相信外包，其實我也會有這個擔心，確實外包公司良莠不齊，而且實話說，外包開發的公司一般不太會有最優秀的開發團隊。
但是運維是可以外包的，比如各種云服務商，盡量選擇口碑最好的；安全也是可以外包的，第三方安全公司也是有一些的，也盡量選擇口碑最好的。在安全和運維上省錢是不明智的！
開發，在一些非核心模塊上，外包也是可以的，比如你臨時搞一個運營活動，讓人開發一個微信活動的模塊，這事其實并不復雜，也比較容易控制質量。
?
7、讓技術專家充分認識應用場景
幾乎漏了，而這應該是最重要的一條，應用場景是什么，老板或項目負責人跟技術專家說，我們要做個什么什么，技術專家，哦，知道了，然后你認為這個溝通完成了？
事實上，很多問題都出現在這個環節上。
老板或項目負責人對一個產品的理解，是基于可能很長時間的觀察，測試，使用，分析，所形成的理解，并且對很多細節和特點已經有了非常深入的認識。
而技術專家，可能只是聽說過這個產品，甚至老板交代后去搜了一下這個產品，然后基于第一眼的印象和概念，形成了一個非常粗糙甚至是錯誤的認識，然后，他去做技術選型和技術規劃了！！！
背景信息的一致性是非常重要的，也是產品和技術溝通中最容易犯的錯誤，產品以為自己都說清楚了，而技術以為自己都聽清楚了，但是雙方的理解并不一致！ 因為產品忽略了交代背景，而技術通過腦補還原了背景，你確定他腦補的和你認為的是一致的？
交代目的，交代背景，交代應用場景，要不厭其煩，并盡可能要求對方按照自己理解重述完整邏輯（這需要一點溝通技巧，并不是真的不尊重對方），才能確認這個溝通過程ok。
總結
- 上一篇： 高退出低留存：六年百万数据透析，想颠覆传
- 下一篇： 专心做业务，别想不开搞研发