前言
沒接觸編程之前，總覺得它很神祕，很牛逼。每當有新的系統，新的軟件出來時，總想衝在前頭，然後 down 下來好好體驗。
後來加入了程序員大軍，才發現編程並非想象中的那麼美好，經常要面對完成不了的需求，和背不完的鍋，真的是一部辛酸編碼史。
儘管如此，我們的工作也算是在為機器注入靈魂，還是挺高大上的。只是很多時候不得不面對一些殘酷現實，下面就來聊一聊這幾年的編程感悟吧！
1、 bug 是修不完的
不知各位猿友有沒有這樣的體會：每當週五臨近下班時，測試總會向你扔來一大堆的 bug 工單。
而就在你以為所有的 bug 都解決完後，回過頭象徵性的驗一驗之前的接口時，突然發現，他媽的又不正常了。
這種感覺就像按下一個葫蘆，起來一個瓢，以為解決完了，才發現只是自己以為。
那為什麼會一直修不完呢？一方面是因為程序它就像一個精密的機械手錶，很多地方都是有關聯性的。
當你要改動一個地方的時候，往往得把它所有的關聯點都得考慮一遍，有點像深度優先遍歷。可想而知，一旦系統複雜，那大多時候我們也只能是走一步看一步。
另一方面只要我們的系統還有用戶在使用，那就會有改動，特別是對於三天兩頭加需求的互聯網行業來說，這更是家常便飯。
在這麼高頻率的改動下，設計得再好的系統也經不起折騰。就好像一輛高速運動的跑車，還總想著給它換零件一樣。
所以大夥看那些成熟的開源框架，都有屬於自己的一個發佈計劃，而且都是相隔幾個月的那種。
可想而知：減少需求是多麼的重要！
2、if else 就是我們的日常編碼模式
想象一下，如果沒有了 if...else 那我們的程序會怎麼樣？是的，一切都糅合在一起了，再也不能愉快的進行流程控制了。
正是因為有了 if...else，讓我們能以貼近生活的方式去劃分代碼邏輯。
可以說 if...else 在程序裡無處不在，甚至一敲代碼，我們就會自動聯想到 if...else 所要對應的業務線，多麼的渾然天成！
3、過早的優化，不是優化
以前遇到過一個同事，總喜歡開口閉口就談拓展性預留，說哪個場景有可能會用到，所以要提前預留下。
可實際上到了後面的開發，80% 的概率是沒有再用到這些優化點的了。相當於將精力花在了沒有發生的事件上。
其實，這也能理解，因為產品經理總是動不動的改需求，而作為一名優秀程序員的我們，總想提前預判這些改動點，以最小的代價完成修改。
可實際在項目剛開始的時候，是屬於一個不穩定開發時期，會存在很多變數。
如果過早的優化，比如添多餘的數據庫字段，劃分很細的服務等這些對未知場景的優化，其實意義並不大。
過早的優化，不是優化，真正的項目痛點不會在一開始就暴露出來，等我們被項目完整的虐過一回，到時也就自然而然的知道該怎麼優化了。
4、大多數項目就是在增刪改查
現在的互聯網項目其實就是在將生活數字化，數字化的過程肯定是需要和數據打交道。
所以，大多數項目其實就是在解決數據從哪裡來，又回到哪裡去的問題。
至於這中間採用了什麼技術方案，也只是解決手段不同而已。最終還是得落到對數據處理這一終極目標。
而對數據處理肯定逃不過增刪改查，這也是很多項目存在的意義！通過不斷的對數據加工處理，呈現出更貼近我們生活的虛擬世界。
5、一人挑起一款產品的時代已經過去了
互聯網行業發展到現在 20、30 年了，從僅限於專業人員使用，到現在的應用普及。可以說用戶已經從原來什麼都不懂的小白，升級為資深體驗家了。
而在此期間所誕生的優秀產品，已經和用戶深深綁定了，想要靠我們個人去扭轉用戶的使用習慣，基本不可能，更別說有可能遭到大企業的狙擊。
所以，想要獨自開發出一款現象級產品，真的難如登天！就像錯過了 80, 90 年代下海大潮一樣，我們已經很難再撼動這個成熟市場了。
當然，互聯網的繁榮發展也為我們這些後來者奠定了基礎，定製了很多標準化框架，像 TCP、HTTP 等，
也算為我們的開發工作提供了很多便利。
6、程序員真的髮際線高！
最後，我們來說一說程序員最最殘酷的真相。沒錯！就是我們那瓦亮瓦亮的額頭。那是高級程序員的象徵，是辦公室裡最靚麗的一道風景！
相信只要我們好好努力，總有一天，都會達到這個境界！≥Ö‿Ö≤
總結
以上就是這幾年編程生涯的感悟，歡迎大家一起分享！