不重視系統安全、過于微服務化、各種導入包……這些問題開發人員可能會在日常工作中會犯，除此之外，還有哪些開發者容易掉的坑呢？本文作者以下為譯文：

我是一名Python + Go開發人員，在過去的幾年中，我一直在運營全球規模的應用程序。我們團隊每天都需要為200萬名客戶提供服務，運營這種規模的系統并非易事。我想在本文中分享多年以來學到的九大經驗教訓。

保障安全刻不容緩

保障安全刻不容緩，你不能輕描淡寫地說：“今后系統會加強安全性。”

強大的應用程序安全應該被當作開發過程中的首要問題，應該從第1天開始就需要討論，絕對不能等到第你可能并不需要微服務

微服務非常有魅力，我完全理解。即便只是想一想能夠單獨擴展應用程序中的各個小功能，就足以讓人興奮不已，因為你可以感受到滿滿的成就感。

但是，說實話你可能不需要微服務。比如“我希望將功能X的代碼從功能Y的代碼中分離出來”，“防止不良代碼滲透到應用程序的其他部分”，或者“最小化受影響的應用”等到這些理由不是使用微服務的原因，這些不過是糟糕的開發實踐導致的惡果，你需要的是更嚴格的代碼審查標準（不要合并不良代碼），以及更為細致的安全控制。

你是否需要單獨擴展應用程序的各個部分，而且目前的組件（例如登錄流程）是否存在容量的問題？然后再探索那些需要擴展成獨立服務的組件。

你是否需要運行基于虛擬服務器的架構并希望降低成本？如果是，那么就不應該探索微服務。即便采用微服務，充其量也不過是功過相抵。惡劣的情況下，最終只是多了幾個需要單獨啟動的實例。

假設你的整體式架構包含5個服務，而你卻將其分解成了微服務。那么，現在你有5個應用，你所面臨的局面是：

a）你需要逐個啟動專用實例，而占空的空間是最初的5倍；

b）你利用現有的空間，同時承擔額外的運營成本。

標準化的開發環境

在與多個開發人員合作時，標準化整個團隊使用的開發環境可以讓你受益無窮。我并不是說你必須將一些基于容器的虛擬開發環境通過魔法混合在一起。雖然你要這么干我也攔不住，但是你只需使用同一個版本的語言就可以為團隊帶來奇跡。

如果你的同事用Go 1.11編寫代碼，而你卻在Go 1.12上發現了Bug，那么可真是欲哭無淚。協調何時升級版本可能很困難，但一旦協調成功，諸事都會順利。

配置的工作不簡單，請務必做好相應的計劃

雖然有些流行的網站說，配置只不過是“將所有東西都扔進環境變量中”，然而事實遠非如此。

我認為配置應用程序的方法至少有四種：代碼內的默認值、本地配置文件、命令行的標志、環境變量、遠程配置（如使用Hashicorp的Consul）等。我認為遠程配置是可選的，而其他四個都是必要的。

對于開發來說，為了在本地運行應用程序而不得不將27個不同的配置值放入環境變量，這會讓人萬分沮喪。另外，你可能需要更好的自動化和Makefile。你可以利用本地配置源的方法，如主機上的任何進程都可以讀取環境變量。你應該借助某種Secret管理工具。我個人喜歡使用Vault（來自Hashicorp），但你可以根據應用選擇最合適的工具。

只在必要時導入軟件包

我們都知道left-pad的那個故事吧（https://在導入庫時，通常我會遵循一個簡單的規則：如果我可以在10-15分鐘內自己編寫，那么就自己寫；否則再考慮使用外部的庫。

在開發的時候，牢記這條規則可以避免將不必要的內容導入應用程序，但是你不必每次需要提供API時都考慮從頭開始編寫新的沒必要抽象所有代碼

還有一個很大的坑：抽象一切。

有時，你會覺得“稍后我可能會再用到這個功能”，這個想法可能會將你引向一條黑暗又可怕的面向對象之路。

DRY原則（Don’t Repeat Yourself，不要自我重復）徹底征服了我們，盡管這條原則有其充分的理由。

然而，你需要注意不要在抽象上花費太多時間，以至于沒有足夠的時間編寫邏輯。你的工作是寫代碼！等到你發現你需要實現的某個方法或函數之前已經寫過了，那么可以再回過頭來抽象，但是切記量力而行。

我個人遵循的原則是，如果抽象之前只是一個只有3行的函數，那么就重復好了。如果真的只有3行代碼，也許你該想一想是否值得寫成函數。

項目需要像“鳳凰”一樣，

經歷浴火重生的洗禮

這個想法令人不寒而栗。經理們會為此感到緊張，產品所有者會為此變得暴躁，而且開發人員也會因此而感到憤怒，但你必須這么做。

每隔一段時間就從頭開始其實是一件好事。你可以借機刪掉代碼中的冗余，而且無需改造現有的半個代碼庫就可以實現新的想法，同時還可以強制每個人重新評估項目。

你可以把項目想象成一片森林，每一行代碼都是一棵參天大松樹，綿延數里。隨著時間一天天過去，這片森林會布滿灌木叢、飄落的松針、松果、枯枝和許多其他雜物。這些都是你的麻煩，你的技術債務。

這些東西越積累越多，直到受到某種外部力量的影響。對于森林而言，這種外部力量就是野火。火焰肆虐過的森林，地表寸草不生，只有樹皮足夠厚的樹木才能存活下來，所有未長成的樹木都會被大火燒盡。雖然這對森林來說是滅頂之災，但其中蘊含著一個驚天的秘密：森林渴望大火。多年來，它一直在耐心地等待，等待火焰來凈化一切，因為火焰在樹冠下肆虐過后，下一代的參天大樹才會從松果中發芽。

當火焰橫掃過森林地面時，它會孵化出幼小脆弱的樹苗，讓它們與被大火燒得漆黑的幸存者并肩而立。你的應用程序也需要這樣的洗禮：生命力旺盛、編寫良好的代碼會從清理中存活下來，而新的想法和代碼會從累累白骨中站起來，宛如浴火重生的鳳凰。

你不是谷歌

如果你是谷歌的一員，那么請繞道。但如果你真的是谷歌的員工，又何必來讀這篇文章呢？關鍵在于，你是谷歌微軟、亞馬遜、Twitter或Facebook一員的可能性非常小。所以，你無需在全球17個不同數據中心的10,000臺裸金屬服務器上協調150,000個容器。通常，你的問題不會影響到世界各地的人民。

那么，為什么我們要談這個話題？因為你應該根據規模決定你的運營平臺。如果你只需要運行幾百個容器，那么有必要使用Kubernetes嗎？你真的需要運行Kuberetes，還是說只想在簡歷中多添一項炫耀的資本？

HashiCorp Nomad等系統非常適合中小規模的系統：設置簡單，幾乎不需要維護，還有良好的文檔記錄，而且轉換應用程序很容易，因為它適用于容器以及系統進程和JVM原生應用程序。如果你真的想使用Kubernetes，那么為什么不使用Rancher等把混亂的東西都抽象化呢？運行Kubernetes這般復雜的系統實在讓人感到頭疼，而且也心疼錢，因為這些系統都是給谷歌這樣的公司設計的，單憑一個團隊很難管理。

我甚至會說，不要聽互聯網上陌生人的忽悠

你應該自行決定適合自己的應用程序和開發風格的規則。即使本文提到的幾件事，你也應該仔細推敲，畢竟我也只是互聯網上的一個陌生人。

網頁名稱：程序員易踩的 9 大坑
當前路徑：http://m.newbst.com/news31/103031.html

成都網站建設公司_創新互聯，為您提供企業網站制作、全網營銷推廣、做網站、搜索引擎優化、網站排名、品牌網站制作

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯