我是kurio（來自印度尼西亞的一款新聞聚合器）的軟體工程師。kurio是一款聚合器應用程式，我們的主要工作是：收集發布合作夥伴**上的新聞或文章，並通過我們的應用程式將其提供給使用者。
與其他新聞聚合器一樣，我們為使用者提供了多種新聞內容，例如按我們的top_stories邏輯進行排序的新聞、按照趨勢進行分類的新聞以及來自特定發布商的新聞。
移動端的kurio新聞布局
feed的構建過程由我們的feed服務負責處理。
這個服務是kurio的三大主要專案之一，之前的版本已經執行了很長一段時間。因此，它變得非常複雜，有時也會難以理解。這也使得新增新功能變得非常困難。因此，我們決定重建我們的feed服務。希望通過這個新版本的feed服務，我們可以輕鬆新增新功能或者使其更易於維護。
首先我們需要了解以前的系統是如何工作的。從編譯、測試和部署開始，直到收到使用者請求，我們需要知道整個過程的工作原理。
因為這是乙個核心的服務，而我剛剛來這裡一年，我真的不知道它是如何運作的，尤其是多年來整個系統新增了很多額外的功能和補丁，很難通過閱讀**來了解它。所以，我們需要了解流程和規則，然後基於這些流程和規則構建新的流程和規則。
例如，當使用者開啟應用程式時，會得到由這項服務提供的top_stories新聞源。或者是一些規則，例如：在top_stories新聞源中向使用者顯示的內容是有限制的。或者類似於：不要向使用者展示他們不關注的主題，或者根據使用者的屬性（性別、年齡等）顯示新聞。
列出這些規則和流程是一件簡單的事情，難就難在如何將其轉換為**。一般來說，我們的流程非常簡單，如下所示。
使用者獲取新聞的流程
基本上主要是兩個大功能，獲取個性化新聞和獲取預設新聞。最難的是獲取個性化新聞，因為我們必須將它與個性化引擎相結合。此外，我們必須遵循一些與上面提到的個性化內容相關的規則（提取使用者興趣和屬性，然後根據使用者的興趣構建新聞源）。
我們之所以要重構這個服務，是因為當我們要新增新功能時，之前系統的**架構無法很好地擴充套件。如果要在未來開發新功能會非常痛苦，因為我們不得不重構很多東西。
所以我們真正需要的是修復架構。設計乙個新的架構真的很難。我們需要問自己很多問題，比如：「這樣做會怎樣？」、「為什麼要這樣？」、「為什麼不是這樣？」我們希望新架構能夠解決「未來」的問題，並提供向後相容性。為此，我們進行了大約乙個月的討論，針對每個大功能進行了技術棧和流程方面的討論。
最終，我們決定嘗試一些函式式的開發方式。我們放棄了之前使用的**架構，發明了一種新的**架構，帶有函式式程式設計（使用高階函式模式）的味道，但又不像lisp或clojure那麼動態。
因此，在我們的**中可以找到很多hof（高階函式）模式，如下所示：
func something(params, func(params)) (func(params)){}因此，我們意識到go語言不適合用來解決我們的問題，但在我們這10個後端工程師當中，只有乙個人了解clojure（函式式程式設計），而學習新的程式語言就意味著我們需要額外的時間。經過長時間的討論，我們決定繼續使用go語言，不僅是因為我們所有的後端工程師都很了解go語言，也是因為go語言已經在很多微服務中得到驗證。
在將流程和設計轉換為**時，我意識到我們必須對基礎有乙個真正的了解。一開始，我並沒有真正理解高階函式的工作原理。在閱讀**時感到很困惑，怎麼總是乙個函式接收乙個函式作為引數然後再返回乙個函式呢？不過要感謝谷歌，我現在終於明白了。
我們還需要了解go語言本身的基礎知識，比如使用指標作為函式接收器、datetime的基礎知識，以及很多其他基礎的東西。如果我們對這些東西不了解，只會增加完成這個專案的時間。
優化的第一條規則——不要優化
優化的第二條規則——還不到優化的時候
優化前先分析
因此，在開發這個服務時，我們的第乙個目標是確保至少可以執行它。我們沒有去考慮效能問題，並試圖忽略任何有關優化的事情，例如使用go例程。
在開發完**後，我們就可以編譯並執行它，所有請求都能被正常處理，響應也很正常。當然，初始版本速度非常慢。與之前的系統相比，它慢了十倍。以前的系統在使用staging伺服器時單個api請求大約需要500毫秒，而新版本需要50000毫秒（約50秒）或更久。
優化**也是我們最重要的任務之一。為了優化我們的**，我們遵循了以下步驟：
找出需要長時間處理的迴圈**，將其轉換為使用go例程，提高並行性或使用管道。
分析系統並檢測所有速度慢的功能，對其進行優化。所幸的是，在go語言中進行分析很容易。借助pprof（工具，我們可以對系統進行分析並檢測所有速度慢的功能。我們甚至可以檢測出我們所使用的哪個庫最慢，這樣我們就可以使用具有類似功能的另乙個庫替換它們。
如果有必要，增加快取。
構建服務時，我們的規則是只在確實需要使用快取的情況下使用快取。快取就像一種藥物，它會讓我們上癮，因為當我們的系統看起來很慢時，會把快取看成是解決問題的靈丹妙藥。通常，在開發大型併發專案時沉迷於使用「快取」的人，首先想到的是「快取」，而不是先考慮優化（基準測試、分析）功能（邏輯/演算法）。
對於我們的情況，我們通過兩種方式來使用快取：
通過這種優化，我們至少可以像在以前的系統中那樣改進新系統的效能（staging伺服器的響應時間約為400毫秒，生產伺服器的響應時間約為180毫秒）。
基於語義版本控制，在不新增新特性和不破壞api的情況下進行重新構建就不算是乙個新的版本。基本上，在這個新重建的系統中，我們的目標是改變架構，而不是api規範。因此，無論我們在系統中進行做出哪些變更，都不能更改api。因為即使是非常微小的變化也會影響到所有相關的服務。
為了讓它成為乙個新版本，我們對錯誤響應訊息正文進行了一些修改。
原始錯誤響應訊息正文：
}在重新構建這個服務時，我們至少進行了三次測試，然後才發布到生產環境中：單元測試、整合測試和負載測試。
在所有這些型別的測試中，單元測試是最小的測試。有些人似乎低估了單元測試的重要性，因為它只是乙個單元，乙個小功能。但是，在重建這個新服務時，我體會到了單元測試的重要性。
在sprint開始時，我們忽略了單元測試，因為我們希望專注在**架構的設計上。所以我們開發了一些沒有任何測試的功能。我們這樣做是因為我們仍然在構建一些實驗性的**架構，為了避免進行不必要的單元測試重構，我們在這個時候沒有建立任何單元測試。
但是，在完成**架構設計之後，我們忘了為在sprint開始時建立的功能新增單元測試。直到我們將它部署到staging伺服器並與另乙個真實服務進行了整合測試。我們在應用程式中發現了很多錯誤。然後我們檢視了源**，發現我們的功能有很多條件都沒有覆蓋到。
知道了這個問題後，我們意識到我們還沒有測試過這個功能。它還沒有通過單元測試。如果我們從一開始就進行單元測試，那麼修復這個問題並重新部署它就不需要做額外的工作。在進行單元測試時，我們可以考慮很多不同情況，並在部署應用程式之前修復它們。
雖然我們做的是幕後工作，並且對我們的使用者沒有可見的影響，但我們確實學到了很多東西。我學到了很多關於如何從頭開始構建高併發系統的知識。完成這項任務後，我知道了為什麼當我們在面試後端開發職位時，總會被問及邏輯和演算法問題。這是因為在構建高併發系統時，效能是非常重要的方面，任何演算法都會影響到系統的響應時間。
英文原文：
重構了後端服務，我學到了這些東西
我是kurio 來自印度尼西亞的一款新聞聚合器 的軟體工程師。kurio是一款聚合器應用程式，我們的主要工作是 收集發布合作夥伴 上的新聞或文章，並通過我們的應用程式將其提供給使用者。與其他新聞聚合器一樣，我們為使用者提供了多種新聞內容，例如按我們的top stories邏輯進行排序的新聞 按照趨勢...
重構了後端服務，我學到了這些東西
我是kurio 來自印度尼西亞的一款新聞聚合器 的軟體工程師。kurio是一款聚合器應用程式，我們的主要工作是 收集發布合作夥伴 上的新聞或文章，並通過我們的應用程式將其提供給使用者。與其他新聞聚合器一樣，我們為使用者提供了多種新聞內容，例如按我們的top stories邏輯進行排序的新聞 按照趨勢...
我學到了什麼 我思考了什麼
經理是個搞開發搞了十多年的人,甚至自己開發了框架並投入使用了.搞得外包,全國各地都跑過.可以自豪的說哪哪公司什麼系統參與搞過,人生閱歷非常豐富.我思考最多的應該是我哥跟我說後來經理也說過的話,我哥說時候我不太有感覺,經理說時候還舉了個例子.意思就是人在三十前都不是掙錢的時候.是投資自己的時候.去給自...