創業專案該如何選擇技術?

　　這些年，許多人問過我下面相同的問題：

我開始了一個新專案，你認為我該使用什麼技術呢？

　　通常，這些人屬於下面兩類中的一類：

• 已經做出決定的技術人員
• 需要鼓勵支援的非技術人員

　　在一天結束的時候，我懷疑這些人是否真正關心我的答案。或許他們只是想知道我們是否面對相同的問題或只是需要鼓勵支援。

　　坦白的說，作為一名工程師，我信奉這個說法：偉大的想法可由幾乎任何技術構建。它們都有自己的優點和缺點。無論你選擇什麼技術，你都要為它帶來的風險買單。但真的，你專案的成功與否更多的取決於願景、領導團隊、執行和市場，而並非技術的選擇。

　　現在，我是一個負責人，我每天做技術上的決斷。當我選擇了一個特定技術時，我要能夠證明這個決定，向我自己、我的合合夥人/員工和潛在的投資者。我根據專案及公司願景做技術選擇。

　　專案要成功你必須有一個堅定的願景。如果你能將你的願景轉化成一組衡量你每個決定的值，你的前進道路會更清晰，也更容易找到合適的加入你的人。

　　除了願景，許多初創公司專注於文化。人們都說文化是由創始人、最初的幾個員工及產品本身確立的，然而，技術抉擇對公司文化有直接影響這個說法卻沒怎麼被提到。

　　你的專案初創可能基於J2EE、Oracle、Perl、PHP、Rails、Node.js或.NET，隨之而來你的團隊工程師將有不同的期望，不同的價值觀，和不同的關注點。這些技術沒有本質上是壞的。偉大的事情都有各自不凡的所在。它們伴隨而來的是一種文化。

　　幾年前，我遇到一位負責人選擇使用Node.js來搭建自己的應用。出於好奇，我問他為什麼選擇Node。他的回答很簡單：基礎的工程師對Node.js很興奮，所以我可以更容易招募到願意免費貢獻的人，因為他們希望積累相關經驗。

　　這個決定顯式地定義了工程師文化和團隊成員——那些能夠在這個專案中工作或感興趣這個專案上工作的人。

　問一個不一樣的問題

　　那麼我們不應該問什麼技術是我們需要使用的， 我們應該問我們自己：

這個技術符合我們公司的核心價值觀嗎？

　　這顯然是個更為之困然的問題，因為你需要切切實實地瞭解你公司的核心價值觀。這將是建立一個成功專案的關鍵。

　　你不能盲目地套用技術就像你不用套用別人的商業計劃那樣。這是公司身份的一部分，你的核心價值觀，你的目標，你的團隊，你的期望都是跟別人不一樣的。

　　關於“這技術在某某公司用得適合啊”這樣的論據是很少有效的。例如Facebook使用PHP，它“在Facebook公司用得很適合”，但是這意味著我們選都應該使用PHP嗎？

　技術文化聯盟

　　要具體描述這些技術社群的特性是很困難的,但我會個你分享我在不同選擇上的觀點與看法。請自由在評論裡分享自己的看法，也可以包括關於其他技術社群的。

　　古典學校： 

　　這裡有些是“經典“的語言：他們已經被使用很長的一段時間，並且被證明他們的價值。他們的使用範圍已經很廣泛，但卻引不起別人更大的激情。

　　注意：我在這沒有提及Perl，因為我並不知道有哪個創業專案是以Perl作為核心技術來建立的（6？）。

　　PHP

　　理念:

• 功能都實現出來，這非常重要
• 就像網際網路的基礎一般
• 只要有一個方法去實現它，那麼就不會被破壞
• 只要它執行起來並且速度很快，那麼其他東西都是沒有意義的
• 不要太理論化了，我們的語言是非常通熟易懂的，任何人一眨眼的功夫就能上手了。你可以用Java做同樣的事情看看！
• 物件導向是種落後的想法

　　常見的使用例子: (在2013年中期)

• 你的第一個web app
• Wordpress/Drupal的擴充套件

　　個人觀點:

　　PHP擁有它光榮的日子。它真的讓web開發更加簡單，容易上手. 但是, 大概因為大量新的程式設計師開始使用PHP並且它擁有個不是那麼地堅持自己觀點的社群，所以只有少數人能寫出漂亮的PHP程式碼。

　　良好的擁有規範的程式碼例子是很難找到的，並且我甚至不敢肯定PHP擁有自身的規範。這導致了PHP社群以糟糕的程式碼質量，缺乏測試，安全問題如同夢魘和像在2000年代初期般的落後品味而著名。

　　擁有良好規範約定，開發流程和指南的強大的PHP團隊，是可以完成偉大的事情的，但這樣團隊很稀少。

　　Java

　　理念:

• 可移植性
• 像C/C++般的能力和表現，但卻能夠自動管理記憶體
• 更多地關注物件導向
• IDE是必須有得
• 我們要消耗所有的記憶體，因為它們是一文不值的
• 執行緒處理是個好方法！
• 不要提起Java applets
• 看看我可愛的JVM！
• 開源（但擁有者為Oracle）
• 緩慢但更為安全的開發流程

　　個人觀點：

　　Java是非常有趣的。在幾年前很多開發者已經厭倦了Java，他們找到了其他新大陸。他們開始轉向一些指令碼語言，像PHP，Pyhton，Ruby或者一些更加難懂小眾的語言像Erlang。

　　儘管如此，Google通過Android展示了Java並不像我們腦海裡的那麼糟糕（只要你並不是使用J2EE或者Swing）。現在有一種”趕時髦“的趨勢視乎暗示著Java再次變得酷起來了。這些大多建立在兩件事情上:

• JVM
• 讓人難以置信高質量的程式碼庫

　　即便如此，對於我們來說，花一整天來編寫Java程式看起來並不是一件吸引人的事。如果你打算依靠Java的堆疊，那麼有一系列的其他JVM語言供你選擇，他們成熟而且相容Java擴充套件的庫（例如：Scala, Groovy, JRuby, Clojure），你總是可以混搭使用它們。

　　自從大量畢業生學習Java後，聘請Java程式設計師並非一件難事，但是要找那些前期創業公司，高水準的工程師並且對寫Java程式感興趣是一件極具挑戰性的事情。

　　另外注意：如果你的目標是Android，那麼不用想得太複雜，即使你認為其他JVM語言更好，你也要堅持使用官方的堆疊。

　　我們仍然有許多的原因在你的創業專案裡使用Java技術，但你可能會想同時使用一些的”更快，更靈活“的解決方案（Ruby, Python, Node…）。對於公司跟工程師來說，一個多語言環境帶來了大量的價值，這就是為什麼Java社群看起來節奏很慢，但卻肯定是活躍的。

　　Java絕大部分是吸引了那些受到了傳統的訓練的工程師，他們嚮往舒適，有重複性，總所周知的程式設計模式。他們習慣關於使用這種語言，這種工具，這種自然的節奏。或許他們並不是最具有求知慾的開發者，但是他們卻是很可靠的（當然，你要挑選了正確的人）。

　　C#/.NET

　　理念:

• 是更加好的Java
• 最初是為了桌面與嵌入式軟體設計的
• 我們比開發Java的小夥伴們擁有更好的IDE
• 雖然是企業級般的重量了，但是我們提供了大部分Rails很酷的特性
• 我們有矛盾的開源版本
• 緩慢但更為安全的開發流程

　　個人觀點:

　　當我回顧C#在釋出C#5的時候，我不得不驚歎，我真的對該語言新的特性留下了深刻的印象。單從純粹的語言設計角度來看，C#是有一丁點的領先於Java。在Visual Studio裡寫Javascript時的欣悅感讓我感到很驚喜（自從我用VS主要為了C++後，我真的再也沒有期待過什麼了）。

　　另一件讓我印象很深的是：C#可利用的文件的質量非常顯著！但是C#並不是開源的，和Visual Studio + MSDN 非常昂貴，並且整個環境都因為licenses跟記憶體損耗而變得很糟糕，這些事實多少讓這個好印象打折扣了。

　　微軟正在慢慢地往開源發展，所以有了更多像Azure的開源方案。但是作為一個社群，.NET仍然是微軟開發的中心。作為創業者，你應該考慮下你對開源與擁有企業支援的文化之間對比的看法。

　　C#大部分吸引了Java群體中的變曏者：這些工程師們尋求穩定性和有保障的合同遠勝於追求開源。還有他們可以容忍IIS！

　明確的可替代品

　　在過去的這些年，有兩個動態語言對於新的創業專案來說變得十分受寵：Python and Ruby。這兩個語言實際上有非常多相似的地方。現在Python因為後臺apps而著名（因為NLP, biotech, APIs, SOA的因素 ）而另一方方面，Ruby因為面向使用者的apps而著名。儘管這兩個語言都受到了一樣的限制（主要是效能跟併發性），但是他們的核心價值和社群有著不一樣的專注點。

　　Python

　　理念:

• 只有一種顯而易見的做事方法
• 程式碼要漂亮簡潔和明確
• 文件是關鍵
• 有較強的語言設計引導

　　個人觀點:

　　作為一個更喜歡ruby的人來說，我常常嫉妒python專案文件的質量。同時python設計的初衷——給你一個正確的程式設計方式卻又讓我又愛又恨。通常這一初衷對於團隊來說很好，但某些時候可能令人抓狂。

　　在某些領域python有很多優秀的庫，並且這些庫和你想解決的問題有關，這種情況下python可能是最好的選擇。python開發者知道怎樣去討論交流他們的程式碼。他們用文件記錄所做的事情並且用程式導向來描述他們務實的方法。

　　但是python在網際網路流行前就已經存在，如果你關注的是併發和高吞吐量，那麼這個併發性很差的動態解釋語言可能不是一個很好的選擇。

　　python主要吸引的是那些想要一個現代但通過充分驗證的語言的更加務實和經驗豐富的全棧開發者。

　　Ruby/Ruby on Rails

　　理念:

• 為人而不是機器而設計的Designed for humans, not machines
• 極端的靈活性：如果陷入困境的話，是你的原因，那是你
• 一切力求簡單、優雅並充滿樂趣
• DSL至上，盡DSL
• 測試非常重要
• 事情變化很快，保持學習
• 激情活力的社群

　　個人意見:

　　就我而言，Ruby是我幾年來的首選語言。你會發現令人難以置信的、大量的Ruby開原始碼。Rails實在是一個了不起的Web框架，如果你知道如何使用工具的話它讓使大多數的Web專案容易實現。

　　但靈活性和過快的開發週期也有缺點。隨時準備在你的程式碼上投入大量時間以保持其更新以及分離廢棄老的庫。如果不能依靠快取，一個成功應用的吞吐量往往被缺乏良好的併發支援限制。

　　Ruby開發者主要是用Rails開發，所以與框架特性相比基本不會去深入核心語言本身的特性。他們往往是充滿好奇心且機會主義的（以一個很好的方式），有些實用主義，關心程式碼質量/結構和測試覆蓋率。Rails開發者早期採用它的典型原因是由於該框架本身預設使用的一些新技術（coffeescript、turbolinks、CSS前處理器……）。

　　Ruby和Rails主要吸引了那些想把事情做得快而優雅的開發者。相比於底層計算細節，這些開發者往往是以產品導向的，他們更關心的目的和客戶價值的實現。

　新成員

　　這是些讓人們興奮的語言/技術。他們代表了執行在“雲端”的程式語言的設計新浪潮。

　　Node.js (Javascript)

　　Node.js不是一門程式語言，但它是使JS在伺服器端執行最流行的方法。和我對Ruby的大部分評論是關於Rails一樣，相比JS我更關注Node。

　　理念:

• 為實時驅動的應用程式而設計，高吞吐量、低延遲
• DIY
• 小的核心，剩餘的內容由社群維護
• 低耦合
• 借鑑Ruby/Python

　　個人意見:

　　我覺得Node.js很有趣。在技術上Node沒有太多新內容。Python有Tornado/Twisted，Ruby有EventMachine，C有 libevent。

　　事件驅動的框架已經使用了一段時間，但Node具有兩大優勢：*大多數JS庫是非阻塞*大多數Web開發者不管怎樣都要寫一些JS。

　　在前端和後端使用相同程式語言的想法吸引了不少人，但值得與否還有待驗證。

　　Node提供了巨大的吞吐量（只要你堅持IO操作），它很容易上手，而且寫起來很有趣。

　　由於其本身具有事件驅動性，除錯及測試面臨挑戰，回撥處理是可維護性的地獄。我希望Node能夠提供一種官方的今後或承諾的解決方案。略顯凌亂的文件使在現有專案裡跳轉時有些困難。

　　Node的開發者大都是它的早期的接受者，他們更喜歡自定義而不是按慣例建立結構/模式，這樣使他們覺得更舒服。它吸引開發者使用已知的語言（JS）去處理高層的併發。Node作為一個框架處理的水平比經典的MVC更底層一些。Node開發者們也真的喜歡這個在伺服器和客戶端使用相同語言的想法。

　　Clojure

　　理念:

• 實用且符合現代人使用的Lisp
• 一切皆是資料
• 併發性，併發性，併發性
• 讓那該死的可變狀態見鬼吧
• 能夠很好地與Java協作
• 稍微靠近科研路線，但並不影響他的實用性

　　個人觀點:

　　我最喜歡Clojure的一點是它的lisp精神。一旦你攻克了它的圓括號和操作符/引數順序，那麼Clojure將很可能讓你重新思考你構建程式碼的方式。對於處理資料跟強迫你保持程式碼簡短這兩方面來說，它真的很棒並且高效。

　　讓我頭疼的是我並非擁有足夠的聰明去更多地編寫Clojure。當我嘗試去追蹤那些資料時，我的大腦會出現棧溢位。對於該語言來說異常通常是沒意義的，假如你嘗試解決別人程式碼的bug，這將會是機具挑戰的事情因為Clojure本身是複雜的語言，並且可以用巨集來擴充。最後，Clojure社群並不是真的面向web開發，Clojure完成的大多數作品都是以資料作為中心的。

　　Clojure主要吸引了那些處於邊緣，對程式語言有求知慾，面相資料的程式設計師。如果你尋找有程式語言怪癖的資料處理專家，那麼Clojure將會是吸引他們的好方法。

　　Scala

　　哲學:

• 同時具有物件導向與函式程式設計世界的最佳優點
• 讓編譯器為你做一些工作
• 併發事務
• 比Java少一些規範，但是目標在於相同或更好的效能
• 與Java生態系統和諧共存

　　個人意見:

　　當目標是JVM時，Scala目前是我所選擇的語言。它的學習曲線陡峭。 知道何時使用 FP 與 OOP是非常複雜的，而且在應對該語言語法本身時也是如此。

　　那就是說，獲得使用FP的好處，同時又在需要的時候仍然保持OOP，是非常有用的。一旦你“掌握”了該語言的風格，寫Scala實際上是令人愉快的，而且它的社群也非常友好。

　　Play框架確實很好，它提供了一個很好的替代Rails的選擇，特別是對API開發來說。Twitter的工程師團隊為此提供了許多資源與開原始碼。

　　目前使用Scala是一個非常安全的選擇。Java開發者會有舒適感並會嘗試這種更加“現代的”語言。動態語言開發者不會感覺太陌生，並且獲得了Java生態環境，效能提升，併發性和永恆性。如果編譯時間不會使你感到沮喪的話，現有工具以及慣例使得在一個成長的團隊中使用Scala非常不錯。

　　不過就像Ruby，Scala社群的文件不是很豐富。我真的希望  API文件 可以重新編寫得更直觀，總的說來就是更有用。但是公平的說，已經有許多非常好的資源了，比如Martin Odersky (Scala的創造者)提供的Twitter的 Scala學校和Coursera的Scala 課堂之 FP 。

　　Scala主要是吸引了好奇的Java開發者，他們想要一些更現代的東西，就像Ruby/Python開發者想要他們語言的一個更具伸縮性的版本。對於吸引那些想擴充它們現存開發環境的偉大的開發者，以及那些可以充分利用該語言二元性的開發者來說，Scala是一個好方法。

　　Go

• 更強大的C
• 你可以自己管理記憶體，前提是你不能粗心大意
• 直觀的程式碼更好
• 豐富的程式碼庫
• 效率很快..對於任何一個部分來說（從編譯到執行）
• 存在並行程式設計模式，並且簡單使用
• 文件很關鍵

　　個人觀點:

　　我真的很喜歡Go（亦稱Golang）。在我使用它幾年之後，我選擇使用它來開發我自己新專案的API。Go或許對於一些人來說有些無聊，但它的簡潔與效率是真材實料的。

　　Go強迫你更多地去思考你的程式碼的結構，你的資料/程式碼行為，因為你不能總是堅持物件導向的程式設計模式。我發現我的程式碼總算變得容易除錯，結構更簡潔，但有時會重複性比較大（例如：錯誤處理）。

　　沒有比Go更加方便地開發併發業務的語言了。一旦需要編譯，你的程式碼編譯加上執行的時間會比Rails伺服器啟動的時間還快。Go支援一些鴨子型別（duck typing,動態型別的一種風格），這造就了從Ruby（舉個例子）轉換過來顯得頗為簡單。對比起一些指令碼語言，它所編寫產品的效能實在讓人覺得驚歎，並且它佔用的記憶體很小。

　　Go被設計為一個人或是一個大團隊都可以為同一程式碼庫工作的語言，而且它的身旁有很多很棒的工具值得你使用。

　　然而，它不是完美的語言。有時第三方依賴庫很讓人頭疼。當你在高水平程式設計中運用了Go會讓你覺得它的水平太低了。有些語言設計時的決策有時會引起困惑(例子：互動式介面和結構化設計)。

　　初創公司裡，Go看起來在效能和併發事務方面變得越來越流行。我見過很多初創公司用Go替代了Node，而且另一些公司新增了Go應用作為擴充套件程式。

　　Go社群裡看起來混合了一些老的C/C++學校黑客和一些喜歡低水平語言的年輕人。Go語言和社群的領導者固執的相信讓人們理解他們的想法是很容易的。同時他們也允許你能快速的評估你接受他們哲學後是有多麼的舒適，而且可以發現是否能達到你的預期效果。

　　Go主要吸引著面向效能和結構體系的開發者。他們想要輕易的實現併發，要達到C的執行速度，也要達到Python/Ruby的開發速度。他們不想在找一個新的有趣的語言，他們需要一個堅定的妥協。

　技術驅動理念

　　技術的選擇會受到理念的影響。你需要清楚而謹慎地權衡你選用的技術是否與企業的價值觀一致。做出正確的決定有助於你從技術細節的糾纏中擺脫出來，擁有更多投入商務運作的時間。

　　原文地址：http://matt.aimonetti.net/posts/2013/08/27/what-technology-should-my-startup-use/