編程究竟是怎麼一回事情

工作也快四年了，算上大學的時間，和代碼打交道也快7年了。其實沒有好好的去想過我正在做的這件事情。一開始只是我的一腔熱情，我覺得寫 code非常的酷，我創造了一些東西，其實到工作後才發現，你做的是一個螺絲釘，至少在大公司是這樣，你是和你的團隊在一起創造，或者維護一個東西。它不完全是你的個人主義式的創造，會有很多的限制，以及考量。除非你做到了非常高的位置，或者在小公司，你完全可以自己決定怎麼去做這個東西。

我突然回想起來再大三暑期學校實習的時候，實踐課的老師說，大家出去後更多的是去做開發，是工程類的工作，完成工程開發中的一部分。一些細節，深入的的東西其實不會想太多，比如一個類庫的底層是怎麼實現的。我就算不知道原理，我也仍然可以完成，實現我的工作，實現想要的功能。這也是你身為一個工程師的基本素養和能力，就是解決當下的問題。深入的研究和創造那是後面的事情，或者說是你自己的事情。

工程的角度

從工程的角度來說，或者從程序員的這個崗位，公司給你薪水，要求你給出的回報。首先是解決當前的問題。原理什麼的，可以無需關心。

對於普通的程序員來說編程是搭積木完全不為過，說句不好聽的是你就是搬磚的，利用已經有的磚頭，水泥，鋼筋。怎麼拼湊，搭建起一個穩固的高樓大廈。

普遍意義上的語言，框架，不外乎是一些知識性的東西，你看了文檔，學習了就會使用。是工具型的東西，對一個有幾年編程經驗的人來說，學習一門新的編程語言，或者框架，不過是幾個小時或者幾天的事情。

所以知識本身也不重要，重要的是你去搜尋知識，分析問題，整理方案的能力。

所以要善用google，去搜尋你需要的資料，分析，整理，然後成為你的解決方案，代碼。

寫代碼的本質

從寫代碼本身來說，或者怎麼樣去寫好代碼，寫代碼的目的一部分是為瞭解決工程問題，一部分是本身的研究，提升，內化，或者說內功。

寫代碼究竟算不算一門藝術？好的代碼，好的思想經久不衰，比如前端領域正在顛覆的，其實在別的領域已經有很成熟的方案，和思想了(比如桌面的軟體開發)。

再比如每次面試都會問題的排序演算法，各種設計模式等等，也有數年的歷史了吧。仍然散發魅力。好的東西，總是能經歷時間的考驗。

當我們寫代碼的時候是在幹什麼？

是你用你的邏輯思維去解決一個問題。所以一定要先想好怎麼解決，然後才開始寫。

在開始一個項目的時候，可以先去畫草圖，寫文檔，如果文檔寫得非常清晰，方案足夠詳細，那麼去實現的時候也不會有太大的問題。代碼只是描述思維過程的工具。代碼是招式，是途徑，思維的過程纔是靈魂。

何謂框架，設計，架構?

框架是一種抽象思維，抽離出這個問題最本質，最核心的部分。所謂的設計，也就是抽象的過程。一個好的設計，往往是比較穩定的，能滿足擴展性的。

架構這是一個比較大的話題，會專門寫一篇文章來討論。我們說量變引起質變，萬丈高樓平地起，一個穩固的大項目，都需要一個良好地基，與周邊生態。當你在做這部分工作時，你其實已經不完全是在寫代碼了，你是藍圖的設計者。

搞開發比演算法簡單?

開發其實是一個工程問題，要考慮的問題非常多。演算法是一個數學問題 , 側重點是不同的。可以理解為一個是廣度，一個是深度。

開發你需要從代碼的可讀性，擴展性，語言生態的特定問題，軟體工程，開發效率，甚至相關領域的業務知識。是一個綜合問題，並不比演算法簡單。

編程世界的迷惑

在編程的世界我認為有很多迷惑人的東西，讓人本末倒置。在無盡的業務當中，我們就慢慢的迷失了自己，所以你要明白，你喜歡的是什麼，是寫好代碼這件事，還是解決問題的能力，還是你所解決的問題，業務，工程。一開始踏入heloworld的大們，我想都是因為熱愛代碼本身吧，為他神奇的魔力，可以做到那麼那麼厲害的事情。可是圍繞代碼這件事情，也會有很多的分支，就像是各式各樣的武功祕籍，讓人眼花繚亂。怡情可以，較真就沒必要了。

編碼工具

我曾經花費了大量的時間在編輯器的配置，先是notepad++ editplus eclipus idea subline text vim emacs 都折騰了一遍，什麼字型大小，顏色，快捷鍵，插件。等等。被折磨的死去活來後，感謝vscode的出現，讓我停止了魔怔，我好想突然蘇醒，倒騰了那麼多也沒什麼卵用，代碼寫得更好了麼。寫得更快了嗎，似乎也沒有。反倒耗費了大把的時間和心力。或許是那段時間對編程的真心熱愛，讓我變得極客，hhkb 也買了。然而並沒怎麼用，大屏幕也埋了，但也用不習慣。簡單，長久，通用或許纔是最好的東西，越久過時，收益來看是更划算的。

我並不是說編碼工具不重要，但我不認為那是最重要的一件事情，它是錦上添花，內功還是得靠你自己。

代碼風格

代碼風格，縮進，字型大小等等，我看見有的人會折騰很久，如果縮進不對，他就寫不了代碼。其實吧，按照大多數的那一套規範就可以了，一般都有成熟的工具，和默認的配置，

在團隊中也是，重點不是以什麼樣的風格，重點是有一個統一的規範。如果你真的有閑暇的時間去折騰，那也無可厚非。只是這也仍然是錦上添花的東西。沒有，並不會真的影響你的多少代碼質量，以及功能能不能完成。

框架類庫

一個火熱的技術就像是一個信仰，一個宗教。各自在招攬者它的信徒，它的價值隨著它的信徒增多而增多，隨著信徒的減少而減少。選擇框架，選擇技術棧，就像是在選則前途，選則命運。選對了，至少短時間內，熾手可熱，選錯了，代表著淘汰的邊緣。所以我們該思考的事情是什麼，技術總會一代，一代的被革命。沒有所謂的永遠的鐵飯碗。在這快速淘汰的洪流中，怎麼讓自己被淘汰得慢一點。你的學習能力，你學習的效率，你舉一反三的能力。假設同樣的時間，你學到的東西更深入，更持久，那麼你的能力就越強，你可以遷移的東西就越多，你學習的速度也就越快

別盲從於新技術，之前使用一個開源庫sharp，GitHub上有9000多星，以為靠譜了，然而使用的過程中才發現，有非常多的問題。我們相信了星數。卻忽略了很多別的東西，比如實際的使用效果，社區反饋等等。比如express和koa， express的使用人羣更多，社區更健壯。koa是很新，很時髦，然而很多問題就得你自己的去解決。新奇，和它能否解決實際的問題是兩碼事

盲目的設計

人的大腦只能同時處理好這1件事情，設計的時候，就不要考慮實現，實現的時候就不要考慮設計。

也不要去過早的優化，那會耗費大量的時間，甚至讓你忘記了你最重要的事情。在什麼時候去做優化？在即將碰到，和已經碰到問題的時候，做優化的事情會比較有目的性，也容易得到支持，從而把優化做好。因為老闆會更容易看到它的意義。我覺得這叫順其自然。因為在量級沒到那個程度的時候，其實隨便怎麼寫都可以。但也不是說完全不考慮設計與優化，架構師普通程序員的區別是，他知道未來會怎麼發展，也知道目前急需要解決的問題，在2者之間去做一個平衡，會留一些鉤子，或者做一些簡單的優化，或者為今後過渡打下的基礎，不至於今後完全做不了，或者成本太高。只是說你要知道當下最重要的事情是解決當下的問題，而不是在別的事情上面

思考與啟發

其實從寫代碼的過程讓我學會了，要保持簡單

無論是寫代碼還是生活，都充滿著非常多看似令人癡迷的五彩繽紛的東西，你一定要學會透過現象去看到它的本質，否則我們就會盲目的追逐，精疲力竭。用佛法的話來說，永遠在經歷著輪迴，不要執著某一樣東西，這個世界是無常的，唯一不變的就是變化。科學不就是不停地的否定，去推翻自己之前的定論麼。沒有什麼鐵飯碗，也沒有什麼所謂的真理。保持簡單，保持自己的可塑性。

在這個飛速變化的時代，或者我們能做的，就是去找到那些本質的東西，而這些東西往往不容易貶值，是簡單的，基礎的，長久的，穩定的，是可以積累的。隨著時間的推移，你會越來越強大，得心應手。反覆咀嚼，進入新的境界。 錦上添花的東西，有更好，沒有其實也無傷大雅。保持簡單，是一種哲學。