本文目錄一覽：
之前公司的同事找到我叫我去她們公司，要不要去？在之前公司配合挺好的
新技術要解決痛點啊 然後在個人項目上應用成功 再拿出來推廣 – 仲晨11、推動新技術會有兩個問題， 一是是否解決痛點， 二是會導致資源重新分配權力重新分配 – 我不叫大臉貓12、過去半年，我們組就經歷一次引入新的編程語言的經歷。背景：我們有一個命令管理系統（就是 Salt 的封裝），之前在業務層是前人用 PHP 寫的，然後到現在代碼質量和性能都有點問題，每次同時推1w台伺服器做任務就開始有幾台。幾十台的失敗，所以需要重構。主管的意思是想繼續用 PHP 重構，但是另一個同事想要使用 Golang，但是問題是我們組目前沒有項目是使用 Golang，其他同事對 Golang 也不熟悉，所以主管不太同意。所以我和那位同事這樣做，後來順利讓 Golang 在我們組生根發芽。1，我和那位同事結對編程，使用 Golang 重構了系統，QPS 從 20 升到了 2000+，並且支持超過 1w 的機器同時做任務。2，開展了 Golang 從入門到原理的技術分享，總共分享了 5 次 Golang 的技術分享，從普通使用、Golang 的比較經典的包、Goroutine 原理和源碼分享、單元測試、例子分享（使用的是 Golang 實現一致性 Hash），把其他幾個同事也帶入門。
為什麼那麼多人都說GO語言的發展前景很好，要趁早學習呢？
因為與 C/C++、Java、Python 等現在大多數的編程語言相比，Go 並沒有那麼多痛點，而且更具生產力，Go的高性能更加適應未來的互聯網發展趨勢，所以說GO語言是長遠發展的必備利器，現在越早學習GO，獲利越大，我是2年前就在慕課網學了GO語言，想轉型就多跟著做些項目，提升下go的實際應用能力。現在php都在轉行go，幸虧我眼光超前快人一步，現在的工資待遇還是很不錯的。
創業項目該如何選擇技術?
這些年，許多人問過我下面相同的問題： 我開始了一個新項目，你認為我該使用什麼技術呢？ 通常，這些人屬於下面兩類中的一類： 已經做出決定的技術人員 需要鼓勵支持的非技術人員 在一天結束的時候，我懷疑這些人是否真正關心我的答案。或許他們只是想知道我們是否面對相同的問題或只是需要鼓勵支持。 坦白的說，作為一名工程師，我信奉這個說法：偉大的想法可由幾乎任何技術構建。它們都有自己的優點和缺點。無論你選擇什麼技術，你都要為它帶來的風險買單。但真的，你項目的成功與否更多的取決於願景、領導團隊、執行和市場，而並非技術的選擇。 現在，我是一個負責人，我每天做技術上的決斷。當我選擇了一個特定技術時，我要能夠證明這個決定，向我自己、我的合合伙人/員工和潛在的投資者。我根據項目及公司願景做技術選擇。 項目要成功你必須有一個堅定的願景。如果你能將你的願景轉化成一組衡量你每個決定的值，你的前進道路會更清晰，也更容易找到合適的加入你的人。 除了願景，許多初創公司專註於文化。人們都說文化是由創始人、最初的幾個員工及產品本身確立的，然而，技術抉擇對公司文化有直接影響這個說法卻沒怎麼被提到。 你的項目初創可能基於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的開發速度。他們不想在找一個新的有趣的語言，他們需要一個堅定的妥協。 技術驅動理念 技術的選擇會受到理念的影響。你需要清楚而謹慎地權衡你選用的技術是否與企業的價值觀一致。做出正確的決定有助於你從技術細節的糾纏中擺脫出來，擁有更多投入商務運作的時間。
原創文章，作者：小藍，如若轉載，請註明出處：https://www.506064.com/zh-tw/n/246492.html
微信掃一掃 
支付寶掃一掃 