6年iOS開發，自述通往 架構師的四條路線，（頭條熱搜）
前言：
我用了6年的時間，一步一步走到了現在，中途也有了解過其他的技術，也想過要轉其他的語言，但是最後還是堅持下來走iOS這條路，希望我的經歷可以幫助到後來的人，要是覺得對你有幫助的話，可以點贊關注一下。
導讀：
1、架構師應不應該寫程式碼
2、為什麼別人的系統總是那麼爛
3、成為架構師最困難的門檻是什麼？
4、如何更高效的學習？
作為一個開發者，有一個學習的氛圍跟一個交流圈子特別重要，這是一個我的iOS交流群：638302184，不管你是小白還是大牛歡迎入駐 ，分享BAT,阿里面試題、面試經驗，討論技術， 大家一起交流學習成長！希望幫助開發者少走彎路。
1.架構師應不應該寫程式碼
合格的程式員對於明確分配的任務會完成的很好，但是大部分情況下“架構”這個詞意味著架構師並不會涉及太多細節，架構圖和程式碼實現之間總還是有些距離，你無法保證所有人都會正確的理解你的設計，或者是程式設計師寫程式碼時遇到障礙時會立刻想出足夠優雅的解決方案。
在我看來，寫程式碼的架構師更像是在做後勤保障的工作：在程式碼中第一時間發現可能存在的問題，向其他人提出警告，或是給予其他人改進的意見，必要的時候或是給其他人演示一下正確的姿勢。
大部分情況下我作為架構師並不需要攬下“核心模組”開發這種工作，畢竟我能調配的時間太零散了，效率難以保證，很多人在專注的情況下比我做的好很多，我只需要保持大局觀需要適度參與就可以了。
總的來說，架構師和程式設計師在某些方面上有點像產品經理和使用者的關係，大部分程式設計師並不會主動告訴你他們想要什麼、哪裡需要優化，甚至自己也不知道這些。想要做出好的產品，捷徑之一就是跟使用者做同樣的事情。
2.為什麼別人的系統總是那麼爛
很多程式員解決問題的能力很強，說要解決一個什麼問題，下午就能寫出幾百行程式碼把功能實現了。但是做出來的東西有種少考慮了什麼東西的感覺。大部分程式都能實現功能，但是如果把“時間”這個也作為一個考慮的維度的話，就會意識到一個合格的專案需要考慮更多的東西：更通用的使用方式、易於理解的文件、簡單而易於擴充套件的設計，等等。
很多公司應該都會有一些遺留系統，它們龐大、笨重、難用、幾乎無法維護，所有人都在抱怨這些系統，並且每天都在想方設法換掉那些遺留系統。但是一段時間過去之後，又會發現身邊的新人又開始吐槽當時替代遺留系統的那個系統了。
“大多數系統當初都很好使，功能當時夠用，擴充套件性看起來也可以，但是這些系統都是開發的人離職之後變壞的。”
3.成為架構師最困難的門檻是什麼？
很多人自稱架構師的人跟你講一個架構時簡直滔滔不絕，各種技術名詞像是說相聲一樣從他嘴裡說出來，三句話不離高併發大資料，但是稍微追問一下，就會發現很多基本概念的缺失，例如自稱精通高併發的人說不清楚他所謂的高併發系統的瓶頸在哪裡，自稱精通架構設計的人說不明白他的系統怎麼保證高可用，自稱超大資料量的系統實際上只有不到100萬條資料，等等。
架構師雖然聽起來很高大上，但本質上仍然是工程師，不是科學家，也不是忽悠人的江湖騙子。學習再多，也需要實踐落地。設計架構方案更多的是在做一些抽象和權衡：把複雜的需求抽象成簡單的模型，從功能、效能、可用性、研發成本等等方面規劃如何構建一個系統，這些內容需要更多的實踐練習。
4.如何更高效的學習？
大多數人每天能留給自己學習的時間有限，這個階段如何提升學習效率就成了要解決的重點。
說說自己提升學習效率的心得，其實非常簡單：體系化的學習。
在重複了幾次痛苦的學習-梳理過程後，再去看一些獨立的文章或者資料往往會事半功倍，因為能在體系內找到相對應的知識，甚至有時候一本書裡一頁只需要看一句話，點破那層窗戶紙，就可以掌握新的知識。
跟很多人一樣，剛畢業時我覺得作為程式設計師，只要努力，加上少許天賦便可以獲得一些成績。
工作一段時間後，對自己和其他人的認識也越來越清晰，逐漸的發現程式設計師之間的差距或許比人和猴子之間的差距還大，接受這個事實這讓我鬱悶了很久。
再過一段時間，發現自己已經能夠客觀的評價自己的能力，也意識到了距離並不是那麼重要，只要想辦法跑的更快，就足夠了。
隨著軟體和網際網路技術體系的發展，架構師這個職位已經可以切出很多細分，系統架構師、應用架構師、測試架構師以及基礎設施架構師等等。除此之外，在不同的公司還會有各種特定的分發，在這裡就不一一展開了。在這裡，我們結合最常規的應用架構師和系統架構師來做一個說明。
5.先說說，架構師職務和責任的定義：
應用架構師（ Application Architect） 負責構建一個以 解決特定問題 為目標的軟體應用的內部結合結構，一般以滿足各種功能性需求以及維護性需求為設計考慮目標；
系統架構師（System Architect）則提供 運營支撐 軟體應用的資訊系統的結構設計，一般以滿足各種非功能性需求或運營性需求為設計目標（如安全性、可伸縮性、可互操作性等等）。
1 設計能力－擅長整合分析
架構是過程，並非結果。
架構是架構師洞察內在結構、原則、規律與邏輯的過程，架構師要做到清晰理解系統，以及簡潔描述，這是分析整合的能力。
一個架構師必須具備優秀的分析能力，要做到根據產品需求和目標，理解清楚產品業務，再整合利用現有的技術領域，找出最佳方案，實現產品概念。
2 技術實力－通過程式碼落地
架構師首先要將程式碼寫的清晰易懂，要能夠實現功能，做到沒有Bug，這要求架構師必須具備至少熟練掌握一門語言。
這是最重要的，一名出色的架構師，基本上過去都是一位優秀的程式設計師。架構師並不是純粹的管理崗位，所以需要深入到一線去梳理程式碼的。如果只是畫流程圖、脫離程式碼、只說不做，是很難做好工作的。
反過來說，提高程式設計技能，對一名架構師的職業生涯至關重要，無論如何都不可本末倒置，要想實現自己的職業規劃，不能荒廢自己本身的技能，技術是架構師賴以生存的最基本能力。
所以，不推薦不熱愛程式設計的人去做架構師，對於團隊工作和個人發展來說，都會帶來糟糕的後果。
3 學習能力 － 掌握技術的發展方向
作為一名架構師，積極開放的心態最重要，因為持有這樣心態的人，才能高效的學習新的新技術。
新技術層出不窮，架構師需要不斷去了解他們的優缺點，掌握他們，然後為我所用。更重要的是，需要學習和掌握每一樣技術背後的真正原理。所以不斷拓展技術的深度和廣度，是一名優秀的架構師的成長軌跡。
網際網路是一個技術更新非常頻繁的行業，只有真正有熱情並掌握了好的學的方法的人，才能走的長久。
4 溝通能力－能夠橫向溝通
架構師必須參與專案開發全過程，包括確認需求、系統分解、架構設計、技術選型、制定技術規格說明、系統實現、整合測試和部署各階段，在這一系列過程中，架構師會與各部門溝通交流。
一個產品的研發會有多部門合作，架構師在其中的溝通極為重要，直接影響研發的進度與質量。架構師不僅要與開發人員溝通，也要和專案經理、產品經理甚至使用者溝通，來梳理產品的各種可能性。
所以，對於架構師而言，不但要有紮實的技術，還需要能夠橫向溝通的能力。
總結：
以上就是我總結出來的知識路線，中途也有了解過其他的技術，但是最後還是堅持下來走iOS這條路，希望這些知識點可以幫助在這個行業發展的朋友和夥伴們，在論壇部落格等地方少花些時間找資料，把有限的時間，真正放在學習和前進上。
作為一個開發者，有一個學習的氛圍跟一個交流圈子特別重要這是一個我的iOS交流群：638302184，不管你是小白還是大牛歡迎入駐 ，分享BAT,面試題、面試經驗，討論技術， 大家一起交流學習成長！
文章來源於網路，如有侵權，請聯絡小編刪除。