在 2011 年，我剛上大一。在這一年開始學習前端開發，那時候還叫美工，主要是切圖和寫頁面。現在已經是工作的第八個年頭了，在這個行業摸爬滾打已經算是很老的人了。經歷了行業的興起，也看到了很多行業怪相。
我認為前端是一個資源型崗位，那裡需要哪裡搬，入門門檻極低，上限也不高。我也認為，前端這個崗位其實是軟件開發中崗位細分出來的一個畸形崗位。
在提倡前後端分離之後，前端卡在設計和後段之間，就做著那一點點畫頁面和調接口的事情。對，我說的就是：前端做的工作是畫頁面和調接口。
隨著 Node.js 的發展，前端們覺得自己擁有了與後端掰手腕的能力，凡是後端做過的事情，統統想要用 Node.js 來做一遍，所謂 “提高前端天花板”。這種事情在阿里等大廠屢見不鮮。這麼多年過去了，我認為有點自嗨的味道。
不能否認 Node.js 出來之後前端工程師能做更多是的這個事實，但是這些事情需要每個人都做一次嗎？需要每個人都來做一個 Web 框架嗎？大部分前端的工作還是不同的業務間跳來跳去，他們甚至工作好幾年都用不上 Node.js，因為他們的工作根本不需要。但是行業的風氣慢慢變了，只會寫業務的前端是沒有技術能力和潛力的。
隨著互聯網的發展，面向的領域和受眾越來越多，軟件界面的要求也變得更高了。UI 開發依然是切頁面和調接口，但是為了滿足更高的軟件要求，需要用工程化方法構建和維護有效、實用和高質量的軟件。前端工程化的概念就出來了。前端們會認為，配合上 Node.js，前端能做的事情更多了，咱們天花板更高了。同樣的，行業的風氣加劇變化，不會前端工程化的前端是沒有技術能力和潛力的。
大部分前端開發的工作還是寫頁面和調接口，其他周邊的工作最後的目的服務於這兩件事情，讓寫的頁面更快更好，接口更快更穩定。而這些工作呢，在前端這個崗位內部繼續細分。一個很常見的例子就是，很多公司成立大前端組，一部分人專作業務，一部分人專門搞一些技術項目來支撐業務組的工作，稱之為 “前端基建”。然後這又出現了一些很奇怪的現象：
- 做基礎支撐工作的前端很容易脫離實際業務場景空想出一些設計方案，最後落地的時候很艱難，但是他們的績效不會太差；做業務的前端幫公司賺錢，卻被視作沒有技術含量，可替代性強，單作業務無法拿到高績效。
- 基礎支撐的前端要求 “技術反推業務”，從技術的角度去幫助業務增長；做業務的同學則需要一些活來證明自己的技術能力；
- 甚至還出現了鄙視鏈，做基礎建設的前端比業務仔更高級，大家都不願意做業務仔。
實在是太奇怪了，現在的評價標準中有一條是：做好本職工作是遠遠不夠的。那麼問題來了，職責細分的意義是什麼呢？前端這個崗位在軟件研發過程中是否有些多餘呢？
我從來不想把自己限定在前端這個崗位上，每次介紹我的時候我都希望可以是 “軟件開發工程”。在滴滴的時候，沒有 “xxx 前端” 這樣的 title，這點我很喜歡。我一直以為並堅持的是一個優秀的工程師在於解決問題的能力和接受新鮮事物的學習能力。入職新公司之後，有更多時間可以做自己想做的事情。業餘時間開始接觸各種技術和非技術相關的事物，開發了兩個桌面應用，Lettura 和 Pavo。從產品構想到最後發布，需要具備一個完整的研發團隊的所有能力，期間學習了很多，收獲了很多，讓我對獨立開發一款產品有了更大的信心。
在 ProductHunter 和 Twitter 上浸泡了一段時間後，參考社區中一些獨立開發者的經驗和思考，我做出了一個決定：給自己五年時間，打造一款付費訂閱的軟件。說實話，我從來沒做過這些，從前期的產品調研到後期的運營推廣，很多工作都未曾涉足。但是我依然想勇敢地邁出這一步，原因有以下幾點：
- 自己有寫代碼和折騰技術的習慣，不如把時間利用起來，做出一點成績。
- 軟件研發的工具鏈生態很完善，可以借助很多平台完成一些工作，不鑽技術細節的話其實很簡單。
- 給自己創造機會學習和體驗完整的軟件研發周期。
- 運營推廣很鍛煉人。
這個五年計劃一定是充滿挑戰的，也一定會有很多收獲。希望五年之後，能夠有一款讓我自豪的作品問世。