碼農多年後的個人總結(二)
這裡有個目錄
- 碼農多年後的個人總結(二)
-
- 聲明
- 多喝熱水！（代碼比不過大神，咱們比養生！！！）
- 工欲善其事必先利其器
- 學會優雅地提問題
- 磨刀不誤砍柴工
- 遇到問題先不慌！！！！
- 分治法（問題多且雜亂，分而治之）
- 勿以浮沙築高台 （打好基礎很重要）
-
- 架構很舒服，但是如沼澤，越陷越深
- 做工作中的消費者，學習上的生産者
- 不要糾結語言、工具，你隻是使用者不是創造者（少些無用的争論）
- 人狠話不多，先實作再說（功能實作後才讨論優化）
- 紙上得來終覺淺，絕知此事要躬行！
- 代碼是越少越好
- 覺得自己能力不足是好事，無需焦慮
- 解決問題後寫部落格、寫總結文檔記錄！
- 碼農不止眼前的代碼，還有工作的軟技能
- 迷茫？敢問路在何方？那做有積累的事！
- 後記
聲明
本文不是技術文，是個人的從業總結，且對象是指大部分人，不是針對各位牛人，亦不是指個例，如有過錯，還請指出，作者會馬上發表官方道歉聲明，9行道歉，100行廣告那種！（開個玩笑，哈哈）
文章各要點簡潔，相信各位看官不會很累。（我寫的很慢，是以你們看的也就不會很快，就不會很累）
以下就是幹貨要點：
多喝熱水！（代碼比不過大神，咱們比養生！！！）
這真不是直男發言，健康第一，多喝水,多上廁所，多走動，減少各種頸椎病的同時,還能助力新陳代謝,有條件的還能加2粒枸杞,
保護眼睛和我們的頭發,步入碼農不得已,保溫杯裡放枸杞。
最主要的是，能幫你在卡Bug的時候冷靜下來。
很多時候沒有解決問題的思路，不妨上個廁所，興許它就有了。
工欲善其事必先利其器
這句話很多人都知道，但是不會運用，無論是從事哪門程式設計語言，哪個作業系統，都有很好用的工具。
很多人一開始用什麼軟體，到最後也是用什麼軟體，不知不覺限制了自己。
其實，多花點時間尋找利器（工具）是真的能事半功倍的。
在此推薦35款Windows必裝神器，絕不許你不知道！
希望大家不局限于推薦，自己動手搜尋下自己所在領域的神器！！
學會優雅地提問題
作為技術路上的前行者,有問題不會是再正常不過的現象,如何提出問題也是一門大智慧，
這裡小編在《為什麼你的問題群裡沒人回答？這就是原因！》一文中詳細講述。
簡易概括就是，虛心禮貌，問題簡潔，寫文總結。
提出一個好問題，比回答一個問題更重要，不要害怕提出“傻問題”，提出啥問題隻傻5分鐘，不提問題傻一輩子，事實上沒有蠢問題，提出問題的本身代表着求知，請保持提問，永遠保持提問！！！
磨刀不誤砍柴工
這也是個家喻戶曉的詞，但是真的很少人能做到，初級程式員往往遇到問題就開始敲代碼，等出錯了再說。
殊不知有磨刀的過程，遇到問題，需要先思考，如果問題過于複雜，就畫圖！畫圖！
真的要畫圖，不要說沒習慣，誰也不是生下來就畫圖再幹活的，你考試考數學不用草稿試試！！
UML圖、流程圖、思維導圖等等，都有助于提升你的效率。
這裡給大家推薦線上畫圖
遇到問題先不慌！！！！
你遇到的問題80%都有人遇到過，你慌啥。
遇到bug時候，先安慰自己，讓自己有個好情緒後再處理問題，不可帶着煩躁的情緒去處理，
那隻會越卡越久，越卡越煩。成熟的程式員往往是遇到問題，冷靜（不慌），調試、日志、一步步排查直至解決問題。
是以遇事，先安慰自己,不煩躁，穩中求快。
當你慌了，簡單的問題也變複雜了。
分治法（問題多且雜亂，分而治之）
在計算機科學中，分治法是一種很重要的算法。字面上的解釋是“分而治之”，就是把一個複雜的問題分成兩個或更多的相同或相似的子問題，再把子問題分成更小的子問題……直到最後子問題可以簡單的直接求解，原問題的解即子問題的解的合并。
通俗來說，就是如果問題實在過于複雜，可以嘗試将其像分蛋糕一樣分成多個小步驟，一步一步來，這樣當所有小步驟完成，這個問題也就解決了。
例如，當你要完成一個學生管理系統，看着很龐大，不好下手，可以将它劃分前端和後端，然後再劃分功能子產品，再劃分子功能子產品，再根據子子產品劃分完成時間，一天一個小子產品，這樣看着是不是就比較簡單了呢？
分而治之，逐一攻破
勿以浮沙築高台 （打好基礎很重要）
架構很舒服，但是如沼澤，越陷越深
不知道在座的有木有自學程式設計的或者是報教育訓練班的，幾個月瘋狂密集的學習，俨然成為了個“大神”。
但事實上呢？ 外表看似強大的情況下，一面試就懵，一問就是不會，這就是基礎不牢。
使用架構雖然可以快速讓産品成型，但是想路走的遠，資料結構、設計模式、編譯原理、UML諸如此類的基礎課程還是要鑽研的。
飯是一口一口吃的，路是一步一步走的，沒有捷徑。
宛如大樓的地基一樣，越高，地基越深， 基礎決定了你的上限。
架構是會随着時代改變更新的，但是原理不會改變，莫急莫燥。
從C語言、資料結構和算法、計算機組成原理、計算機網絡等 計算機基礎一步步學，戒躁戒躁。
學習并非一日之功，冰凍三尺也非一日之寒，做好終身學習的準備很重要。
做工作中的消費者，學習上的生産者
不知道大家有木有一種“飄”的感覺，即看着好像會很多，但實際又都不值得一提，感覺自己很“飄”，
正如許多人經常調侃自己是調包俠，隻會調用各種包，離開包了啥也不會，也正如上文說的架構很舒服，但是如沼澤，越陷越深。
對此，個人建議，做工作中的消費者，學習上的生産者。
工作之中快速完成工作為第一要素，造輪子時間成本高還不穩，調包也是無可厚非，但是學習過程中，我們需要将我們常調用的包嘗試自己造出來。
推薦閱讀《手寫IOC容器-探究IOC的本質原理》
不要糾結語言、工具，你隻是使用者不是創造者（少些無用的争論）
在這裡插入圖檔描述
C#和Java哪個更好？PHP是最好的語言？大家總是“讨論”得熱火朝天。
事實上，不同的語言在不同的場景下各有應用，在國内.NET生态确實不如Java,但是在歐美呢？
語言和工具隻是為業務場景服務的，适合業務就行，讨論好壞沒有意義，真正的大佬隻會忙着學習，
經常在各個技術群看見大家争論，有這功夫，多看幾篇技術文章不香多了？
黑貓白貓，能抓到老鼠就行
人狠話不多，先實作再說（功能實作後才讨論優化）
好的代碼往往不是一次寫出來的，是重構出來的。
在遇到新功能的時候，我們往往會想一次性做到最好，但是現實是很殘酷的，一次做到完美是不現實的。
先以最快的速度實作功能先,實作完後你就不會帶着焦慮去尋找新的解決方案了。
我們常常隻是需要一個茅房，卻設計成了高樓大廈，随着項目的進行，漸行漸遠，早已不是最初想要的模樣，是以，先以最直接的方式實作功能後再優化。
少即是多，快比好更重要
我們在項目開發過程中，也常常會想加“花裡胡哨”，也可以說是所謂“高大上”的功能，然而，這常常會導緻項目臃腫不堪。
這好比在馬的上面加上了汽車的座椅。看着很高大上，但是實際未必實用。我們可以先考慮實作核心功能，優化核心功能。
哪怕它看起來很“low”，但是它能用且輕便。
紙上得來終覺淺，絕知此事要躬行！
程式設計這個事上，實踐大于理論
曾經有個朋友問我個問題，那麼多代碼語句你是怎麼都記的？都背下來嗎？
我仔細想了想、好像都不用記，無他，唯手熟爾。
敲多了自然就記得了，我記得我一開始32條語句都不會，就是一直敲，一直敲，慢慢地就熟悉了。
代碼是越少越好
許多人認為代碼寫的越多的越牛逼，事實上不是的，牛逼的大佬代碼往往很簡潔清晰。
你寫下的每一行代碼都是負擔，每寫多一行，意味着維護成本和出Bug的風險在增加，
盡量将你的代碼寫的簡短易懂，讓人一看就明了。
關于代碼優化，這裡推薦《代碼整潔之道》
你每解決一個Bug，就是在制造下一個Bug
覺得自己能力不足是好事，無需焦慮
很多人覺得自己能力太“菜”，對自己的能力沒信心，但事實上，意識到自己能力菜是一件好事。
這意味着你在成長，你看到了很多沒掌握知識才會覺得自己能力不足，那些從事簡單、無關緊要的工作的人沒有理由懷疑自己。
這時代最不缺的就是焦慮，沒必要為自己徒增煩惱了。很多不懂？學就是了！Who怕Who!
你知道的越多，不知道的就越多。
解決問題後寫部落格、寫總結文檔記錄！
如果你解決了問題不加以記錄，下次再次遇到或者他人問起，你依舊是某度某歌去搜尋，且很有可能找不到當初的文檔。耗時耗力，還很煩躁。
你可以使用印象筆記或各種部落格網站記錄你的所思所想，注意以下要點：
- 不要因菜而不寫，切記，這是寫給自己，不是寫給别人看的！不是打擊你，大多數人初始寫的根本沒人看，這就是杞人憂天。
- 不要因小而不寫，小bug，小知識點一樣要記，矮凳子一樣絆死人，多少耗時一星期解決的bug，隻因為一個空格，一個分号····
- 不要因為短而不寫，内容沒幾句？沒啥好寫的？短小不說明内容不重要，内容很長反而成本高沒人看。
- 不要因為爛大街而不記，好多内容搜一下就出來了，像int轉string,資料庫連接配接字元串，語言用法一搜不就有了嗎？不，搜尋一樣要成本，自己記錄筆記，才是解決問題最快的方案。
寫記錄的最大收益者永遠是記錄者，這裡的收益包括知名度，寫作叙述能力，總結能力，資源内容，甚至經濟收入等
不知道如何寫？半小時憋兩字？你可以試試這樣。
- 初始将你要學的内容使用思維導讀構成成體系，這也能給予自己目标，不會輕易半途而廢。
- 将你的筆記或部落格初寫一遍，将所有你學到的内容都寫出來，這個過程不需要進行深度思考，不需要語句通順，隻需編寫。
- 重新閱讀，将語句捋通順，将内容抽絲剝繭的優化一遍，用盡可能簡潔地語言去叙述它，将所學知識進行壓縮，用盡可能通俗的話描述它。
- 進行下一篇的編寫，如此反複，形成積累
- 将所編寫的記錄構成體系，再腦海中形成目錄，便于查詢！
輸出式的學習大于輸入型的學習，一旦開始，你自會獲益良多，不信你試試？
碼農不止眼前的代碼，還有工作的軟技能
不要隻沉浸在代碼裡，碼農還需要溝通！溝通！PPT！PPT！ 對象！對象！（注：此處對象僅代表女朋友）
溝通、找對象、交朋友、管理等技能重要性不比代碼低。大多時候，溝通其實比寫代碼能力重要的多。
哪怕你是選擇做一個純粹的技術人員、跟上司、設計人員、産品經理等溝通也是非常必要的一項技能。
切不要隻沉浸在代碼裡無法自拔，認為代碼行天下，畢竟生活不止代碼，還有數理化。
此處僅舉例幾個軟技能，實際遠不止如此，切莫隻卡在代碼上。
程式員35歲的坎你不是不知道，多學習些其他技能。技多不壓身嘛。
這裡推薦一本書 《軟技能 代碼外的生存指南》
迷茫？敢問路在何方？那做有積累的事！
不知道是不是很多朋友像我剛入行一樣，不知道敲代碼适不适合自己，對未來感覺到特别迷茫。
對此，我個人感悟是，做有積累的事！做能讓明天的自己跟今天的自己不一樣的事，可以是學習，寫部落格，記筆記，
也可以是培養興趣愛好，如唱歌、跳舞、繪畫等。隻要能讓自己成長，能有所積累的事，你都可以做。
隻要你堅信，做這些事，未來自己一定跟現在不同。
也許我們此生不一定會走到最适合自己的高速軌道上，但是我們正走在勻速前進的平穩軌道上。
後記
本人不是大佬，隻是道路先行者，在落河後，向後來的人大喊一聲，這裡有坑，不要過來啊！
縱然如此，依舊有人重複着落河，重複着呐喊······
個人部落格網站 Blog
技術交流Q群： 1012481075 群内有各種流行書籍資料
文章後續會在公衆号更新，微信搜尋 OneByOneDotNet 即可關注。
你的一分鼓勵，我的十分動力，點贊免費，感恩回饋。喜歡就點贊評論吧，輕按兩下66~