2011年的时候，我刚上大一。在这一年开始学习前端开发，那时候还叫美工，主要是切图和写页面。现在已经是工作的第八个年头了，在这个行业摸爬滚打已经算是很老的人了。经历了行业的兴起，也看到了很多行业怪相。
我认为前端是一个资源型岗位，那里需要哪里搬，入门门槛极低，上限也不高。我也认为，前端这个岗位其实是软件开发中岗位细分出来的一个畸形岗位。
在提倡前后端分离之后，前端卡在设计和后段之间，就做着那一点点画页面和调接口的事情。对，我说的就是：前端做的工作是画页面和调接口。
随着Node.js的发展，前端们觉得自己拥有了与后端掰手腕的能力，凡是后端做过的事情，统统想要用Node.js来做一遍，所谓“提高前端天花板”。这种事情在阿里等大厂屡见不鲜。这么多年过去了，我认为有点自嗨的味道。
不能否认Node.js出来之后前端工程师能做更多是的这个事实，但是这些事情需要每个人都做一次吗？需要每个人都来做一个Web框架吗？大部分前端的工作还是不同的业务间跳来跳去，他们甚至工作好几年都用不上Node.js，因为他们的工作根本不需要。但是行业的风气慢慢变了，只会写业务的前端是没有技术能力和潜力的。
随着互联网的发展，面向的领域和受众越来越多，软件界面的要求也变得更高了。UI开发依然是切页面和调接口，但是为了满足更高的软件要求，需要用工程化方法构建和维护有效、实用和高质量的软件。前端工程化的概念就出来了。前端们会认为，配合上Node.js，前端能做的事情更多了，咱们天花板更高了。同样的，行业的风气加剧变化，不会前端工程化的前端是没有技术能力和潜力的。
大部分前端开发的工作还是写页面和调接口，其他周边的工作最后的目的服务于这两件事情，让写的页面更快更好，接口更快更稳定。而这些工作呢，在前端这个岗位内部继续细分。一个很常见的例子就是，很多公司成立大前端组，一部分人专作业务，一部分人专门搞一些技术项目来支撑业务组的工作，称之为“前端基建”。然后这又出现了一些很奇怪的现象：
- 做基础支撑工作的前端很容易脱离实际业务场景空想出一些设计方案，最后落地的时候很艰难，但是他们的绩效不会太差；做业务的前端帮公司赚钱，却被视作没有技术含量，可替代性强，单作业务无法拿到高绩效。
- 基础支撑的前端要求“技术反推业务”，从技术的角度去帮助业务增长；做业务的同学则需要一些活来证明自己的技术能力；
- 甚至还出现了鄙视链，做基础建设的前端比业务仔更高级，大家都不愿意做业务仔。
实在是太奇怪了，现在的评价标准中有一条是：做好本职工作是远远不够的。那么问题来了，职责细分的意义是什么呢？前端这个岗位在软件研发过程中是否有些多余呢？
我从来不想把自己限定在前端这个岗位上，每次介绍我的时候我都希望可以是“软件开发工程”。在滴滴的时候，没有“xxx前端”这样的title，这点我很喜欢。我一直以为并坚持的是一个优秀的工程师在于解决问题的能力和接受新鲜事物的学习能力。入职新公司之后，有更多时间可以做自己想做的事情。业余时间开始接触各种技术和非技术相关的事物，开发了两个桌面应用，Lettura 和 Pavo。从产品构想到最后发布，需要具备一个完整的研发团队的所有能力，期间学习了很多，收获了很多，让我对独立开发一款产品有了更大的信心。
在 ProductHunter 和 Twitter 上浸泡了一段时间后，参考社区中一些独立开发者的经验和思考，我做出了一个决定：给自己五年时间，打造一款付费订阅的软件。说实话，我从来没做过这些，从前期的产品调研到后期的运营推广，很多工作都未曾涉足。但是我依然想勇敢地迈出这一步，原因有以下几点：
- 自己有写代码和折腾技术的习惯，不如把时间利用起来，做出一点成绩。
- 软件研发的工具链生态很完善，可以借助很多平台完成一些工作，不钻技术细节的话其实很简单。
- 给自己创造机会学习和体验完整的软件研发周期。
- 运营推广很锻炼人。
这个五年计划一定是充满挑战的，也一定会有很多收获。希望五年之后，能够有一款让我自豪的作品问世。