加快現代建築的步伐

Question

我沒有任何計算機科學的正式資格，而是在互聯網泡沫時代，我教了自己經典的ASP，並設法讓自己找到一份工作，我的職業生涯從此開始。我對ASP 3的程序員很有信心，我認爲這是一位很好的程序員，但正如其他人觀察到的，傳統ASP的一個問題是它在隱藏http的本質上做得非常好，所以你可以變得非常勝任一個程序員是基於對你正在使用的技術相對較差的理解。

當我開始轉向.NET時，我把它當作經典的ASP來處理，因爲我當時並不知道任何更好的東西，所以將獨立應用程序開發爲單個網站。我在這一點上轉移了工作，並在接下來的幾年中花費在一個單獨的站點上，這些站點的架構嚴重依賴於自定義對象：換句話說，我獲得了很多使用.NET作爲中間層開發工具的經驗，沿着經常用於教OO的經典「汽車」類示例的方式進行OO設計。將程序分解爲多個功能塊，並圍繞這些功能建立類和方法。儘管我們採用敏捷方法來管理工作，但整個設置仍然是經典的客戶端/服務器。這適合我，我逐漸接觸.NET，並開始以它應該的方式使用它，並且我開始看到技術中固有的力量，以及它爲什麼比好的ASP 3更好

在我最近的工作中，我發現自己突然陷入了與兩個相當年輕，技術嫺熟和非常尖端的程序員的深層次。他們已經建立了一個網站架構，它沿着很多新東西進行建模，而這些東西對我來說都是新的，事實上我有很多麻煩的理解。該應用程序建立在具有多租戶的雲計算模型上，並且該架構全部使用大量接口，工廠等進行鬆散耦合。他們也使用nHibernate。我加入後不久，這兩個人就離開了，我現在應該是一個系統的高級開發人員，他的技術和架構我不太瞭解，我也沒有人提問。

除了你，互聯網。

坦率地說，我覺得我已經在深處投入了，而我正在下沉。我不確定是否這是因爲我缺乏理解這些東西的教育背景，如果我現在對數學計算沒有足夠的數學意義（我的數學從來都不是很好 - 我的設計方法通常只是調試直到它工作，然後重構，直到看起來整潔），或者我是否只是一次性提出太多過於激進的本質。但找出它是唯一的方法是嘗試和學習它。

所以任何人都可以建議一些好的地方開始？好的書籍，教程或博客？我發現很多互聯網材料只是預設了我沒有的理解水平。

您的建議非常感謝。幫助一箇中年人，陷入泥土開發者再次激起熱情！

請！

Answer 1

坐在沙灘上 - 準備

製作一個你不明白的東西的清單。在最後階段，這個清單應該是你的清單。清除你的想法 - 讓自己重新開始，「忘記」你已經瞭解的關於你的架構的所有令人困惑的細節。 挖掘由原始建築師創建的每個文檔。 獲取項目中使用的每種技術的文檔。 做咖啡。

浮動 - 管理複雜

浮動，你需要管理的複雜性。如果你沒有正確處理複雜性，當你完全沒有必要的時候，你會深入細節，你不知道如何以及在哪裏停止，沉入底部並溺水。

「我對設計方法往往 簡直調試，直到它的工作原理，然後 重構，直到它看起來整潔」

我想我曾經是你一樣。我從頭開始開發解決方案，一次添加一件，最終在我頭腦中包含一個複雜的結構。我沒有規劃架構，我沒有分離設計和實現，我只是編碼，調試，重構。它的工作原理是：由於複雜性增長緩慢，所以我不難理解出現的架構。

當「繼承」他人計劃的複雜架構時，這種方法根本不夠好;你不能一次吞下整個結構 - 因爲細節太多了，你不能隨意吞下一點點 - 因爲你不會理解它們是如何相互關聯的，你永遠也看不到大局。

軟件是複雜性管理的難題。有很大的部分，有時被稱爲「子系統」，構成了全局。每一個都由較小的部分組成，而這些部分又由較小的部分組成。當你看代碼時，你看到的只是最小的一塊。所以現在忘記代碼本身，至少在你看到所有更大的代碼之前。

游泳 - 映射的架構

走向浮動是看到了大塊的第一步。要做到這一點，你需要地圖。最大塊的地圖是最高級的架構。如果原來的建築師沒有給你這樣的地圖，你必須自己創建。就像從山谷內部映射一個區域是不可能的，你不能從低層次的細節映射你的架構。您需要站在山頂才能360度觀察所有的山谷，山丘和小徑。您需要從頂部映射您的架構。

擁有此頂層地圖後，您應該爲構成它的部分獲取地圖 - 就像創建整個地區的非詳細地圖一樣，然後創建分區域的單獨詳細地圖。地圖應描述不同的子系統。至少應該描述每個子系統的責任，其外部接口以及它如何與其他子系統交互。

跳水 - 管理細節

有這一原則潛水它說你不應該深處過快之間移動，因爲在壓力的變化。這個原則成立。當您從處理一個子系統轉變爲處理其內部子系統時，請確保您只是進入下一個複雜性/抽象級別。讓你的頭腦一次處理一層。

單獨的概念，模式，接口和實現。 nHibernate是一個對象關係映射（ORM）解決方案。因此，在處理nHibernate本身的細節之前，您需要確保您瞭解ORM的一般概念及其在世界中的位置。工廠是一種設計模式，所以在處理工廠之前，您應該瞭解什麼樣的設計模式以及它們的作用。

技術上升和下降，但概念依然存在。一旦你瞭解了這些概念，在架構層面上，這些概念如何表現出來並不重要。

，你的架構鬆耦合的事實其實是一件好事，因爲這意味着你能理解一個子系統的作用，而不需要知道很多關於其他子系統。您的架構使用接口的事實也很好 - 這意味着您可以瞭解元素如何互相交互，而無需瞭解其內部如何工作。

滑水 - 獲取知識精華

有一本書，我認爲這是一個「必讀」：代碼完成由史蒂夫·麥康奈爾。它改變了我的職業生涯。

---

我希望這篇文章能以某種方式幫助你，而不是完全浪費你的時間。

Answer 2

Patterns of Enterprise Application Architecture是一本很好的書，馬丁是個傳奇。

Answer 3

如果是關於架構，如果是關於Microsoft開發堆棧，我總是會看到Pattern & Practices。

他們有很多關於各種應用程序類型的體系結構的優秀白皮書/書籍。

Answer 4

除了很多很好的資源已經在答案中列出並且很可能會被列出，稍有不同的建議 - 使用StackOverflow。

你似乎能夠寫得非常周到，可讀，敢於說出很好的問題。因此，只要某個特定的特定的架構選擇/模式或代碼段沒有任何意義，可以隨意將它變成一個SO問題（顯然是在自己重新研究一下之後理想的情況下）。

此外，關於你的觀點重：數學：

至於軟件工程而言，你真正需要的大部分時間只有數學是：

• 「離散的數學」 - 集合，圖表，樹木等...及其實際應用到數據結構和算法

• 一個有限的代數技能集參與分析後者的O（n）複雜度

• 理想情況下，直觀地掌握統計/概率 - 作爲一名通用軟件工程師，您並不總是必須能夠進行高級計算，但感覺「這更可能影響我的情況發生的可能性乘以其影響的大小「通常是設計選擇的良好指導。

然而，一件事是在一個優秀的軟件工程師，往往是無價什麼區別「擅長數學」，從「在數學不好」的人 - 而不是嚴格意義上的相關數學 - 是看模式的能力。

如果你「不擅長數學」的原因是你缺乏模式遵守能力，那麼你將處於很大的劣勢。這是你必須在自己身上訓練超過所有其他人才能成功構建系統的技能/能力，恕我直言。

Answer 5

這裏有一些建議，絕不是完整的how-to或all-in-one答案;

• 在工作日花時間學習新的東西。在你工作的一天中這個時間，因爲它是你工作的一部分。這不是你應該只在晚上或週末做的事情。如果你想花一些時間去學習它，請繼續前進，但不要忘記學習是你工作的一部分，不要忘記你必須在家裏隱藏自己的無知，不知道一切對你的職業生涯是致命的。平衡學習時間和工作時間取決於你。

• 獲得一些大張紙和一盒彩色鉛筆（或MS Visio，如果您願意的話）。開始繪製兩種類型的圖表：

  • 思維導圖，用以圖示您對新技術的理解。如果你不知道什麼思維導圖，請點擊維基百科開始。
  • 您負責的系統架構圖。無論您使用UML還是其他廣泛使用的格式，或者您自己的設計都由您決定。

Answer 6

我見過像你過去的情況也是如此。但通過專門的日常閱讀和parctise，他們似乎和其他任何「年輕的，所謂的優秀程序員」一樣。如果我在你的位置，這是我會做的：

• 分解我的麻煩領域成小塊。
• 將搜索可用於上述列表中的主題的書籍/文章。
• 將自行編碼樣本並對其進行實驗以獲得更好的理解。

話雖如此，不要擔心abt沒有一個數學的心靈彎曲。我自己是一名數學學生，說實話，當我必須使用這些技能時，很多場合都沒有。 「大多數」企業應用程序不需要這種數學技能。除此之外，modenr day apis非常先進，易於使用，因此您不必爲編寫高效的排序算法或任何此類問題而煩惱。

嘗試儘可能多地閱讀設計模式。 「首先設計模式」是一本很好的書，但代碼示例是使用Java語言編寫的（不應該重新考慮）。 「UML蒸餾」是另一本好書。還有很多其他可用的，只是谷歌:)。 另外，請仔細閱讀您現有的系統。

所有最好的..

Answer 7

坦白說，我覺得我已經在深水的一端被投 ，我下沉。 我不知道這是因爲我缺乏 教育背景 瞭解這個東西，如果我根本不 對數學現代 足夠的計算頭腦（我的數學從來沒有 偉大的 - 我的方式來設計往往是 簡單地調試，直到它的工作，然後 重構，直到它看起來整潔），或 是否我簡單地提出了 與太多激進太性質 一次。但要找出 的唯一方法就是嘗試並學習它。

對我而言，這是因爲你缺乏教育背景。人們在學習自己或在工作中經常沒有必要的背景來真正理解框架背後的背後。 一些概念對於所有信息系統都是通用的，我們可以在學校學習它們，因此我們可以理解這些概念如何在每種語言中起作用......您似乎更像一位務實（高效）的程序員，但您會犯錯誤的是您沒有那麼一般的背景（但是在這種情況下，你應該知道你並不孤單......特別是PHP開發我認爲沒有這個背景）。

如何理解代碼與數據庫，ORM之間的關係如Hibernate，如果你不完全知道什麼是事務（我猜你知道如何使用它......（務實的我說！）但你永遠不會聽說過ACID這樣的概念：http://en.wikipedia.org/wiki/ACID，我想你對事務隔離並不瞭解）。

如何使用web服務與，RPC SOA架構，RMI，CORBA ...高效，能夠在你的數據庫數據一致，如果你不知道的一些概念，如2個phaze提交 http://en.wikipedia.org/wiki/Two-phase_commit_protocol

如果您不知道很多設計模式，最佳實踐，並且不知道何時使用它們，那麼如何編寫出色的代碼？

我們可以說很多事情。

事實只是你錯過了工程師學生們所有（通常？）擁有的信息知識的一部分。當我們開始在一所工程師學校工作時，我們並不擅長這些事情，但與您唯一的區別是我們知道非常重要的概念存在以及何時應該使用它們。因此，我們只需閱讀相關內容並應用我們從網絡或我們團隊學到的知識（因爲在學校我們幾乎看不到基礎知識，但在很多技術人員身上）。

我真的認爲對你來說沒有什麼是不可能的，你應該真正瞭解你不瞭解的一般概念，並且你聽到了很多。如果沒有這方面的知識，你就會傾向於重新發明輪子，而你的實用主義會找到一些可行的解決方案，但它們只是有點髒......例如，你的開發人員可以工作，但是當你在系統中引入高負載時，你可能有併發問題，性能問題。這種知識的缺乏是不是在找你一個簡單的背景，但真正需要的，當你有很多複雜的系統上responsabilities的問題...