若是按照以往的慣例,我會在標題前面加個詞簡單描述一下。但在寫這篇文章時,我想了好久,都沒想出什麼詞能夠知足「簡單的描述一下」。因此就不寫了。程序員
仍是從工做先談起,由於工做在我看來挺重要的。編程
今年年中的時候去了另外一條產品線,作流處理的。想去的緣由是由於好奇心害死貓——老是聽到他們在聊一些感受很酷很好玩的東西,有時還聽的一臉懵逼,產生了許多疑惑。架構
去了之後,部分問題在實戰和平常的學習中找到了答案。但有些答案引發了我更多的疑問,直到觸碰到了我盲區,驅使我開始新一輪的學習。這就是下半年我技術博客更新頻率下降的緣由——我在花時間輸入,而不是輸出。函數式編程
我在新的產品線中完成業務的同時也把一些自動化設施引入了進去。自動化測試work了,但覆蓋率不高,由於需求方但願咱們能快點出個「樣品」,基本能用就行。函數
在明確肯定這種「儘快出,基本能用就行」的狀況下。天然而然只能加快步伐跟上——畢竟咱們得先有(錢),再變得更好(的質量)。但這筆欠下的技術債務,開發們早晚是要還的,並且越早還越好。學習
若是技術債務可以還上,這種狀況仍是能夠接受的。讓人感到心累的更可能是一些「長期鬥爭」——需求方平常以爲這個很簡單兩三天就寫出來了,而業務方思考的不只僅是讓這個功能work起來。顯然,這裏是有矛盾的。在這裏,能夠引用《架構整潔之道》的內容來展開。測試
對於每一個軟件系統,咱們均可以經過行爲和架構兩個維度來體現它的實際價值 。spa
行爲價值是最直觀的價值緯度——開發的工做就是讓機器按照某種指定方式運轉,給系統的使用者創造或者提升利潤 。 開發們爲了達到這個目的,每每須要幫助系統使用者編寫一個對系統功能的定義,也就是需求文檔 。 而後,開發們再把需求文檔轉化爲實際的代碼 。插件
固然,當機器出現異常行爲時,程序員要負責調試,解決這些問題 。架構設計
大多數開發就是這麼想的——他們僅僅看到了軟件這一層面的價值。顯然這是有問題的。
軟件系統的第二個價值維度,就體如今軟件這個英文單詞上 :software
。 的意思是「產品」,而soft
的意思,不言而喻,是指軟件的靈活性。
軟件系統必須保持靈活 。軟件發明的目的,就是讓咱們能夠以一種靈活的方式 來改變機器的工做行爲 。對機器上那些很難改變的工做行爲,咱們一般稱之爲硬件( hardware )。
爲了達到軟件的原本目的,軟件系統必須夠 「軟」一一也就是說,軟件應該容易被修改。當需求方改變需求的時候,隨之所需的軟件變動必須能夠簡單而方便地實現。變動實施的難度應該和變動的範疇( scope )成等比關係,而與變動的具體形狀 ( shape )無關 。
需求變動的範疇與形狀,是決定對應軟件變動實施成本高低的關鍵。這就是爲 什麼有的代碼變動的成本與其實現的功能改變不成比例。這也是爲何不少公司第二年的研發成本比第一年的高不少,第三年又比第二年更高 。
從系統相關方 ( Stakeholder )的角度來看,他們所提出的一系列的變動 需求的範疇都是相似的,所以成本也應該是固定的 。可是從研發者角度來看,系統用戶持續不斷的變動需求就像是要求他們不停地用一堆不一樣形狀的拼圖塊,拼成一個新的形狀。整個拼圖的過程愈來愈困難 ,由於現有系統的形狀永遠和需求的形狀不一致 。
咱們在這裏使用了「形狀」這個詞,這可能不是該詞的標準用法,可是其寓意應該很明確。畢竟,軟件工程師們常常會以爲本身的工做就是把方螺絲擰到圓螺絲孔裏面 。
問題的實際根源固然就是系統的架構設計。若是系統的架構設計偏向某種特定的「形狀」,那麼新的變動就會愈來愈難以實施 。因此,好的系統架構設計應該儘量作到與「形狀」無關 。
那麼,到底是系統行爲更重要,仍是系統架構的靈活性更重要?哪一個價值更大?系統正常工做更重要,仍是系統易於修改更重要?
若是這個問題由業務部門來回答,他們一般認爲系統正常工做很重要 。開發們經常也就跟隨採起了這種態度。可是這種態度是錯誤的。下面我就用簡單的邏輯推導來證實這個態度的錯誤性。
固然,上面的邏輯論斷可能不足以說服你們,畢竟理論上沒有什麼程序是不能修改的。可是,現實中有一些系統確實沒法更改,由於其變動實施的成本會遠遠超過變動帶來的價值 。你在實際工做中必定遇到過不少這樣的例子 。
若是你問業務部門,是否想要可以變動需求,他們的回答通常是確定的,並且他們會增長一句:完成如今的功能比實現將來的靈活度更重要。但諷刺的是,若是過後業務部門提出了一項需求,而你的預估工做量大大超出他們的預期,這幫傢伙一般會對你聽任系統混論到沒法變動的狀態而勃然大怒。
另一點是我在今年招人時變得更佳嚴苛了。我認爲,一個好的程序員能不能頂上兩個普通程序員很差說。可是一個差的程序員必定會搭上兩個好的程序員的精力。背後的心酸事蹟就不說了。若是代碼規模再上去,這個比例還會被放大。不過今年仍是從V2上招到一個聰慧皮實的小夥子,真是太好了!
關於技術上細枝末節的就很少說了。就說一點吧,今年我成功的把Kotlin引入了產品線,能讓產品線的開發們更愉快的寫代碼,畢竟Java仍是偏verbose的。同時我也感覺到了函數式編程的精妙之處,並對編譯器產生了興趣。最近還在用Go寫一些小玩意兒,不得不說學過Kotlin之後切過去仍是挺舒服的。
今年學的東西還挺聚焦的,就兩塊——錢和專業技能。
「錢」這個字說的很俗,不過很實在,由於我就是爲錢纔去學的。不過不管從學的過程仍是結果來看,既知足了我目的,也知足了個人一些好奇心。總的來講,挺好的。
「錢」一個字,也說的很泛。實際上,我看的是一些宏觀經濟和理財相關的東西。並結合實際狀況,運用到了本身的理財中。今年基金定投部分的理財收益率爲6.9%,全部資產的理財收益爲6%個點。
但今年以來滬深漲了37.95%,簡直是天差地別。這有三個緣由:
關於第三點。避免這種問題之後再發生的方法就是多買幾隻雞分散風險了(分散基金經理腦抽的風險)。有人可能會說指數型基金纔是最好的balabala。但事實並不是如此,我國的股市並不成熟,散戶較多(較米國)。就目前來看,主動型基金是能跑贏指數型基金的。
在11月的時候,我趁着結帳行情買入了一些股票。與此同時,我開始研究如何瞭解一家公司。大體通俗的講幾個點:
這樣就能挑選出一個好公司了嗎?或許吧。可是好公司也有三種好公司,即:
這看起來彷佛是個不可能三角。不過這得取決於咱們屁股坐在哪裏——若是咱們是股民,咱們固然要找對投資人好的(好比多分成,多回購);若是咱們是員工,那麼就得找對員工好的公司(好比錢多,給你平臺成長)。
瞭解這些,對我職業生涯的規劃是有必定幫助的。
專業技能,今年的趨勢是逐漸往下沉澱——固然應用層的知識得知足現狀。往下沉澱一部分是興趣使然,一部分也是業務中有用到相關的知識。這樣天然是好的,有動力,有反饋。
今年看的書不算多,就10多本。有兩本對我影響比較大,一本是Robert C.Matrin的《架構整潔之道》,若是說平常的寫代碼和學習是在練基本功,那麼看完這本書感受就像被打通了任督二脈。
還有一本就是吳軍的《格局》,書中的部份內容解決了我長期以往的疑惑,還有幾個點我甚至歷來都沒有想到過,收穫頗豐。
最後貼個年度概覽吧。
極客時間:
獲得:
話說回來,在翻獲得和極客時間的年度總結時,仍是讓我有點小震驚的
說好的不熬夜呢?
先說一下健身的事,去年立的flag沒有實現。體脂目前是16個點左右,體重快80了。緣由是最近幾個月作俯臥撐把上半身作壯了..
至於跑步,曾在狀態好的時候想試一下半馬。但跑多了膝蓋有點不適,因此就及時停了。
今年跑過的最長距離是1.3w米,極限仍是1.5w米吧。加上全部的運動項來估計(由於Keep的年度報告還沒出來),平均每週的運動時間應該有300分鐘以上。
做爲一個對旅行無感的人,今年卻走過了4個城市——看着一些朋友結婚。朋友圈裏的同窗們也慢慢到告終婚育子的階段。而我也找到了能一塊兒過日子的對象,大概這就是緣分吧。按照我本來想法,我想浪到30歲的。
望着可期的將來,我些許穩重了。
工做上,當務之急是先解決對幾個開源組件瞭解不夠深的問題(這使咱們在踩坑時要花很長的時間來脫坑),以及自動化測試的落地,在此同時整個架構也鬆耦了。再對其餘場景下須要的組件、邏輯以插件的形式靈活的加到項目中。團隊方面的在這裏不方便細說,就跳過了。
關於專業的學習,我仍是但願保持如今的節奏——即對業務中使用到的技術進行挖掘,並尋找機會向下沉澱。其餘方面,我會繼續瞭解「錢」相關的一些事。另外,我還想看一些數學通識相關的書籍。
健身相關的,仍是但願本身可以把體脂降下去,到14個點。早日練成半馬。其餘的保持現狀就行。
活在2019年裏的時候,總有一種時間過得時快時慢的感受,但它已通過去了。活在今天看以往,那些事彷彿就一剎那。只有看看之前的照片,看看之前的博客,看看身邊的人,才知道本身是這麼活過來的。