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






















