技術從業者的將來（2）

　　前言

　　新的一年，在暫時沒有工做以及家庭的雙重羈絆的這個週末給本身放了一天假，這樣的時間尤屬可貴。　　

　　我在《致全部.Net者和有夢想的朋友們 - 共勉》這篇文章中提到過，在現在的工做生活不分家的快速節奏中，爲了生活和家庭，咱們必須負重前行，即便天天的時間大部分都給了工做以及家庭，可是咱們仍是要按期給本身清理負面情緒以及釋放壓力，由於只有本身能持續成長，才能更好的抵禦年齡所帶來的危機。　　

　　因此，對於職場人來講，成長永遠應該放在第一位，關注本身的心態以及需求，這就須要給本身時間和空間思考，給本身喘息思考的時間，才能更好的看清楚方向，才能更好的厲行本身的夢想。　　

　　說話即生產力 　　

　　對於大部分技術人員來講，可能咱們都不會注重本身的說話，由於咱們不少人都沒有意識到說話所產生的生產力。

　　爲何說話就是生產力？

　　不知你們有沒發現，跟身邊一些思想層次很高的人談話會很是舒暢，由於這些人能快速的洞悉到問題的本質，一語中的，把問題迴歸到本質上，而不是任由別人天馬行空說到哪就是哪。　　

　　舉個例子，若是你是CEO，你但願本身重要的話語能被即刻理解和付諸行動嗎？是的，因此你但願的是說話便是生產力。

　　再換個場景，若是一個管理者說話沒有突出重點，而是內容或思路比較零散，你會打心底承認這個管理者嗎？下屬的執行力會強嗎？

　　因此好的說話，就是生產力，可以產生不少積極做用。

　　說話其實就是一場看不見的硝煙。大多數人在講話的過程當中，內容或思路比較零散，講到了這點又忘記了那點，說到了後面前面的話又重複說了一遍，並且還夾雜着大量的口頭禪，勢必不會帶來可觀的影響力。

　　一個顯而易見的例子是，在會議上，咱們較多的人會把話題越拉越遠，就像脫繮野馬，以至徹底脫離主題，長此以往，給人的印象就是，你說的話中，有意義的並很少，可參考度低。這無形中是在下降本身的影響力。

　　展示過人的說話水平，不只是我的魅力的展示，更是影響他人與事業發展的重要技能之一。

　　如何提升本身的說話

　　咱們可能會發現，越是高職位的人，可能說話越是精簡，字裏行間都是重點。同時他們在公司也更加具備影響力，所以他們的職業或事業發展也更加順風順水。

　　由於他們注重說話所帶來的生產力，即注重當前說話的中心以及探討問題的重點是什麼，針對明確的重點，發言流利順暢，使內容清晰有次序。

　　一種顯而易見的提升方式是，首先在內心要暗示把本身放在重要的位置上，但願本身的說話能產生生產力，那麼天然而然你就會注重本身的說話，就會在說話前進行必定的邏輯梳理，使本身的表述清晰有序。

　　因此一切的東西，都是在於你把本身的一個定位在哪。你在乎本身說話是否能夠產生生產力，那麼你就要把時刻把本身放在高的立場上，注重本身說話。

 　　

　　像CEO同樣思考

　　公司最近有這樣的培訓，遺憾的是我的因爲生病錯過了，但我能想象獲得，核心思想是：把本身的思想層次提升，再提升！

　　你想擁有管理者同樣的工做生活方式，那麼你就要像管理者同樣的思考，思考什麼？換位思考，若是換成你來作，你是怎麼規劃的，你會怎麼在執行過程當中採用哪些手段來下降失敗的可能性的，換言之，你會不會作得更好？

　　不要覺得這些很遙遠，沒有培養這樣的意識的人，是很難作到量變引發質變的。

　　咱們不少作技術的人，關注的基本都是技術層面所帶來的自我成就感，可是若是你想讓本身前進一大步，是須要在思想層面作改變了。

　　從企業的角度出發

　　我不是在畫餅，也不須要畫餅，由於咱們沒有直接的利益關係，可是對於有緣的朋友，我仍是強烈推薦的是，任何事情的出發點，都站在企業的角度去思考。

　　我明白在不少人的內心認爲，本身永遠都是打工者。拿人錢財，替人消災，作到跟工資相符的價值出來就能夠了，甚至能低於這個收入的價值都行，反正公司又不是個人。

　　短時間來講，這是對的。然而對於咱們整個職業生涯來講，這是不利的，由於這樣作只會讓咱們貶值，而不會讓咱們升值，還會固化了咱們打工人的心態。

　　站在企業的角度看問題能給咱們帶來什麼？

　　首先這樣能培養本身的更高層次的思想維度，這些思惟習慣的培養和積累，會促使咱們作事的方法論和眼光持續成長，繼而會給咱們帶來一種工做本能，成爲本身的一種優點工做思惟和技能，使得本身愈來愈值錢。

　　—我的的價值在上升，在於你的優秀習慣愈來愈多，而同時藉助於更高的思惟格局、技能和經驗，在面對各類困難時心中不慌，從容應對，做出正確的決策以及有效的執行計劃。

　　其次，沒有這樣的思想積累，是很難讓本身的思想有質的改變，繼而是很難爲咱們後續走到高職位鋪路的。

　　你想作老闆，翹着二郎腿抱着祕書，聽着工做彙報，沒問題的，那麼你有什麼能夠支持起你老闆的位置？　　

　　咱們的目標是什麼？讓本身變得更好！只有站在老闆的角度看待企業，纔是讓本身成長最快的角度。

　　因此我建議朋友們站在更高的層次去看待問題，即便咱們不能便可站在企業的角度出發，但咱們仍是能夠比現有的角度更高一點，就是這種高一點的思想，會給咱們職業生涯慢慢帶來質變的。

　　關注產品

　　只關注技術所帶來的成就感，是技術人的通病，而可能就是過於專一在技術層面，讓不少技術人忽視了產品這個層面。　

　　這個層面對於咱們技術人來講，意義何在呢？

　　體現技術價值的，是將技術轉化爲生產力的產品自己。產品實際上是各類技術解決方案的集合體，它映射的是，對通用問題的解決模式。若是你是有意在某個行業持續發展成爲領域專家的話，那這些模式的積累以及深刻，絕對會讓你身價不菲。

　　因此關注產品自己，對於技術人員的職業素質的提升是大有裨益的，也是對在職業生涯上有意成爲領域專家的重要步伐。

　　技術再好，作出來的產品不能很好的解決用戶的痛點，市場是不會買單的，這無疑是對咱們技術的一個最大否認。

　　要知道，除非你是在作着本身的專利技術，且這些技術就是公司的生產力，不然技術都是爲你的產品業務服務的。　　

　　並且在關注產品的同時，你會發現，本身做爲用戶的話，基於對技術的追求，免不了會想讓客戶在使用層面具有極致體驗模式，那麼產品的體驗這部分就會讓你的技術價值更加獲得驗證。你要給客戶極致體驗，就促使你使用websocket，使用緩存，使用高可用方案來支撐。

　　因此若是你真是一個技術追求者，那麼你必須重視你的產品自己，由於這是對技術的一個最好驗證。

　　關注需求自己

　　關注產品，其實就是關注需求自己。

　　咱們不少技術人員，在作需求的時候，可能僅僅看到需求表面的東西，接到需求就着手編寫代碼，這樣實際上是不利於本身的思惟培養的。

　　作一個需求，雖然不必定要像CEO以及產品經理那樣深入瞭解這個功能給客戶帶來什麼價值，但至少知道這個需求是不是某一類問題中的一個，這類問題的經常使用解決方案是什麼，這個需求所要傳達的信息，如何能更好的傳遞給用戶？

　　磨刀不誤砍柴工，在深刻發掘需求自己的同時，會引導咱們針對該需求衍生出一類問題的解決方案，在基於這樣的解決方案，對於再次過來相似的需求，是能夠幫助咱們避免作另外一套相似的方案來實現的。

　　說到這裏，我強烈推薦的是，不要作一個需求直譯機，咱們須要發現客戶的需求，是真需求仍是僞需求，繼而深刻發掘客戶真正須要的是什麼，抽象出來，做爲一類問題的通用解決方案。　　

　　關注客戶

　　嗯這個層面對於技術人來講，視乎有點風牛馬不相干了。

　　可是若是你注重本身的技術帶來的成就感，那爲何不重視你的技術價值最終驗證者的反饋呢？

　　產品給公司帶來收益，也承載着咱們的技術能力，產品的價值，也就是咱們技術人關注的所謂技術成就感，是要經過客戶驗證的。換言之，客戶承認了咱們的產品，咱們的技術才真正產生價值。

　　站在更高的層次看一下這個命題，當咱們關注客戶後，就會引伸出：產品在前期是如何推廣進而吸引用戶的？ 如何運營留住用戶的？在用戶的這些反饋數據之上，咱們是如何分析並優化產品的？

　　好吧，說到這裏，引伸出一堆可能在實際工做中跟開發工做不相及的觀點，然而我知道，對於有心在本身職業生涯勇攀高峯的人，這些思惟的培養，將會對你的職業生涯產生很是重要的影響。

　　君不見管理層乃至CxO，更多的關注點都是在客戶身上，關注如何提高用戶的滿意度等等，而這些的最後，纔是考慮使用什麼技術服務於這些。 

　　

　　關注客戶以及產品這兩個層面，纔會使本身的視野愈來愈開闊，也會爲本身的職業帶來更多資源。

　　提升本身的眼界

　　無論你走向哪一個崗位，例如架構師亦或技術管理乃至技術總監或者CTO/CEO，開拓的視野是職業中很是重要的一環。　　

　　當你在三樓時，你能看到可能就是眼前的垃圾堆，可是當你在三十樓時，你就能看到城市的不一樣風景。可是若是咱們不會在爬上三十樓以前，基於每一層的風景對本身的眼界進行開闊，有可能到了三十樓，你眼中仍是隻是看到這個垃圾堆。

　　培養CEO同樣的思考，不必定會給咱們帶來即刻的自我增值，可是具有了高階的眼界以後，就會幫助你在多個場合即刻脫穎而出。  

　　遺憾的是，不少技術人員，可能會更關注眼前的風景，更多的可能連頭都不擡。

　　當咱們埋頭默默耕耘的時候，也要時不時擡頭看天。

　　就像上面說的同樣，關注客戶和產品，讓本身的眼界不侷限於技術，對比本身產品在市場上的競爭力如何，其餘競品的優點以及劣勢，產品如何盈利，對手的商業模式是怎樣的，讓本身從更宏觀的角度看待這個產品的生命力。　　

　　眼界的開拓，讓咱們具有更多的選擇以及作出更好的抉擇，合理的讓技術爲咱們服務，這樣纔會在問題的解決方案上進行更好的抉擇。

　　你要知道業界內的解決方案有什麼？基於什麼狀況下選擇不一樣的解決方案？這些都須要你有這樣的眼界。

　　當你準備創業或者到了高級別的職位，你就會知道，團隊的組建，產品的運營模式，市場的推廣方式，流量的流轉控制，核心競爭力的創建，這些光景所讓人提升的眼界層面，是不一樣於技術層面所帶來的。

 　　將來方向

　　我在《技術從業者的將來》這篇文章中，分享了一些我的的職業感悟，時代發展的太快，技術更新換代的太快，除了面對着家庭以及工做外，在如此高速的科學技術發展洪流中，咱們還要保持不斷的自我進步，因此咱們技術人更加須要明確本身將來的方向是什麼。　　

　　基礎技術能力　　　　　　

　　曾幾什麼時候我認爲，走到了管理崗位，技術將不會顯得那麼重要。

　　在真正作了技術管理以後，發現技術的重要程度並無減弱。由於咱們須要作的技術決策更多了，這些決策是否會成功，就是創建在技術能力基礎之上的。　　

　　咱們須要紮實的基本功，而這個基本功並不只僅是熟知面向對象編程便可，還須要計算機原理，網絡，部署，算法，設計模式等等。

　　並且在雲生態發展迅速的時代，愈來愈多的企業如今或者將來都會上雲，基於雲上的技術能力，將也是當今時代的技術人應該掌握的基礎技術。

　　當咱們決定在技術路線繼續走下去時，咱們就不能忽視這些基礎能力的積累。

　　抽象能力

　　好的設計就是基於抽象能力抽象出本質，讓抽象知足更多通用的場景。

　　這裏舉個例子，咱們使用太高德地圖App都知道，裏面是能夠查詢車輛的具體到站信息的。好比我天天到公司有兩條路線的公交A,B可選，某天我坐了A，可是我到站下車時想知道B車到了哪裏。

　　因而做爲產品就會很容提出這樣的需求：在地圖中我要知道坐A車到站時，B車到了哪裏。

　　做爲開發者，很容易想到給車作一個標記功能，這樣就很容易對比車輛的位置，因而乎就往下作了。其實咱們往深點想，若是期間用戶退出了地圖再從新進來的時候，咱們如何找到」有狀態的「這兩輛車？因而乎又想到能夠經過我的的帳號信息進行關聯，標記的車輛能夠綁定到我的的相關信息裏面。這裏面又帶來了問題，這樣的話就會要求客戶強制進行註冊，而咱們目前的不少地圖是沒有要求用戶註冊才能使用。

　　當咱們作到這一步的時候，就體現出咱們的抽象能力是不夠的，可能就會出現我上面說的需求直譯機，而這樣是對咱們的職業生涯沒有任何幫助的。

　　產品直接的需求是能對比功能，試想若是咱們地圖上提供對車輛的一些基本信息例如車牌號，再借助GPS的能力，這樣是否就能具有區分Ａ和Ｂ車輛的能力了呢？並且基於這樣的能力，咱們還能拓展其餘的能力，譬若有兩輛車靠近的時候，經過公交的基本信息告訴好友本身在哪輛車上。

　　你的抽象程度越高，複用能力就越寬。

　　Devops　　　　　　　

　　試想一下，當咱們須要給公司開發一款新產品，從需求到這款產品最終上線到客戶手裏，咱們軟件開發者具體作了些什麼？

　　我相信你們都會清晰地知道，軟件最終能到達用戶的手中，有兩個層面的事情是不可或缺的：

1. 應用服務開發層面(功能性需求)
2. 部署上線落地層面(非功能性需求) 

　　實際的工做場景中，咱們很大部分的人都只是專一在這兩個層面中某一塊，鑑於工做的內容性質， 運維工程師和開發工程師有着徹底不一樣的思惟邏輯。

　　因此在這種狀況下，Dev和Ops之間是割裂的狀態。

　　那麼Devops能給咱們帶來什麼？

　　咱們先看一下什麼是DevOps？

　　傳統的軟件開發流程是這樣的

 　　而DevOps是這樣的

 　　

　　DevOps 是字面上 Dev 開發 / Ops 運維二者組合，是一種重視"軟件開發人員(Dev)"和"IT 運維技術人員(Ops)"之間溝通合做的文化、運動或慣例，實際上它是一種文化 + 願景 + 方法的統稱。

　　DevOps 強調的是高效組織團隊（文化）之間如何經過自動化的工具協做和溝通（方法）來完成軟件的生命週期管理，從而更快、更頻繁地交付更穩定的軟件（願景）　　

　　咱們爲何須要DevOps？　　

　　當咱們面對快速發展的互聯網行業，稍縱即逝的商機，業務須要快速迭代，不斷試錯，更快地交付產品和服務是咱們全部公司賴以生存的條件，也是咱們全部公司的願景。

　　所以，在這樣的願景下，用科學的方法學來指導企業經過快速的對應，迅速地部署，實現了一流的穩定性/可靠性/安全性的系統服務，讓企業擁有持續交付的能力。　　

　　在這裏，跨職能的團隊的合做並不只僅是爲了實現用戶要求的功能，他們保障的是：快速的對應在整個價值流中不會帶來對內或者對外的混亂和困擾。

　　DevOps打破原來的開發和運維之間的界限，將分離的兩個流程融合到了應用的研發過程當中。經過自動化"軟件交付"和"架構變動"的流程，來使得構建、測試、發佈軟件可以更加地快捷、頻繁和可靠。這些改變的目的是爲了支持和適應應用快速、安全、可持續和頻繁的版本發佈。

　　咱們如何實踐DevOps?　　　　　　

　　文化

　　首先DevOps是一種文化的背景下，文化的推行，確定要涉及到思惟的轉變。

　　DevOps並非簡單的在組織機構上把開發團隊和運維團隊合併起來，咱們上面提到它包含着思想，因此在思想層面上，須要企業文化和思想觀念的變革。

　　那麼想要將DevOps真正落地，第一點就是思想改革。不只是運維的思想要變，開發也要變。員工要變，領導更要變。

　　DevOps並不只僅是組織架構變革，更是企業文化和思想觀念的變革。若是不能改變觀念，即便將員工放在一塊兒，也不會產生火花。

　　方法

　　想要充分落地DevOps，離不開工程和平臺的支持。

　　在更快的交付願景下，映射出來的是在整個產品交付環節的效率提高的，因此咱們將在效率工程上進行效率提高。

• 開發效率

　　在這裏引入了敏捷開發，敏捷開發大幅提升了開發團隊的工做效率，讓開發專一於每一個迭代內需交付的最小閉環功能，讓版本的更新速度變得更快。

• 測試效率

　　當開發團隊的效率提高後，不可避免的需同步提高測試效率。而自動化測試流程將會在DevOps設置的上下文中起做用，並且這還將須要持續測試（CT）。

　　若是沒有持續測試，也就不能對持續集成進行及時驗證，天然就沒法作到有效的持續交付。

　　自動化測試是一項艱鉅的技術活動，若是沒有有效實施，它就有能力破壞整體的DevOps策略。

　　雖然在持續集成中要儘量的使用自動化測試，可是難以免有些狀況是自動化測試難以覆蓋。因此手工測試仍是必不可少的，可是在測試團隊的持續改進中必須將手工測試儘量的優化，不能讓其成爲自動化測試的瓶頸。

• 部署效率

　　減小部署層面的重複性和出錯可能性，自動化手段是必不可少的，因此咱們須要提供基礎設施平臺的支撐，其中包括咱們耳熟能詳的術語：CICD，觀測面板，容器化（虛擬化），編排工具，服務網格等，其中CICD是DevOps的基礎核心，沒有CICD自動化的工具和流程，DevOps是沒有意義的。

　　在咱們上面作了這些效率工程以後，咱們的將會大大縮短產品上市以及換代的時間，這就是咱們DevOps的願景。

 

　　在有了基礎支撐以後，很重要的一點是， 咱們的工做是有交互的。

　　在DevOps的流程下，運維人員會在項目開發期間就介入到開發過程當中，瞭解開發人員使用的系統架構和技術路線，從而制定適當的運維方案來支撐自動化和研發工做。

　　而開發人員也會在運維的初期參與到系統部署中，瞭解部署架構以及基礎設施平臺是如何運轉的，在資源管理、監控、網絡、安全等方面提供系統部署的優化建議。　　

　　在這期間，自動化測試工程師和開發工程師一塊兒基於場景以建立測試腳本，並在產品經理的幫助下擴大其測試範圍，而且在基礎設施平臺集成這些代碼和腳本做爲持續測試的基礎。

　　後記

　　在這不容易的過去一年中，若是你的2020年是平安美好的，那咱們應該感謝本身以及家人和朋友，若是你的2020沒有那麼美好，那麼讓咱們忘掉這段記憶，在2021年從新啓航。

　　其實無論在哪一個行業，若是你許諾了給本身或者家人一個美好的將來，那麼咱們都將需好好規劃這個將來，而這個將來，我相信，並不會輕易就達成，因此咱們在這以前必定要先自醒，清晰本身的方向，不能瞭解本身真實的情況，就不會找到有效的辦法去改變現狀。

　　讓咱們繼續加油！