9步：為你的 web 應用選擇一個技術棧
創始人、CEO（執行長）、CTO（首席技術顧問）以及其他的利益相關者都需要知道如何構建一個軟體產品，你是他們中的一個嗎？是否煩惱過 web 應用到底選擇哪一個技術棧比較合適？用 JAVA 還是用 Python 呢？使用 node.js 或者 Flask/Django 作為 web 框架真的選對了嗎？前端到底是選 Angular ,React 還是 VueJs?資料庫到底是選 MySQL,Postres 還是 MongoDB?你應該在DigitalOcean上與Apache或Nginx進行自我託管，還是隻使用亞馬遜AWS？也許你覺得和Heroku這樣的PaaS合作更好一點？
如果你有無數的問題不知道從何下手，那這篇文章可以說是雪中送碳，它會幫助你做出決定。
1.簡單、敏捷
通常來說呢，要是你的產品失敗了，那麼你在技術上的糾結就沒有意義。許多創業公司一開始就想要使用厲害的技術，然後花費很多時間和經歷來保證產品的健壯性，結果發現產品沒啥市場。
無論在什麼時候，要是你想從頭開始構建一個產品，那最好的選擇就是使用最簡單的解決方法來解決問題。一個帶有 Wordpress 或者 Unbounce 的介面可能就夠了，甚至一個靜態頁面就足以解決問題了。在你經歷構建產品的麻煩之前，你需要仔細衡量你對產品的興趣。要是你設想的概念和你最終使用的技術不大一樣，那也沒什麼大不了的。
確定了想法和概念可行後，你就可以開始準備構建產品了。在這期間一點要保持敏捷。決不能花費數月來為開發者編寫一個程式規範，特別是這個產品只有6到12個月的實現時間的時候，這可能導致時間上來不及。
想一想：最重要的事是什麼，先做最重要的事。先讓基礎的介面跑起來，然後加上第一個要求，然後加上第二個。這麼做的好處在是一方面你可以實時評估進展，另一方面也方便你根據需求調整專案方向。這樣做能夠使風險降到最低，因為你的系統已經能夠運行了，可能這個系統功能還不夠完善，但至少，它能跑起來！
2.想一想你的個人需求
多想想實際要解決問題。你應該基於實際的問題去選擇技術，面對不同的問題的時候，也許這種語言會比另一種語言好的多。比如，Python 語言在計算和統計方面就很有優勢。
技術所面向的使用者
產品是為使用者而構建。你想構建一個什麼樣的產品？如何使使用者體驗達到最佳？想一想誰會使用你的系統。他們是用電腦工作呢還是用平板工作呢？他們是不是通過手機來訪問東西（60%的使用者是這麼幹的）？需要一個電腦桌面風格的應用嗎？使用者最常使用的瀏覽器是哪一個？
速度和效能
你對於速度和效能有標準嗎? 軟體會在你的內聯網執行嗎？如果是這樣的話，軟體載入時間可能比最佳狀態還要少。
當然，如果可以的話要儘可能的思考產品的敏捷性。如果軟體效能不大好，需要現在就改善嗎？如果你想做一個大型的軟體，你可以先改善一下平臺服務（例如 Heroku）,然後在改善產品結構，來達到改善效能的目的。當這個產品的規模較小時，你不需要考慮效能的問題。當你產品達到了一定的規模，就可以開始考慮效能問題了。
遷移&系統遺留問題
你有需要遷移的資料或者資料庫嗎？你有需要遷移到新系統的模組嗎？這一系列類似的問題都需要檢查和評估。
安全
安全問題不能被忽視。考慮到你工作面對的資料有所不同，可能安全會是這個系統最重要的因素之一。
3.考慮開源技術
當你構建一個新的軟體的時候，你應該尋找開源的解決方案。這避免了你從零開始進行軟體構建。這樣做可以節省大量的時間，而且可能更加的安全（畢竟大眾的智慧強於個人的智慧），而且還能讓你講精力集中在業務方面，使產品更加出眾。要記得給開源社群一些回饋。
當你發現一個新技術的時候，別激動，先列一個思考清單。它有什麼許可證？這個語言有沒有什麼特性你們開發團隊正好需要？這個語言有多少核心開發人員？你可以去 Github 上面去檢視程式碼貢獻者或者是星星，以及這個語言版本的演化歷史。如果你想要更加深入的瞭解這個語言，它底層的演算法好理解嗎？該語言的文件是否全面，該語言的技術是否經過測試？有沒有什麼模板樣例能夠讓你對這個語言迅速上手？
4.檢查系統
每一種技術都會有一個人和工具組成的生態系統。
這個語言或者框架背後的系統有多大？有多少棧溢位類的問題、回憶或者線上教程？谷歌當前引導的趨勢是什麼？軟體還在持續改進嗎？它擁有多少個包，你能不能拿到使用許可證？
你知道嗎？有一些很棒的清單，它們能夠幫助你深入挖掘一些語言或者框架背後的系統。你可以檢視和該技術有關的教程，文件以及一些重要的包。它列出了 Django,node.js,React,Angular以及其他的。
還有一點也很重要，這個新技術的社群歡迎新人嗎？社群是否活躍？給使用者和開發人員提供了多少支援？有沒有用於聯絡相關人員的郵件地址列表、聊天頻道、一個 Slack 聊天房間，或者一個預約系統？有沒有部落格內容是和該技術有關？
5.前景和支援
市場生命週期
每種技術都會有生命週期。之所以選擇成熟的技術，是因為相對而言成熟的技術更加可靠。你應該去 The Latest Technology Radar(最新技術雷達) 來了解未來的技術可能是什麼樣的，這樣做能夠幫助你決定是使用某種技術還是將他們留作備用。The Latest Technology Radar 是免費的，它將技術分為 技術，平臺，工具，語言和框架。但是你需要謹慎的使用這些資訊，因為這些資訊不是一成不變的。
另一個方法是去找一找大型工廠/企業使用的都是什麼技術棧。找找 Airbnb 在使用什麼，而 AngularJs 的使用人權又是誰。如果你不懂技術，你可以使用以上方法來決定選擇什麼技術。有一份 Angular JS 的技術選擇清單在 alternativeto.net 上。
長期供應商支援
供應商對這個技術支援有一段時間了吧？有沒有大公司贊助這項技術的發展呢？要知道 Angular 背後的大佬是谷歌，React 背後的大佬是 Facebook。在意味著，在這些大佬的支援下，這些技術會持續的更新、發展，直到大佬們決定放棄這項技術為止（這是有可能發生的）。但這些技術使用的範圍越大，它們存活的時間可能會更長。
有些應用在很長一段時間內會持續的更新版本。過一段時間，他們就會提供一個新的版本，修復了上一個版本存在的問題。你應該要看一下技術網頁：更新都解決了什麼問題？更新/遷移的過程容易嗎？有沒有不相容的版本（像是 Angular 1 和 Angular 2）?
6.人力資源和招聘
你身邊開發人員水平如何？如果你必須決定到底使用什麼前端技術，恰好身邊又有三個厲害的 Angular 開發人員，那你可以優先考慮 Angular 作為前端技術。開發的速度很重要。與其讓技術人員去學習一個新的技術，不如就讓他們呆在自己的舒適區使用現有的技術。當然，瞭解現有系統的生態系統（包括開發人員和使用工具）也是一個加分點。
至於招聘，則一定要想一想以下幾點：你能為你想使用的技術找到足夠的、高質量的開發人員嗎？給他們多少報酬合適？大公司是否使用了同樣的技術，是否使用開發人員都是優質開發人員？你招到的開發人員是真正優質的開發人員，還是說他們和“指令碼小子”（以黑客自居並沾沾自喜的初學者）區別不大？找一個優秀的軟體工程師或者一個優秀的 PHP 開發人員的難度可能大於需按照一個優秀的 Java 開發工程師，你可以看看目前的工作趨勢。
這種技術好學嗎？選擇一種簡單的開發語言能夠幫助你找到一些初級培訓人員，這個系統也會更加容易吸引到更多人。
最後一點：HR 可以從 Stackoverflow Developer survey（連結見原文) 裡面去尋找合適的人員。它提供了和開發人員型別、技術以及工資方面的相關資訊。值得一看！
7.軟體的設計足夠靈活嗎？
服務粒度
比起20年前，現在的一切都迭代的更加迅速。在很長一段時間裡，人們主要都用 windows 系統的臺式電腦。未來的十年裡，可能就完全不是這幅光景了。你選擇的技術開發出來的產品可能會使用5-10年：這是一個很長的時間。你無法確認一切將會如何發展。因此，當需求出現的時候，你要準備好改變使用的技術。
小型的程式包也要思考粒度以及粒度分割點。你最好把 伺服器、前端、後臺都分離成更小的應用和微服務。如果現有的技術不管用的話，你應該要能夠找到替換的技術。你可以看看 面向物件服務（SOA) 和 領域驅動設計(DDD)相關方面的設計。（連結見原文）。
你能擔保以下情況不會出現嗎？出現的規模怎麼樣？
你能夠隨意訪問資料嗎？如果想要改變改變技術，那麼原先產品種的資料能夠匯出嗎？這個技術是否能夠提供介面，讓應用能夠適應其他終端呢？也許你想在客戶或者消費者面前開啟應用，或者你想用你選擇的技術構建一個手機 app 或者 電腦 app。
8.給人感覺如何？
讓你的開發人員去了解這項技術，或者自己去了解。你對這個技術的第一映像是什麼？做一些導頻設定，嘗試使用現有的模板，或者（如果可能的話）嘗試一個小專案。如果您使用細粒度的服務，你可以使用新的技術構建一個小型服務，然後觀察這門語言是如何運作的。
目前我們可以使用一些現有的應用來理解語言之間的差異。TodoMVC (連結見原文) 就是個不錯的專案——比如說一個簡單的 Todo 應用就是使用不同的 JavaScript 框架來實現的，你可以檢查原始碼結構。應用中有各種各樣的例子，你可以將 Angular 和 React 對照，將 Vue 和 Ember 對照。
牛逼的 RealWorld project 專案更加全面：它是一箇中等的全堆應用程式，使用 Django 或者 node.js 作為後端，使用 Angular 或者 React 作為前端。你可以閱讀 Eric Simons 寫的相關介紹的文章。
9.開始吧！
如果你是一家小型創業公司的負責人，進入市場比挑選完美的技術更加重要。專注於你的業務和營銷，而不是優化技術，畢竟你現在的使用者沒有 Facebook 那麼多。早期的時候，可能你的知識量達不到需求。但是隨著時間的流逝，你必須成長起來，開始要懂得優化、改善現有技術，並技術棧進行調整（並且進行支出預算）。
不同的企業，面對的情況可能不同。無論如何，最終的決定可能都是帶有一定的政治性的——公司的每個人都需要在你的決定中來找到平衡。管理層（希望內部/潛在的開發人員）可能是最重要的利益相關者。
你要時刻記住，質量至上。選擇什麼技術不是最重要的，一個好的產品還需要好的設計、清晰的需求、嚴格的測試流程等等。最終要的一點是不要低估了自己的能力，保持專案語言的的一致性，不要在未來轉向其他的技術。
原文連結：