去年三月份开始进入一家外包公司实习，六月份辞职并于七月份正式毕业，随后在八月中旬进入目前所在的创业公司，不想已然过去了一年有余，岁月如梭，着实不饶人。那个年轻，稚嫩的我们在一年的洗礼下悄然发生了变化，至少体重已经快超标了。本着一个程序猿的码农工作者，内心却住着一个如此文艺骚青年，总是忍不住想要写点东西，祭奠祭奠已然逝去的一年，所发生的那些事，以及关于成长，关于感慨，关于当下对自己的定位的看法。
进入创业公司，是真的很累。很庆幸去了一家技术氛围相对浓厚的创业公司，虽然终日加班——莫名想起一个段子，话说程序员毕业一年却写着三年工作经验，而两年时间来自于加班……我们是996的工作制度，其次我们七八个后端技术人员每周发一个版本，所以说996似乎不是很贴切，毕竟每周总有一两个夜晚是凌晨三四点才在楼下点开滴滴软件，坐在出租车里，隔着玻璃窗望着天上的明月，似乎也没有多么明亮。记得有段时间，进入全员疯狂加班的状态，近乎每天都在增量发版本。这段显得有点黑暗，有点阴沉的时间里，我慌张过，忐忑过，想过逃避加班，想过离职，总之，就是想着如果可以无所不用其极的躲避加班，那该多好？如今回过头去思考，看待过去，反而觉得当时似乎也没有那么累，因为每天都似乎在进步，那种感觉恐怕也是有点奇妙与刺激的吧。当然，除此之外，必须感恩我的爱人，是她给了我无微不至的关怀与鼓励。但是，反正即便再刺激，我也不会回去那样的生活……
不知道其他程序猿是否会有一种心理：我宁愿将时间花在研究各种中间件，各种框架，乃至各种框架源码，也不愿多花时间在业务代码上。
常常我便会有这种强烈的感觉，作为技术人员我渴望去研究框架研究技术，业务代码反反复复都是if else……技术谈何进步？薪资谈何上升？这种显得有点偏激，有点执着的想法直接导致我提出了离职。原因大致是，新的框架来了，网上各种人讨论的热火朝天，如火如荼，众说纷纭，而我刚刚于十二点下班，复制完今天的最后一行业务代码。论坛，QQ技术群里各种大牛分析，网上博客层出不穷，别人都在进步而我竟然还在写这些鸟玩意，什么鬼！！！大概有一个月后，便开始有人在群里招聘，精通XXX新技术新框架，月薪XXK，地址XXX地址。看到群里这样的招聘，慌了，我的天，外边的世界都开始使用它了，而我居然偏安一隅，我这是做技术的吗？苦苦挣扎的心情，但是你始终没有提出说要离职，直到……你身边的朋友开始在讨论这些你不是很懂的问题，或者看到他的QQ头像在某个群里发表大牛般的指导性言论，探讨如何新技术新框架的前世今生的时候，在回去的路上内心翻腾不止，在同学之中已经落后这么多了吗，于是拍案而起，于凌晨三点在宿舍电脑前写完离职申请，并定时于明早十点发给了人事……
最后，在大佬们的游说下，我还是没有离职，原因很多，但是本质原因是我没钱，没工作在深圳过不下去……
时至今日，对于新技术新框架的层出不穷，态度反而是更加谦卑而敬畏。之前我是打算在一个系列文章，探索一下MyBatis的源代码，虽然网上非常多这样的系列文章，但是那毕竟不是自己的东西，没有真正去探索一下，很难将其中的内部架构，内部原理真正的了然于胸，于是动手写了好几篇，可是后来又被我删掉了，原因不外乎就是我自己没有那个能力真的输出一些自己思考过，经得起探索，经得起考验的真知灼见，倘若写的有误差，而又刚好与人瞧见，岂非误人子弟？其次，如果从产品的角度来看待框架看待技术似乎会有意想不到的另一番“美景”。
在创业公司待的这段时间，似乎回归业务反而更是难了，至少如果去接手一个新的框架的时候，满满的文档拿过来跑个demo出来，参照文档持续跟进总归是可以解决技术问题。但是业务上的思考，才是检验成长的关键成果。当接手一个业务功能的时候，是否去思考这个功能给我们的用户带来了什么样的价值？又能为我们带来多少价值，挽回多少用户，提高多少竞争力，战略层面上它的所扮演的角色是什么（站在公司战略的层面去思考）？ 市场反馈回来的需求是否是伪需求？竞品是如何实现这个业务功能（站在产品的角度去思考）？需要投入多少时间需实现该业务功能？如何设计这个业务功能？代码层面是如何设计这个功能？该功能波及多少其他功能（站在实际实现功能的角度去思考）？等等……接手一个业务功能到真正的投入编码所花费的时间真的很多。当我们仔细去看待这个过程的时候，就会发现这一系列下来，思考的越前的人，他的所关注的点也就愈发的不一样。所以，我们再写着代码，而老板却在写着融资方案（这些思维都是技术总监时常给我安利的，感恩总监大人）
成长，似乎就是看待问题的角度，以及解决问题的思路。
另外一点说到从产品的角度去看待一个框架，原本在我看到学习框架的最佳方式就是打开该官方文档跑demo，后来与朋友交流过程中，发现如果从一个产品的角度来看到一个框架的意义，可以让我们站在另外一个角度来看待这个问题。比如MyBatis，我们用了那么久的Mybatis，写了那么多的代码，是否拷问过自己，为什么会有MyBatis？或许你可以罗列出一大堆的东西，但是你却很难有条不紊的讲出来，可能就是想到一个就是一个。仿佛你并没有真正的用上它，感受它的好，也接受它的坏，乃至你自己投入开发MyBatis插件进行优化……比如：为什么会有它 --> 规范哪里不好 --> 竞品对比 --> 哪里好，为什么好，哪里不好，为什么不好--> …… --> 最终回归到原理的时候，往往你已然理解的很透彻，去看源码，往往偏向于了解它的架构设计，代码设计。其实作为开发者，我一直都最喜欢设计模式，钟情于它，总觉得它的魅力实在是太大了。在实际开发上，我的老大是一个将近十年的开发老兵了，因为我偏向于热衷这些东西，所以经常请教他。我经常说这里我应该怎么设计，其实我就想说我要用什么设计模式，然后我在百度一下看看怎么搞，结果他上来之后看了看，说这里抽一个接口，那里抽一个抽象类……从头到尾没说过什么设计模式，然后我就照做了。有时候我会说，这里用什么设计模式是不是更好，他却说这里抽象一个接口就可以了，搞那么复杂做什么。三两次后我再问他，他却说，什么设计模式，那些东西自己搞去，别浪费我时间。……后来我慢慢放弃了执着于遵循设计模式（虽然我在博客里搞了挺多的，写博客的目的是做笔记），后来跟老大聊天的时候问起设计模式，他说好多年以前他用C#跟C++打过demo，早忘了这些东西了……他用他十年的经验让我其实少走了很多弯路，我虽然依然很菜，但是他教给我的解决方式其实是回归到本质问题——抽象的理解。所以在设计层面上如果你也拷问自己 ：这么做有什么问题？怎么做会更好扩展？等等……慢慢的，这些问题似乎都变成了为什么。（虽然我的产品眼光是狭隘的，但是我坚持多看看产品经历的文章，多学习产品经理的思维，期望后续可以有更多的机会去学习产品理念）
简单复盘了一下，对自己当下的定位已然很明确了。复盘过后，思维上总是会有所变化。
真的非常感谢技术总监与研发经理两位大牛对我的深刻指导。改变了我的思维方式。改变了我看待问题的方式，角度，处理问题的手段，姿势，帮助我成长了很多，在看了很多文章后，我觉得有句话其实还是有点道理的：用产品经理的眼光去看待问题，用架构师的眼光去解决问题。