5大代碼規則，守護程序猿世界的愛與和平！
編碼規則是程序編碼所要遵循的規則，要注意代碼的正確性、穩定性、可讀性。
而對于這些條條框框，一些不拘小節的程序猿們往往并不在意，這導致常常會發生一些意想不到的問題和狀況，讓大家苦惱不已。
現在，小芯整理了一份“命令”清單：列出了作為現代開發人員，你必須要做和不應該做的事情。
下面請看其中的5件，討論為何你和團隊應該采納它們。
1. 先確定問題，再確定解決方案。
每個人都有自己喜歡使用的東西：Redis、MySQL等。沒關系，有偏好是再正常不過的。
但當這些偏好成為要求時，就會出現麻煩;透過這個鏡頭可以觀察每個問題，避免其偏離。別被騙了，這不只是個人的罪惡，組織也應對此感到內疚。
許多公司要求使用某些技術、庫或工具，而往往沒有“腳踏實地”地進行思考或投入，令開發人員和運營工程師不得不在實際中使用或實施這些技術。
這是我長期以來不甚滿意的一部分，既包括企業體系結構，也包括掌控真正編寫代碼的凡人的上帝般的力量。
結構小組通常決定公司將使用某種技術或產品(Kubernetes、OpenShift、AWS等)，但卻未完全了解組織內部的問題以及這些技術旨在解決什么問題。
我在Capital One工作期間親眼目睹了這一點，當時我們的架構團隊決定將使用Kubernetes，但這對那些必須在實際中開發和實施系統及工具的人或將供其運行的應用程序來說并無真正意義。
通常，架構(或是同病相憐的兄弟——企業安全性)是導致他們無法獲得所需東西的原因。
如果他們-架構和安全性-首先了解所需解決的問題，然后決定使用哪種工具，情況可能大相徑庭，并且很可能順利得多。
圖源：Unsplash
2. 提出問題
聽起來很簡單、容易、還有點幼稚，但其實很難。遇見不懂的，那就提出問題。想知道為什么是這樣嗎?提出問題。想知道項目的方向嗎?提出問題。
僅僅提出問題并不意味將得到想要的答案，也不意味根本不能得到任何答案。但是如果不提出問題，那將永遠找不到答案。
進入新團隊或開始新工作后，最好的事情之一就是提出所有問題。拔出FNG卡就像在一開始“擺脫外觀愚蠢的”卡一樣。
用以下內容作為開頭提出問題：“嗨，對這一切而言，我是個新手，所以要提個愚蠢的問題……”這是一種很棒的方式，可以找到想知道的事情，同時挑戰現狀。
你會驚訝地發現有多少組織按照“以某種原因”這種方式做事。通常是因為有人在不久前設置了這種方式，但沒有人愿意修改它。
通過提出問題、質疑假設和挖掘信息，我們令所在團隊、集體、個人以及生活變得更好。通過這樣的提問，我已經能從基礎結構中獲得整個層次。
誰知道你將做出哪些修改。
3. 使用優秀工具完成工作(除非使用Java)
我不愿這樣說，但是的確找不出在當今行業中使用Java的理由。
Java確實有一些與之抗衡的差異，我不會否認，但是這些差異并不能真正適用于當今的工程環境。以下是使用Java的一些優點：
- 它可以在任何地方運行。
- 自動內存管理(及其垃圾回收器)。
- JVM堆棧的廣泛社區和框架/庫/插件。
讓我們談一談現實：你看到多少個軟件商店使用Java編寫用于多個體系結構、操作系統等運行的代碼庫?至少不是大多數。
如今，Java在內存管理領域也不是唯一。Go和Rust都具有某種垃圾收集功能，Python使用引用計數，許多其他語言也具有這種功能。
到目前為止，Java并不是唯一擁有大量活躍社區的語言。Rust和Python擁有非常活躍、具有幫助的社區，Go的社區與日俱增。
但是，至少在我看來，使用Java進行其他權衡是不值得的。因為Java依賴JVM，所以每個Java應用程序都會產生自動大小調整的成本。
在談論具有千兆字節可用空間(不到幾百MB的空間)的服務器時，這可能不值一提，但在高度集裝化的世界中，幾百MB卻是天文數字。(請注意，Python也具有此種缺點。)
使用Go、Rust(和其他)經過編譯的靜態鏈接語言，可以擁有非常小而精簡的容器，這些容器中通常只有一個大小為4 MB二進制的文件。
這對于網絡吞吐量非常重要的大型組織尤其重要，下載400 MB或5 MB新的容器非常容易。
另外，由于JVM和Java是JIT編譯的，因此運行Java代碼會降低性能。
對于低延遲、高吞吐量的應用程序，或對服務器進行裝箱打包非常重要的場景，將字節碼轉換為系統調用而導致的性能損失是不值得的。
這一切就是正確使用工具完成當前工作十分重要的原因。
你不想使用BASIC供人登月，也不想使用Java進行高性能計算——那么要找到與所需解決問題相匹配的解決方案。
圖源：Unsplash
4. 不要使用Monorepos
如果你不熟悉monorepo概念(羨慕你)，請允許我解釋一下：monorepo并非為應用程序提供多個源代碼存儲庫，而是將所有內容都放在一個存儲庫中。
這有益于多個項目，但是要付出代價：必須使用Subversion，而不能使用Git。盡管Git具有很多優點，但它不支持像subversion這樣的稀疏檢出。
稀疏檢出可檢出一棵較大樹的單個目錄，而非像Git一樣檢出整個樹。這意味著可以讓多人或團隊在樹的各個部分上工作而免于重疊。
使用Git不能做到這一點，因此使用Git作為源代碼控件時，應該為離散應用程序使用單獨的存儲庫。
5. 不要方枘圓鑿
就像很多美好的事物——做愛、團隊合作精神、精密螺紋的機器螺絲釘，當它們狀態良好時，一切都會輕松自在。我們的生活充滿了反饋，無論反饋是否明確。
打字時指間會感受到敲擊鍵盤的方式，按下扁平的假想按鈕時手機會發出輕微的“咔嗒”聲，每當決定吃冰激凌時我患有乳糖不耐癥的胃就會100%進行反抗;這些都是反饋形式。
他們會告訴我們什么時候進展順利、正常或極其糟糕，實際上一切都一樣。我們之前都體會過，從事一個項目，胃部的那種感覺不斷告訴我們應該更改數據庫以更好地支持數據模型。
如果你只使用關系數據庫和ORM，則可以編寫大量此類數據庫內數據，而不用編寫大量易碎的數據轉換代碼。或者，在找到自己的新團隊或新工作后，出于某種原因，你不再與同事友好相處。
這并不是說你不喜歡他們，或者他們不喜歡你，只是某些性格的人更適合在一起工作。無需強求。找到更好的解決方案，然后繼續。
與經理談談更換團隊。找到一個ORM并開始工作。停止你正在做的事情，然后做令其變得輕松的事情。將方形釘/圓孔問題留給NASA書呆子。
圖源：Unsplash
相信能掌握這5大代碼規則，你的編程之路會更加順利輕松和愉快。
