熱搜: 老榕樹  聯盟  阿里  cpa  廣告  網站  榕樹  cps  淘寶  產品 
 
當前位置: 首頁 » 站長資訊 » 網站優化 » 正文

三十年軟件開發之路:老碼農的自我修養!

放大字體  縮小字體 發布日期:2019-07-30  瀏覽次數:98
核心提示:聲明:本文來自于微信公眾號 CSDN(ID:CSDNnews),作者:Julio Biason,授權站長之家轉載發布。【CSDN編者按】“千帆過盡仍少年”,對于程序員來說,保留技術初心、不斷提升實力是夯實自己的不二法則。而本文的作者

聲明:本文來自于微信公眾號 CSDN(ID:CSDNnews),作者:Julio Biason,授權站長之家轉載發布。

【CSDN編者按】“千帆過盡仍少年”,對于程序員來說,保留技術初心、不斷提升實力是夯實自己的不二法則。而本文的作者,作為一名有著三十多年開發經驗的“老”程序員,就在本文中詳細總結了自己這些年踩過的坑和實踐得出的真理,談到了包括軟件開發、團隊工作、個人成長等方方面面。相信閱讀本文后,會幫助你成為更優秀的程序員。

聲明:本文已獲作者 Julio Biason 翻譯授權。

譯者 | 王艷妮,責編 | 郭芮

以下為譯文:

這是我 30 年來從事軟件開發過程中所學到的一些實際經驗,可能有些聽起來憤世嫉俗,但都是我的切身經驗之談。

再次強調,有些內容真的是憤世嫉俗,有些則是對不同工作崗位的長期觀察。

軟件開發

先明確問題,再開始寫代碼

如果你不知道你想要解決的問題是什么,那你肯定就不知道要寫些什么代碼。在編寫任何代碼之前,先明確地把應用程序是如何工作的寫下來。

“如果沒有需求或設計,編程就是向空文本文件不斷增加bug的藝術。”——Louis Srygley

有時,即使只是“電梯演講”(指短時間內表述結果內容)那么長——用僅僅兩個自然段來描述這個應用程序的功能——也足夠了。

有時候我看著自己的代碼發呆,不知道下一步該怎么做,其實往往是因為下一步本來就還沒有被定義出來。一般出現這種情況,就意味著是時候停下來,與同事們討論一下了——或者重新考慮解決方案。

將步驟寫為注釋

如果你不知道如何開始,請先用自然語言、英語或你的母語描述應用程序的流程,然后用代碼填充注釋之間的空白。比這更好的做法是:將每個注釋視為一個函數,然后編寫出能完全實現其功能的代碼。

Gherkin是幫助你了解期望(expectation)的好幫手

Gherkin是一種測試描述格式,它指出“鑒于系統處于特定狀態,當發生某些事情時,這是預期的后果”。即使你不使用任何能讀取Gherkin的測試工具,它也會讓你很好地理解應用程序的預期效果。

單元測試很好,集成測試更好

在我目前的工作中,我們只測試模塊和類(例如,我們只為視圖層編寫測試,然后僅測試控制器層,依此類推)。它能讓我們了解到某一部分有沒有出錯,但缺乏對整體的觀察——而集成測試測試了整個系統的行為,在這方面會表現得更好。

測試可以讓API更好

我們在不同層次中編碼:有一個存儲層,應該使我們的數據永久存儲;有一個處理層,應該對存儲的數據進行一些轉換;有一個視圖層,它有關于數據必須如何被展示出來的信息......等等。

正如我所提到的,集成測試感覺更好,但是單獨測試不同層可以讓你更好地了解其API。然后你可以更好地了解如何調用東西:API是否太復雜了?是否需要保留大量數據才能進行一次調用?

做你知道如何在命令行上運行的測試

也不是說命令行對于任何項目都很重要,但是當你知道運行測試的命令時,你就知道如何讓測試的執行自動化起來,然后你可以在一個連續的集成工具中使用這些測試。

時刻準備好扔掉你的代碼

很多人在剛開始使用TDD(測試驅動開發,Test-Driven Development)時,一旦被告知他們可能不得不重寫很多東西,就會變得很生氣。

TDD“旨在”扔掉代碼:越了解你的問題,那么你就會越明白,無論你寫了什么,從長遠來看都無法解決問題。

所以你不應該擔心這個。你的代碼不是一面墻:如果你必須永遠拋棄它,那也不是白白浪費了材料。當然這意味著你編寫代碼的時間一去不復返了,但是你現在對這個問題有了更好的理解。

好的語言生來帶有綜合測試

可以肯定的是,如果一種語言在其標準庫中自帶一個測試框架——即使小得不能再小——那么與沒有測試框架的語言相比,它周圍的生態系統仍將擁有更好的測試,無論該語言的外部測試框架有多好。

未來思路是垃圾思路

當開發人員試圖解決問題時,他們有時會試圖找到一種方法來一下解決所有問題,包括未來可能出現的問題。

但現實就是這樣:未來的問題永遠不會到來,你最終要么必須維護一堆永遠不會被完全使用的龐大代碼,要么得整個重新寫,因為有一大堆屁用沒有的東西......

解決你現在遇到的問題,然后解決下一個,然后再下一個。直到有一天,你會發現這些解決方案中顯現出了一種固定的模式,然后你才能真正地“一次性解決所有問題”。

文檔是寫給未來自己的情書

我們都知道,為函數、類(class)和模塊編寫該死的文檔是一個痛苦的過程。但是以后當你看到文檔就能回想起來當時你編寫函數時的思路,你就會明白將來文檔能在關鍵時刻救你一命。

功能文檔是份合同

當你以編寫文檔作為自己編程工作的起始點時,你實際上是在簽訂合同(可能是跟未來的自己):我說了這個函數要做這件事情,那么它就必須做這件事情。如果稍后你發現代碼與文檔不匹配,那你就是代碼出了問題,而不是文檔出了問題。

如果一個函數的描述包含“和”,這就是不對的

一個函數應該且僅應該做一件事,真的。當你編寫函數文檔并發現你寫了“和”這個字的時候,這意味著該函數不僅僅是做一件事。那么就需要將該函數分解為兩個獨立函數并刪除“和”。

不要使用布爾型變量作為參數

當你設計一個函數時,你可能會想要添加一個flag——不要這樣做。

現在,讓我給你舉個栗子:假設你有一個消息傳遞系統,并且有一個函數可以將所有消息返回給用戶,稱為getUserMessages。但有一種情況是需要返回每條消息的摘要(例如,第一段)或完整消息,因此,你添加一個名為retrieveFullMessage的flag/布爾參數。

再說一次,不要這樣做。

因為任何讀你代碼的人都會看到getUserMessage(userId,true)并想知道這里的true到底是個什么意思。

你可以將函數重命名為getUserMessageSummaries并使用另一個getUserMessagesFull或類似的東西,但每個函數只調用原始的getUserMessage為true或false——但是類/模塊外部的接口仍然是清晰的。

但是一定“不要”在函數中添加flags / Boolean作為參數。

注意界面的變化

在上面幾點中,我提到了重新命名函數的問題,如果你能控制使用該函數的整個源頭,那就不算是問題,只需要搜索和替換即可。

但是,如果該函數實際上是由庫公開的,那么你不能隨便地更改函數名稱。這將打破你無法控制的許多其他應用程序,并惹惱其他人。

你可以通過文檔或某些代碼功能創建新函數并將當前函數標記為已棄用,然后,經過幾次釋放后,你終于可以Kill掉原來的函數了。

(你可以做的一個有些混蛋的舉動是創建新函數,將當前函數標記為已棄用,并在函數開頭添加一個休眠,這樣一來使用舊函數的人會被迫更新。)

好的語言自帶集成的文檔

如果語言有自己的方式來記錄函數、類、模塊或其他,而且帶有一個哪怕最簡單的文檔生成器,你就可以確切知道所有的函數、類、模塊、庫、框架都具有良好的文檔了(不是說一定特別好,但至少是比較好的)。

大多數情況下,沒有集成文檔的語言,文檔方面做得都不怎么樣。

一門語言絕不僅僅是一門語言而已

編程語言就是你寫的、而且能做事情的東西,但在特殊關鍵詞以外它還有很多別的東西:它有一個構建系統,它有一個依賴控制系統,它有一種使工具/庫/框架互動的方式,它有一個社區,它有一種與人打交道的方式。

不要僅僅因為一種語言容易使用就選擇它。永遠記住,你可能因為一種語言的語法很簡明而支持這種語言,但是與此同時你也是在支持維護人員對待這個社區的方式。

有時候,寧愿讓應用程序崩潰也不要什么都不做

雖然這聽起來很奇怪,但即使在處理過程中添加了某些錯誤,也不要默默地捕捉到錯誤但什么都不做。

Java中一個可悲的常見模式是:

這看起來跟處理異常沒有什么關系——除了重復了一遍,僅此而已。

如果你不知道如何處理它,那就隨它去吧,你早晚會知道它會發生什么。

如果你知道如何處理該問題,那么就處理它

與前一點相反:如果你知道什么東西在何時會導致異常/錯誤/某種結果,并且知道如何處理它,那么就請處理它吧。顯示錯誤信息,嘗試將數據保存在其他位置,將日志文件中用戶的輸入捕獲到以便以后處理,但要記得處理它。

類型決定你的數據是個什么東西

內存中只是一串字節序列;字節只是 0 到 255 之間的數字組合;這些數字的真正含義取決于語言的類型系統。

例如,在C中,值為 65 的char型變量可能是字母“A”,值為 65 的int型變量是數字65——處理數據時請不要忘記這一點。這也是為什么大多數人在用布爾型變量做加法以查看True的數量時經常出錯。

現在,讓我展示一下我最近看到的一個Javascript里的例子:

如果你的數據具有模式(schema),請使用結構(structure)來保留它

你可能會想要使用列表(或元組,如果你用的語言允許的話)來保存數據,如果它很簡單——比如說,只有 2 個字段。

但是如果你的數據有一個模式(schema),有一個固定的格式——你應該每次都使用一些結構來保存它,不管是用struct還是class。

理解并保持cargo cult的方式

“Cargo cult”是一種理念,如果其他人那樣做了,那么我們也可以。大多數情況下,cargo cult只是對一個問題的偷懶的解決方法:

“如果X這樣做了,我們為什么要考慮如何正確存儲我們的用戶數據?”

“如果有某巨頭公司是這樣存儲數據的,那么我們也可以”。

“如果有某巨頭公司支持這種做法,那就說明這種方法很好。”

......

不要管所謂的“合適的生產力工具”,你只需要盡力去push進程

“合適的生產力工具”其實意味著:對于某件事情,有一個正確的工具和一個錯誤的工具——例如,應該使用另外的某種語言/框架而不是當前的語言/框架。但每當我聽到有人提到這個詞時,他們都是在試圖推銷他們喜歡的語言/框架,而不是合適的語言/框架。

“正確的工具”比你想象的更明顯

也許你當前的項目需要處理一些文本,也許你很想說“讓我們用Perl吧!”,因為你知道Perl在處理文本時非常強大。

但你漏掉了哪一點呢?你在一個C的團隊工作,每個人會C,而不是Perl。

當然,如果它是一個小的、“放在角落”的不起眼的項目,那么用Perl就可以了——但如果它對公司很重要,那么最好還是用C。

PS:你的英雄項目(本文稍后將詳細介紹)可能因此而失敗。

不要跟你項目之外的事情糾纏

有時人們會試圖改變外部庫/框架,而不是使用適當的擴展工具——例如,直接對WordPress或Django進行更改。

這樣很容易讓你的項目秒癱瘓,變得無法維護。一旦發布了新版本,你就必須與主項目保持同步,并且很快就會發現改動不再適用,你將把外部項目留在一個舊版本中,且充滿了安全漏洞。

數據流動比模式更重要

(再次說明,這僅僅是個人意見)當你了解數據如何在代碼中流動時,你的代碼質量就會更上一層樓,這比無腦應用一堆設計設計模式(design pattern)好多了。

設計模式是用來描述解決方案的,但它不能找到解決方案

(同樣,個人觀點)大多數時候我看到設計模式被應用的時候,它們被用作尋找解決方案的一種方式,所以你最終會扭曲一個解決方案——有時候,甚至是扭曲問題本身——來適應某個設計模式。

首先,解決你的問題,找到一個好的解決方案,然后你可以檢查模式,以提供如何命名該解決方案的思路。

我經常看到這種情況發生:我們有這個問題;一個設計模式接近正確的解決方案;讓我們使用這個設計模式吧;現在我們需要在適當的解決方案基礎上添加很多東西以適應這個設計模式......

學習函數式編程的基礎知識

你不需要徹底搞懂“什么是一個單子(monad)?”和“這是一個函子(functor)?”等問題,但要知道不能一直改變數據——使用新值創建一個新元素(將數據視為不可變),并盡可能使函數/類不保留某些內部狀態(純函數/類)。

認知成本是可讀性的殺手

“認知失調”是一種高大上的說法,但其實意思就是“我需要同時記住兩個(或更多)不同的東西才能理解這一點。”把這些不同的東西保留在你的頭腦中會產生成本,并且事物之間關聯性越小,這種成本就越會不斷積累(因為你必須把所有這些都記在腦子里)。

例如,將布爾值相加以計算True的數量就是一種輕微的認知不協調;如果你正在閱讀一段代碼并看到一個sum()函數,你知道它是列表中所有數字的總和,你就預料到列表由數字組成,但我看到過人們使用sum函數計算布爾值列表中的True的數量,這也太特么容易讓人糊涂了吧。

Magical Number 7 ,正負二(7+- 2 的范圍內)

“magical number”是一篇心理學文章中提到的概念,意思指人們可以在同一時間記住的事物的數量。如果你有一個函數,它調用一個調用函數的函數,該函數又調用一個調用函數的函數……再往下說下去你可能要瘋。

想一想:我會得到這個函數的結果,然后將它傳遞給第二個函數,得到它的結果,然后傳遞給第三個函數。但是:

當今,心理學家更多地談論Magical Number 4,而不是7。

把函數當成寫作文(如“我將調用該函數,然后該函數,然后該函數......”),而不是函數作為主體(如“該函數將調用該函數,將調用該函數......”) 。

走捷徑挺nice的,但只是在短期內如此

許多語言、庫、框架都有縮短工作時間的方法,減少了需要你打字輸入的內容。但是,稍后,這些東西會讓你栽跟頭,你將不得不棄用這些捷徑并懂得人間正道是滄桑的道理。

因此,在使用之前,先了解那些捷徑是如何做事情的。

你不需要先用難的方式寫東西然后再用捷徑的方式清理:你只需要走捷徑在后臺做事情,所以你至少知道使用它可能出錯的地方在哪里,以及如何用非捷徑方式替換它。

抵制“輕松”的誘惑

當然IDE會幫助你完成大量的自動填充并讓你輕松構建你的項目,但是你明白發生了什么嗎?你了解你的構建系統是如何工作的嗎?如果你必須在沒有IDE的情況下運行你的程序,你知道該怎么做嗎?如果沒有自動填充你能記住你的函數名嗎?是不是有辦法打破/重命名一些東西讓它們更容易被理解?......

要對窗簾后面的東西保持好奇。

總是在你的日期中使用時區

處理日期時請始終添加時區。你的計算機時區和生產服務器時區(或其中一個實例時區)將始終存在問題,你將花大量時間來調試為什么界面總是顯示錯誤的時間。

總是使用UTF-8

在日期上出現的問題,也將出現在對字符的編碼上。所以時刻記得將你的字符串轉換為UTF8,將它們作為UTF8 保存在數據庫中,在你的API上返回UTF8。

你可以轉換為任何其他編碼方式,但UTF8 贏得了編碼戰爭,因此更容易保持這種方式。

從笨辦法開始

遠離IDE的一種方法是“從笨辦法開始”:只需獲取編譯器并獲得一個帶有代碼突出顯示的編輯器(任何編輯器),做你該做的事情:寫代碼,構建它,運行它。

不,這并不容易。但是當你跳進某個IDE時,你看到某個按鈕只會簡單地想,“是的,它會運行它”(順便說一下,這正是IDE所做的)。

日志用于事件,而不是用戶界面

很長一段時間,我使用日志向用戶顯示正在發生的事情——因為,你知道的,使用單個東西會更容易一些。

使用標準輸出通知用戶發生了什么事件,使用標準錯誤通知用戶有關錯誤的信息,但使用日志來捕捉可以在日后輕松處理的東西。

將日志想成是你必須解析以便在那時從中提取一些信息的東西,而不是用戶界面,它不一定要是讓人看得懂的明文。

Debugger們被高估了

我常常聽到很多人抱怨,不能Debug的編輯器有多糟糕。

但是當你的代碼投入生產時,你無法運行你喜歡的Debugger;哎呀,你甚至不能運行自己喜歡的IDE;但是logging......logging隨處都可以運行......你可能在崩潰時沒有所需的信息(例如,不同的日志記錄級別),但你可以啟用日志記錄以便稍后找出某些內容。

不是說Debugger們很糟糕,只是它們沒有大多數人想象的那么有用。

始終使用版本控制系統

“這只是個隨便寫的破程序,我只想學點東西”——這不是一個不使用版本控制系統的好借口。如果你從一開始就使用版本控制系統,那么當你做了一些傻事時,撤銷會更容易。

每次提交一個更改

我見過人們編寫提交消息,如“修復了問題#1,# 2 和#3”。除非所有這些問題都是重復的——那么其中兩個應該已經不存在——它們應該分三次提交,而不是一次。

嘗試在每次提交中只進行一項更改(并且這里的更改并不是“一個文件更改”; 如果一個更改需要更改三個文件,你應該將這三個文件一起提交。想想“如果我還原這一步,那是什么消失了?“)

當你過度交換時,“git add -p”是你的朋友

(僅限Git的主題)Git允許使用“-p”部分合并文件,這允許你僅選擇相關更改并不管其他更改——可能是為了新的一項提交。

按數據/類型組織項目,而不是功能

大多數項目的組織如下:

換句話說,它們使數據按功能分類組織(所有傳入的模型都在同一目錄/包中,所有過濾器都在同一個目錄/包中,依此類推)。

這很好,很有效。但是當你按照數據進行組織時,將項目拆分到較小的項目中會更容易——因為在某些時候,可能你想要做的與你現在正在做的幾乎一樣,只是有些許小的差異。

現在,你可以創建一個僅處理Data1 的模塊,另一個僅適用于Data2 的模塊,依此類推,然后你就可以將它們分解為獨立的模塊了。然后當你有另一個項目也有Data1 但也處理Data3 時,你可以重新用上Data1 模塊中的大部分內容。

創建庫

我已經見過很多項目要么創建一個包含不同項目的大型存儲庫,要么保留不同的分支,這些分支不被用作以后加入主要開發區域的臨時環境,而作為一個小而不同的東西延續下去了(從上文講到的模塊化角度來說,請想象一下,我沒有構建一個重用Data1 類型的新項目,而是擁有一個具有完全不同的主函數和Data3 類型的分支)。

為什么不將公共部分拆分出來加到庫里并在不同的項目中應用它呢?

原因在于,大多數情況下,“因為人們要么是不知道如何創建庫,要么是他們擔心如何將這些庫‘發布’到依賴源中而不致泄露(因此也許你也應該了解你的項目管理工具如何檢索依賴項,以便你可以創建自己的依賴項存儲庫)。”

學會監控

從前,為了理解系統的行為方式,我添加了大量的指標:輸入速度、輸出速度、中間滯留數量、已處理的數量......這樣可以很好地了解系統的行為方式:速度在下降嗎?如果是的,那我可以檢查正在輸入系統的內容以了解原因。在某些時候下降是否正常?......

事實上,在此之后,試圖查明一個沒有任何監控的系統有多健康就變得很奇怪,僅使用“是否應答請求”來檢查系統運行狀況不再適用。

盡早添加監控將有助于你了解系統的行為方式。

config文件是個好東西

想象一下,你編寫了一個函數,你必須為它傳入一個初始值才能開始運行(例如,一個推特用戶帳戶ID)。但是后來你又必須用兩個值來做,所以你就直接用另一個值再次調用了該函數。

使用配置文件更有道理,只需使用兩個不同的config文件運行應用程序兩次。

命令行選項很奇怪,但很有幫助

如果你將某樣東西移動到config文件,你還可以通過添加選項來選擇配置文件并公開它來幫助用戶。

現在對每種語言的命令行選項都有一些庫可以處理,這將有助于你構建一個良好的命令行,并為你的用戶提供一個標準的接口。

不僅僅是功能組成,還有應用程序組成

Unix自帶“應用程序只做一件事,并且把它做好”的理念。

如今,我說你可以使用一個帶有兩個配置文件的應用程序,但是如果你需要兩個應用程序的結果呢?那時你可以編寫一個應用程序,用兩個配置文件讀取第一個的結果并轉換為單個結果。

即使是做APP,也要從原始的東西開始

APP的開發可能會涉及微服務——這很好——但微服務需要一些關于應用程序如何通過線路(協議等)在彼此之間“對話”的想法。你不需要從那開始,應用程序都可以從文件中寫入和讀取,這樣容易多了。

當你了解了網絡是如何工作后,再通過電話進行交談時可能會擔心的吧。

優化是面向編譯器的

假設你需要更高的性能,你可能很想看看你的代碼和“可以在這里擠出更多性能的東西”或“如何在這里刪除幾個循環來獲得更多速度”。

好吧,猜猜怎么著?編譯器知道如何做到這一點。智能化的編譯器甚至可以刪除你的部分代碼,因為它始終會生成相同的結果。你需要做的是為代碼考慮更好的設計,而不是如何改進當前代碼。

代碼是為了讓人類閱讀的、優化面向編譯器的,因此,找到一種智能的方法來解釋你在嘗試做的是什么(在代碼中)而不是使用更少的話語來表述。

通過懶惰(評估)

Lisp很久以前就這么做了,而現在大多數語言都是這樣做的。

例如,Python有yield語句,它將停止當前函數的執行并立即返回值,只有在再次調用該函數時才會產生新值。如果你將使用yield的函數鏈接起來,則不需要像保留返回列表的函數那樣多的內存。

在團隊/工作上

code review并不是為了彰顯風格

花點時間進行code review,指出架構或設計問題,而不是代碼樣式(風格)問題。沒有人真正喜歡那些在code review中寫“你在這一行中留下空白了”或“括號前缺少空格”的人。

現在,如果你確實發現了架構或設計問題,那么你可以順便說一下代碼風格問題。

代碼格式化工具還可以,但它們也不是無往不勝的

團隊可能想要避免在code review中討論樣式,因而可能會考慮使用代碼格式化工具在提交之前自動格式化代碼。

是的,這部分解決了這個問題,但是還有一個小問題:我們人類不像計算機那樣能靈活地閱讀代碼,計算機可讀的內容可能無法被人閱讀。當然,有人試圖在有利于人類閱讀的方面創造一些啟發式方法,但這并不意味著這些方法正確。

如果你使用代碼格式化工具,請使用它來找出最能更改代碼的位置。你可能需要簡化這一部分的代碼,以避免它出現混亂。

代碼風格:遵循它就是了

如果你的項目具有已被定義的代碼樣式,則必須遵循它。有時可能不清楚(“這個結構/類應該是單數還是復數”?),但請盡力遵循它。

...除非代碼樣式是Google Code樣式

(完全個人觀點,你不同意也沒關系)每次谷歌發布自己的編碼風格,都是一場垃圾焚燒。社區之前采用了更好的風格方式,谷歌帶來一個與此很不相同的的風格,只是為了能使其在自己名下。

C / C ++只有一種編碼風格:K&R

(再次,完全個人意見)其他所有編碼風格都是錯誤的。(笑)

Python只有一種編碼風格:PEP8

社區(大部分)使用PEP8 風格,遵循它,那么你的代碼可以順利地與生態系統中的其他部分集成。

顯式優于隱式

你知道什么是有史以來最糟糕的函數名稱之一嗎?sleep()。

睡了多久?是幾秒還是幾毫秒?

對你使用的東西要表達地明確一些,sleepForSecs和sleepForMs并不完美,但比一個單純的sleep更好。

(當你編寫應用程序命令行界面或其配置文件時,請考慮這一點。)

(我可以在這里拋出整個“Python之禪”,但我正在努力專注于講個人的,直接的體驗。)

公司想要專才,但全才在公司待的時間更長

如果你對單一語言了解很多,那么它可能會讓你更容易找到一份工作,但從長遠來看,一門語言的使用可能會消失,你就需要再學一門別的語言了。適當了解許多門其他語言有助于長遠發展,更不用說這可能有助于你想出更好的解決方案了。

“一種不能影響你對編程的思考方式的語言,不值得了解。”——Alan Perlis

很長一段時間,我遵循著一個簡單的編程規則:我在家里用來玩的語言不應該是我在工作中使用的語言。這使我能夠接觸到后來我在工作代碼庫中應用的新內容。

我通過編寫Rust代碼了解了泛型如何在Java中工作;我理解了Spring如何完成依賴注入因為我之前有學過如何在C++中實現。

心中有用戶

想一想你將如何使用你從用戶那里收集的數據——這在當今“隱私”變為一種奢侈的時代更為普遍。

如果你捕獲任何使用數據,請記住保護它免遭未經授權的使用。

處理用戶數據的最佳安全方法是壓根不捕獲它

你可以確定,在某些時候,數據會因某些安全漏洞或人為干擾而泄漏。如果你沒有捕獲任何用戶數據——或以匿名方式存儲——你將不會遇到任何問題。

記下來那些“讓我花了一個多小時才解決的愚蠢失誤”

我嘗試過,但從未真正建成過一個列表來記錄那些需要花一個多小時才能修正的失誤,這種失誤僅僅是“忘了添加依賴”或“添加注釋”一類,可我不止一次與這些愚蠢的失誤作斗爭了。

但你應該嘗試保留一個列表來記錄那些讓你花了一個多小時才解決的愚蠢失誤,因為有了它以后你解決起這類失誤來要更快一些。

如果它無法在你的計算機上運行,那么你就有麻煩了

我看過很多系統永遠無法在孤立的計算機上運行,比如開發人員工具,因為系統需要在專門的環境中運行。

這真的會扼殺生產力。

如果你的系統將在一個專門的環境中運行——包括“云”——那就去找可以抽象你所用之物的東西。例如,如果你使用的是AWS SQS(隊列),請找到一個可以抽象隊列工作方式的庫,這樣你也可以使用RabbitMQ了,就可以在你自己的計算機上輕松運行了。

如果你使用的是非常專門化的東西,你可能必須自己編寫抽象邏輯了,將其與主系統隔離,這樣你就可以安心開發主要產品。

 

 
 
[ 站長資訊搜索 ]  [ 加入收藏 ]  [ 告訴好友 ]  [ 打印本文 ]  [ 違規舉報 ]  [ 關閉窗口 ]

 
0條 [查看全部]  相關評論

 
推薦圖文
點擊排行
 
網站首頁 | 網站地圖 | 廣告服務 | 積分換禮 | 網站留言 | RSS訂閱 | 閩ICP備17002783號
評論內容只代表網友觀點,與搜聯盟-廣告聯盟點評網立場無關!請網友注意辨別評論內容。
Powered by SoLMw.com
 
体彩大乐透预测爱彩网