技術選型的一些考慮

| 2016-01-11 | 0 Comments

 一個創業公司,在開始一個項目,往往涉及一個技術選型的事情。即便是大公司,開新項目,也涉及技術選型的問題。

 

這個話題往往會引發很多沒有結論的糾紛,因為不同的技術路線a好者都有自己的判斷,不過我還是那句話,脫離場景談技術都是耍流氓。

 

微信公眾號不能修改已經發佈的內容,這個很不爽,其實我挺希望寫一些開放式話題讓大傢參與討論,然後一..修訂增補,形成一個真正的知識庫文檔,然而微信現狀是不能這樣的,所以我還是拋磚引玉說.自己的一些看法吧。

 

1、盡可能不重復造輪子,但也要根據實際情況而定。

 

我挺喜歡開源社區,我覺得很多優秀的項目和優秀的代碼都可以拿來主義,比如做遊戲,客戶端有cocos2d-x,可以一次開發,多平臺發佈,減少很多開發成本,而且效果也不錯,幹嘛不用。 服務端有大牛 雲風的 skynet開源,我能招到比雲風牛的程序員麼?顯然不能,差一.的能不能?差一半的都招不到,雲風的代碼免費在這裡,而且完全開放授權,我幹嘛不用。

 

不重復造輪子需要滿足幾個前提,第一是市場上提供的代碼和系統基本滿足你的需求;第二是授權和使用成本(如果涉及商業軟體)和預期收益相比非常的低。第三是盡可能在遇到問題的時候可以找到技術支持,包括官方的,或者哪怕官方不提供支持但是第三方使用很廣,你可以方便找到熟悉的人來解決使用中的問題。

 

第三條很容易被忽略,但出問題和狀況的時候特別頭疼,實話說,絕大部分人選用第三方技術方案或開源系統的時候,是不會去做源代碼分析的,這就導致一旦出現詭異的技術問題,自己去分析和跟蹤的難度極高,往往需要官方支持,而有些開源系統早就找不到官方,這就麻煩大瞭。

 

有些情況也必須硬著頭皮自己造,比如市場上符合你基本需求的代碼,或者雖然有但是改動成本過高,或者無法得到有效的技術支持,有時候我們會發現一些特別簡單特別小的開發任務,因為選擇瞭一套復雜龐大的第三方架構,結果是比自己從頭開始做還要可怕。

 

這裡要特別強調幾個選擇誤區

 

誤區1是求全,選擇功能最多的開源軟體,其實你根本不需要那麼多功能,而其x能可能極為糟糕,又或者二次開發的難度太復雜。 這個錯誤我也經歷過。

 

誤區2是需求定義過於自我,某些場景下,你的業務模式的競爭力並不在幾個細微的產品設計上,但為瞭滿足某些你自以為不錯的產品設計,放棄瞭某些本來比較好的開源系統或選擇瞭對原有代碼做較為復雜的二次開發,結果發現得不償失,耽誤大量的時間成本和開發成本,而對業務其實並沒有幫助。

 

2、不要為過於長遠的東西考慮過多。

 

大傢都希望自己的系統低耦合,通配x好,可以完成任意的後續功能的組合,但這也要有個度,當然這話題要是討論起來就沒完沒瞭。

 

簡單說,如果你技術架構能力很強,(主觀判定),知道代碼在編寫中低耦合高擴展,你可以在設計的時候,在滿足現有需求的基礎上,以不額外增加開發成本為前提,(註意這個前提!!!),做一些擴展預留的考慮。

 

如果你技術架構能力不強,滿足現有需求即可,盡量做到低耦合,代碼要盡可能間接,並寫好代碼註釋。

 

我有個觀.,與其做一套通配的結構,不如讓自己的代碼更容易被修改。特別是對於技術架構能力不是特別高的開發者。

 

我特別佩服一些草根創業者,明明沒什麼技術背景也能把一些我認為很頭大很復雜的問題處理掉;有些處理方法你可以認為是很low或者說是很粗糙的,但是管用人傢就把業務做起來瞭,也從來不強調說自己是技術產品;但很多技術創業者反而容易因為自我感覺太好在一些很小的細節把自己陷進去,為瞭追求技術的完美或擴展x,消耗大量的時間和精力,拖累整個項目。

 

3、因人而異選擇技術路線

 

有什麼人,做什麼事,有些技術方案很好,你的技術人員不擅長,你也隻能看著。 技術方案,在相差不大的情況下,盡量選擇你所信任的技術合夥人擅長的領域。

 

說個秘密,直到現在,我直接主導的項目還都是用apache做web server,而不是x能指標更勝一籌的 nginx,為什麼呢?因為我發現nginx+php 在高負載的時候會偶爾出一些500錯誤,而這個問題的原因直到現在我都沒搞明白。 在沒有能明確這個問題之前,我就隻有選擇apache,因為我確信apache用瞭這麼多年沒出過這個問題,而且我知道apache參數如何調優,至少單臺線上每秒鐘跑瞭1000次php請求是抗的住呢。其實我也不用擔心x能是個瓶頸。(技術評測往往誇大瞭不同平臺的x能差異,這是另一個話題,今天不展開,實際上在常用的動態網站處理中,apache和nginx的x能差異並不會特別大。)

 

說這個秘密啥意思呢,因為很多人都說nginx比apache好,x能卓越,這必須承認,但問題沒搞清楚之前我是不會用的,如果有人說他能搞定或者肯教我我也願意換過去對不對。

 

對你的開發也是如此,有些技術方案或者技術平臺確實不錯,但是如果你的人隻是覺得不錯想去嘗試,那麼他作為技術人員,他嘗試當然會有收獲,下一份簡歷多一項技能,但是對於公司而言,這個風險成本是要仔細斟酌的。

 

你說java好,我說php好,這事永遠扯不完,但是如果你身邊有一個高手就是java的,那你還是選java比較保險。

 

4、參照標桿選擇技術方案

 

如果你團隊還沒有技術合夥人或者技術合夥人是個多面手,並沒有明確的方案偏好,或者你希望團隊未來不依賴於單一技術合夥人,那麼建議參照你們所處領域大多數企業或者領先企業所選擇的技術方案。

 

這個參照標桿,隻是參照一些常規的技術方案,你說你一個準備開個網店賺.錢的你非要照搬淘寶的技術方案是不是有.扯。

 

所以,這個參照別真陷進去瞭,巨頭的開發邏輯和一般的創業公司或二線公司差異是杠杠的,你多看看和你近期目標類似的企業大部分用什麼技術方案就好瞭。

 

這個參照還有一個好處,因為在人力資源方面,你挖人,招人也容易招,既然同行很多用這個技術方案的,那麼這樣你招人相對比用冷門方案的會好招一.。

 

5、數據結構建議請專傢看一眼

 

這一條大概有.離題,嚴格來說不是技術選型,但是基本上你技術選型後下一步就是定義數據結構,具體的技術問題我之前有系列文章,這裡不贅述,但是 想說一個概念,數據結構是整個產品非常重要的一個支撐結構,即直接體現瞭需求的滿足度,也是未來擴展x的一個重要考量,不是說你數據結構做的特別靈活就是擴展x好,而是如果你數據結構做的特別死,以後可能改起來就特別的累。

 

做過研發的應該很多都知道,一旦數據結構要調整,沒有小動作,改的地方大瞭去瞭,所以數據結構這塊要特別引起重視,前期結構不一定需要考慮太多擴展,但是有些靈活的考慮要做到,未來有擴展盡可能不要改前期結構,比如用新增結構擴展需求。

 

我以前的習慣是,新項目可能代碼我不會去看,數據結構一般都要先看一眼,沒有大問題再讓團隊做開發,最近比較偷懶瞭。

 

希望一些非技術創業者理解一句話,數據結構出錯的改動成本比代碼出錯要大的多的多的多!

 

6、非業務核心可外包

 

中國很多公司不太相信外包,其實我也會有這個擔心,確實外包公司良莠不齊,而且實話說,外包開發的公司一般不太會有最優秀的開發團隊。

 

但是運維是可以外包的,比如各種雲服務商,盡量選擇口碑最好的;安全也是可以外包的,第三方安全公司也是有一些的,也盡量選擇口碑最好的。在安全和運維上省錢是不明智的!

 

開發,在一些非核心模塊上,外包也是可以的,比如你臨時搞一個運營活動,讓人開發一個微信活動的模塊,這事其實並不復雜,也比較容易控制質量。

 

7、讓技術專傢充分認識應用場景

 

幾乎漏瞭,而這應該是最重要的一條,應用場景是什麼,老板或項目負責人跟技術專傢說,我們要做個什麼什麼,技術專傢,哦,知道瞭,然後你認為這個溝通完成瞭?

 

事實上,很多問題都出現在這個環節上。

 

老板或項目負責人對一個產品的理解,是基於可能很長時間的觀察,測試,使用,分析,所形成的理解,並且對很多細節和特.已經有瞭非常深入的認識。

 

而技術專傢,可能隻是聽說過這個產品,甚至老板交代後去搜瞭一下這個產品,然後基於第一眼的印象和概念,形成瞭一個非常粗糙甚至是錯誤的認識,然後,他去做技術選型和技術規劃瞭!!!

 

背景信息的一致x是非常重要的,也是產品和技術溝通中最容易犯的錯誤,產品以為自己都說清楚瞭,而技術以為自己都聽清楚瞭,但是雙方的理解並不一致! 因為產品忽略瞭交代背景,而技術通過腦補還原瞭背景,你確定他腦補的和你認為的是一致的?

 

交代目的,交代背景,交代應用場景,要不厭其煩,並盡可能要求對方按照自己理解重述完整邏輯(這需要一.溝通技巧,並不是真的不尊重對方),才能確認這個溝通過程ok。

 

 

今天就扯這些。

 


 

文章刪除的一.說明

 

微信官方回復目前尚不支持贊賞自動退款功能,有退款需求的同學煩請在如上鏈接的文章裡留言,留下您的為微信帳號。如果您沒有留下相關信息,我就受之不恭瞭。

 

 

分享這篇文章
Filed in: 最新
×