程序員易踩的 9 大坑

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

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

保障安全刻不容緩

保障安全刻不容緩，你不能輕描淡寫地說：“今后系統(tǒng)會加強安全性?！?/p>

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

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

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

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

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

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

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

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

標準化的開發(fā)環(huán)境

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

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

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

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

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

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

只在必要時導入軟件包

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

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

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

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

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

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

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

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

經歷浴火重生的洗禮

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

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

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

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

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

你不是谷歌

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

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

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

我甚至會說，不要聽互聯(lián)網上陌生人的忽悠

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

文章標題：程序員易踩的 9 大坑
本文鏈接：http://muchs.cn/news/103031.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供網站營銷、響應式網站、建站公司、手機網站建設、全網營銷推廣、網站導航

廣告

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