从17年4月初回福建到现在已经一年了，从做的学的想的几个角度来回忆下这一年都经历了什么。刚好在学校时候也是4月初毕业的，到现在已经毕业4年了。。。时间过得真快。。。

做了什么

流水账说一说做了什么。

前端画图表

去年4月初一回来的第一个活是画图表，用echart之类的在前端页面展示出漂亮一点的图表。当时有两种选择，一种是还是照之前用的方法，用jquery/直接写html和js之类的方式；另一种就是用时下流行的React类的框架/工程化做前端开发。

在这个小项目中，用React的最大的非技术上的优点就是可以使用很多高质量的组件，如蚂蚁金服的ANTD，做的真的很好看，最大的缺点就是之前没用过，要边学变做，速度上肯定会有影响。

稍微纠结和争取了下，最后用了React。选择这个不光是要学React，还包括要学习折腾webpack里面那些工程配置。但是写出来的代码是会比不用这类框架的要整洁（想象一下原生js或者jquery写网页时候的dom操作。。。）

微信平台上的开发

做了个小程序，简化了前台那边的某个的机械的查询填单动作。前端就是微信小程序，后端用的python。这是第一次在微信平台上折腾东西也是第一次用python写服务，但是过程还挺顺利 ~ ~ ~效果也不错 ~ ~

小程序的开发跟react挺像的（其实就是微信自己前端MV**框架），也是不提倡直接操作dom，此外还有一些调微信的接口，所以只要会react/augular/vue之类的，小程序的开发也会很好上手。。。

除了小程序外，接下来还做了个简单的公众号相关的开发，公众号开发就比小程序自由多了，因为公众号页面前端就不像小程序需要使用那套框架。相比于正常的web开发，就是多了个调用微信接口。

在内网部署Gitlab

之前用的是SVN。。。从没用过git的我每次和朋友聊天提到这个都觉得抬不起头。。。管理需求用的是禅道（界面的颜值就是停留在N年前的）。。。个人禅道最致命的就是需求和代码没法很好的结合起来看，这种所谓的项目管理是游离在代码之外的，对开发人员来说真不是很友好。

大概是半年过去了，那半年间，写代码时候好多都参考或者使用了github上的项目，天天上也就被洗脑了，反正也就只能跟着用像github这样的东西来管理项目和代码，才能有一种跟上主流使用工具的感觉，不然真的好土。

装是很好装，Ominibus就一个rpm包安装好就行了（但是最好用docker方式部署，非常方便）。。。gitlab文档很完整，照做就行。

gitlab对oAuth2的支持特别好，支持各种各样的其它登陆方式，为了使用方便，可以将其对接到已有的账号系统里去。而gitlab本身也可以作为oauth2的提供者，让其它服务可以用gitlab的账号信息来登陆（以后再说这块）。

又一个展示图表的项目（正在进行中。。。）

这个不像一开始那个只需要前端部分。。。而且还是放在移动端的。。。花了段时间来想具体怎么做（因为是画图表想着省事还试了各种BI…不过没用。。。最后用到了jupyter。。。）。 不管后端的开发还是前端开发，都只能算不太会，所以用了jhipster（spirngboot+angular）来生成了一些漂亮规范代码用也当作参考，第一次做这种前后端分离的单页面应用的项目。

学了什么

上面的实践中需要做了什么就学了什么，好了之前一直向往的东西和方法，这一年来也陆陆续续投入实践了，比如git/gitlab、docker、jupyter、django、react/angular、springboot、前后端分离、在微信上的开发。。。其中也有不少基础性的工作，用portus部署docker服务器；用nexus3部署内网的pypi/maven/npm服务啊；部署gitlab服务器（先安装包方式，后来还改成docker方式）啊。。。

虽然都不是很深入，但也都就项目而言也够用。都是自学的，也都是逼迫自己走出舒适区（不再用熟悉的陈旧的方式的开发），所以自我感觉这一年对于学到的东西挺满意

想了些什么

这个就比较杂乱了。。。

方向的重要性

之前我们领导也有说过方向很重要，要使巧劲。。。业务那边在技术上懂得不多，全照他们的所提需求来做，费劲效果还不定有多好。。。事实也的确是这样。

这一年来个人写的代码里，产生效果最明显的是某个前前后后开发总时间不到一个月的小程序。但是这个小程序解决了某项机械动作的痛点。。。这个痛点功能的实现呢，又是各个地方都不同的不可能是总公司那边给我们做好。

所以看到另一家分公司实现了类似的功能后。。。动了点脑子想出了个更好的解决方案（真是不好意思不能在这边说得详细。。。）。。。结合当时的一个新的热点入口，省钱又方便地解决了这个问题哈哈

效果很显著，前台每天都有人在使用这东西。。。加速了某个业务的流程～～～

之后回想起这个小项目，自己都觉得不可思议，因为从没做过这么小又实用效果还好的东西。。。而最后的这个好用的解决方案，回想起来，也只有技术这边才懂得提出（啊。。。不能说具体真是憋死。。。），并且有个各地虽然类似但具体展现不同的差异，也刚好总公司那边的技术无法做到适配各个分公司完全自动化，只能做个接口出来。这才给了这个项目空间。

这也给我启示：

  1. 要实地去了解一线的业务，结合技术使巧劲提出接地气的解决方法
  2. 多了解同业同系统内的先进实用创新点及其实现的要点，就算不能直接拿来用，也会有所启发

关于实践和学习

好多新名词啊新技术啊，不实际用适合感觉挺高大上的，但实际在用的话其实上手难度也都不大，所以这类东西还是都是以实际动手为主，才知道是干嘛的，才知道是在实践中解决了什么问题，才能对这类新技术做出客观评价。。。。

反过来，就好比无机不能评测似的。。。在对某种新技术有实际实践的了解之前，那可能还是保守点不评价比较好。

顾虑

开发效率

尽管过去一年学了不少，也做了不少，但实际上开发效率还是蛮低的。。。选型花时间，学习也花时间，构思也花时间。。。实际开发效率就低了。。。

也不知道是不是多做就能解决这个问题