复盘总结

去年三月份开始进入一家外包公司实习，六月份辞职并于七月份正式毕业，随后在八月中旬进入目前所在的创业公司，不想已然过去了一年有余，岁月如梭，着实不饶人。那个年轻，稚嫩的咱们在一年的洗礼下悄然发生了变化，至少体重已经快超标了。本着一个程序猿的码农工做者，心里却住着一个如此文艺骚青年，老是忍不住想要写点东西，祭奠祭奠已然逝去的一年，所发生的那些事，以及关于成长，关于感慨，关于当下对本身的定位的见解。

 

进入创业公司，是真的很累。很庆幸去了一家技术氛围相对浓厚的创业公司，虽然终日加班——莫名想起一个段子，话说程序员毕业一年却写着三年工做经验，而两年时间来自于加班……咱们是996的工做制度，其次咱们七八个后端技术人员每周发一个版本，因此说996彷佛不是很贴切，毕竟每周总有一两个夜晚是凌晨三四点才在楼下点开滴滴软件，坐在出租车里，隔着玻璃窗望着天上的明月，彷佛也没有多么明亮。记得有段时间，进入全员疯狂加班的状态，近乎天天都在增量发版本。这段显得有点黑暗，有点阴沉的时间里，我慌张过，忐忑过，想过逃避加班，想过离职，总之，就是想着若是能够无所不用其极的躲避加班，那该多好？现在回过头去思考，看待过去，反而以为当时彷佛也没有那么累，由于天天都彷佛在进步，那种感受恐怕也是有点奇妙与刺激的吧。固然，除此以外，必须感恩个人爱人，是她给了我无微不至的关怀与鼓励。可是，反正即使再刺激，我也不会回去那样的生活……

 

不知道其余程序猿是否会有一种心理：我宁愿将时间花在研究各类中间件，各类框架，乃至各类框架源码，也不肯多花时间在业务代码上。

 

经常我便会有这种强烈的感受，做为技术人员我渴望去研究框架研究技术，业务代码反反复复都是if else……技术谈何进步？薪资谈何上升？这种显得有点偏激，有点执着的想法直接致使我提出了离职。缘由大体是，新的框架来了，网上各类人讨论的热火朝天，如火如荼，众说纷纭，而我刚刚于十二点下班，复制完今天的最后一行业务代码。论坛，QQ技术群里各类大牛分析，网上博客层出不穷，别人都在进步而我居然还在写这些鸟玩意，什么鬼！！！大概有一个月后，便开始有人在群里招聘，精通XXX新技术新框架，月薪XXK，地址XXX地址。看到群里这样的招聘，慌了，个人天，外边的世界都开始使用它了，而我竟然偏安一隅，我这是作技术的吗？苦苦挣扎的心情，可是你始终没有提出说要离职，直到……你身边的朋友开始在讨论这些你不是很懂的问题，或者看到他的QQ头像在某个群里发表大牛般的指导性言论，探讨如何新技术新框架的前世此生的时候，在回去的路上心里翻腾不止，在同窗之中已经落后这么多了吗，因而拍案而起，于凌晨三点在宿舍电脑前写完离职申请，并定时于明早十点发给了人事……

 

最后，在大佬们的游说下，我仍是没有离职，缘由不少，可是本质缘由是我没钱，没工做在深圳过不下去……

 

时至今日，对于新技术新框架的层出不穷，态度反而是更加谦卑而敬畏。以前我是打算在一个系列文章，探索一下MyBatis的源代码，虽然网上很是多这样的系列文章，可是那毕竟不是本身的东西，没有真正去探索一下，很难将其中的内部架构，内部原理真正的了然于胸，因而动手写了好几篇，但是后来又被我删掉了，缘由不外乎就是我本身没有那个能力真的输出一些本身思考过，经得起探索，经得起考验的真知灼见，假若写的有偏差，而又恰好与人瞧见，岂非误人子弟？其次，若是从产品的角度来看待框架看待技术彷佛会有意想不到的另外一番“美景”。

 

在创业公司待的这段时间，彷佛回归业务反而更是难了，至少若是去接手一个新的框架的时候，满满的文档拿过来跑个demo出来，参照文档持续跟进总归是能够解决技术问题。可是业务上的思考，才是检验成长的关键成果。当接手一个业务功能的时候，是否去思考这个功能给咱们的用户带来了什么样的价值？又能为咱们带来多少价值，挽回多少用户，提升多少竞争力，战略层面上它的所扮演的角色是什么（站在公司战略的层面去思考）？ 市场反馈回来的需求是不是伪需求？竞品是如何实现这个业务功能（站在产品的角度去思考）？须要投入多少时间需实现该业务功能？如何设计这个业务功能？代码层面是如何设计这个功能？该功能波及多少其余功能（站在实际实现功能的角度去思考）？等等……接手一个业务功能到真正的投入编码所花费的时间真的不少。当咱们仔细去看待这个过程的时候，就会发现这一系列下来，思考的越前的人，他的所关注的点也就愈发的不同。因此，咱们再写着代码，而老板却在写着融资方案（这些思惟都是技术总监时常给我安利的，感恩总监大人）

 

成长，彷佛就是看待问题的角度，以及解决问题的思路。

 

另一点说到从产品的角度去看待一个框架，本来在我看到学习框架的最佳方式就是打开该官方文档跑demo，后来与朋友交流过程当中，发现若是从一个产品的角度来看到一个框架的意义，可让咱们站在另一个角度来看待这个问题。好比MyBatis，咱们用了那么久的Mybatis，写了那么多的代码，是否拷问过本身，为何会有MyBatis？或许你能够罗列出一大堆的东西，可是你却很难有条不紊的讲出来，可能就是想到一个就是一个。仿佛你并无真正的用上它，感觉它的好，也接受它的坏，乃至你本身投入开发MyBatis插件进行优化……好比：为何会有它 --> 规范哪里很差 --> 竞品对比 --> 哪里好，为何好，哪里很差，为何很差--> …… --> 最终回归到原理的时候，每每你已然理解的很透彻，去看源码，每每偏向于了解它的架构设计，代码设计。其实做为开发者，我一直都最喜欢设计模式，钟情于它，总以为它的魅力实在是太大了。在实际开发上，个人老大是一个将近十年的开发老兵了，由于我偏向于热衷这些东西，因此常常请教他。我常常说这里我应该怎么设计，其实我就想说我要用什么设计模式，而后我在百度一下看看怎么搞，结果他上来以后看了看，说这里抽一个接口，那里抽一个抽象类……从头至尾没说过什么设计模式，而后我就照作了。有时候我会说，这里用什么设计模式是否是更好，他却说这里抽象一个接口就能够了，搞那么复杂作什么。三两次后我再问他，他却说，什么设计模式，那些东西本身搞去，别浪费我时间。……后来我慢慢放弃了执着于遵循设计模式（虽然我在博客里搞了挺多的，写博客的目的是作笔记），后来跟老大聊天的时候问起设计模式，他说好多年之前他用C#跟C++打过demo，早忘了这些东西了……他用他十年的经验让我其实少走了不少弯路，我虽然依然很菜，可是他教给个人解决方式实际上是回归到本质问题——抽象的理解。因此在设计层面上若是你也拷问本身 ：这么作有什么问题？怎么作会更好扩展？等等……慢慢的，这些问题彷佛都变成了为何。（虽然个人产品眼光是狭隘的，可是我坚持多看看产品经历的文章，多学习产品经理的思惟，指望后续能够有更多的机会去学习产品理念）

 

简单复盘了一下，对本身当下的定位已然很明确了。复盘事后，思惟上老是会有所变化。

 

真的很是感谢技术总监与研发经理两位大牛对个人深入指导。改变了个人思惟方式。改变了我看待问题的方式，角度，处理问题的手段，姿式，帮助我成长了不少，在看了不少文章后，我以为有句话其实仍是有点道理的：用产品经理的眼光去看待问题，用架构师的眼光去解决问题。