改变从自己开始~
开篇
从其他前辈口中听过这样一句话:
软件开发，coding能力只占40%，称为硬技术。剩下的60%的软实力更大程度上决定了软件的质量。
做人篇
带新人
自己慢慢熬成了团队中的老人，自然开始承接了传承的工作，让新鲜血液们快速融入LEADAL研发大家庭。
但是，这个过程中发现了自身存在很多问题。
比如：
- 讲解过于理论化，不能很快地帮助对方解决当下的问题，反而让对方感到困惑或是有炫技嫌疑。
- 不知道怎么去合理地切割模块，导致最后双方本应各自维护的js有冲突的部分。
- 说话方式有时候会比较尖锐，会伤人自尊。
- 还有一个印象非常深刻，就是我忍受不了新人的bad code,于是竟然亲自去改对方的代码，结果对方一更新代码发现命名和程序思路完全变了，竟然不知道怎么继续编下去。上了对方自尊不说，还耽误了项目的进度。
其实这里面大部分责任在我，毕竟是我在带人，我起主导作用。
如果再让重新走这样的一个过程（这是一个经典的反思方式）。
首先，我会多花些时间在模块的划分上，定义好边界，井水不犯河水，各自维护各自的模块，避免代码维护上的冲突。其次尊重新人的劳动成果。每个人都有当新手的过程，如果自己的劳动成果轻易就被别人改掉了，删除了，无疑是一种否认和打击。指出存在的问题，不要亲自去改。
关系从破裂到和解再到复原
关系破裂的开始。
曾经因为一个小误会（或者说是我好心办坏事），其实是想激励对方（类似于激将法），说了一些打击新人自信心的话语。导致对方对我有些负面意见。
关系的和解。
后来在团队领导的指导下，我们进行了开诚布公的谈话，说开了，也就没事了。其实是我以为没事了。结果至少很长一段时间我渐渐能感觉出来我们之间还是有隔阂了，有种别扭的感觉。
关系的复原。
这是从放低自己的姿态开始的。真诚地去关心对方，真诚地在对方需要帮助的时候帮助对方（渴时一滴如甘露，醉后添杯不如无），发自内心地降低自己有些膨胀的意识。所谓“路遥知马力，日久见人心”。既然初心是好的，也就不怕人家误会。最后还是能成为朋友的~I believe~
处事篇
平衡研发时间和产品质量
慢慢成为了项目负责人才发现需要去平衡研发时间（研发成本）和产品质量，有些东西是要基础功能必须实现的，就要先执行。有些用户体验的东西尚且不影响功能的情况下，就可以在下一版本进行优化处理。毕竟我们是要为交付期限负责的。
say No——学会合理地拒绝需求
有一段时间，大家人人都成了紧绷的弹簧，任务量大，交付时间紧。技术总监已经明确表示，X项目的需求尽量不接了，但我还是不懂得拒绝。
最后自己忙的半死。
平衡研发时间和产品质量的部分已经提到了，实际上软件开发是在交付压力的情况下进行的，非常讲求平衡（当然，良好的项目经理尽量不让压力丢在研发人员身上，因为这样做对项目质量有害无利）。
于是我就亲身被教育了怎么去拒绝需求。更接地气的说法是砍需求。
原本一个多群柱形图（基于d3.js实现），还需要提供群组的差异化显示，我的回复是：“可以做，但是需要消耗一定时间。”总监直接就说，单个的柱形图有没有？有是吧，那你把多群柱形图拆分成n个单个柱形图。
起初我还没理解，停留在固有思维上，还解释计算位置啊之类的成为实现难点。后来总监又解释了一遍我才清楚。
我对砍需求的理解就是：找替代方案，优雅降级~
定位篇
给自己一个定位。
就目前的工作侧重分配而言，20%研发新产品，40%维护老项目（修复bug以及处理版本升级的新需求），40%在思考如何推进公司整体web开发模式的优化。
比如：
- 挖掘前端框架初始设计不合理或已过时的地方，进行优化。
- 接触新框架思想引入公司内部框架。vue和angular同样都是MVVM模式的框架，但vue是基于getter setter的单向数据流，但angular是基于脏值监测实现了双向数据绑定。这种MVVM模式的设计模式怎么更好地引入公司。（要的是本土化的解决方案，而非直接生硬引入）
- 如何更好地将Node引入公司现有地开发模式，利用Node命令行及其小工具提高全员开发效率。顺便引发对前端工程化及打包机制的思考。
- 怎样更好地让前端和后端协作（前后端分离）。比如后端集成后的前端页面插入了大量后端模板指令的东西，将导致页面没有复用价值或很难再被移植复用。再比如，后端改js会和前端的部分js冲突掉，目前公司的集成大部分是由后端人员来做。这种模式是否可优化，前端怎么更好地参与进集成工作？
- 前端如何更优雅地mock数据。现在我们mock数据都是手动一个个在拼json,这个过程能否简化，提供一些特殊语法？可参考：活儿好又性感的在线 Mock 平台 - Easy Mock
- 代码审查。其实目的有两个，一方面是帮助green hand更好地成长，另一方面是想发现组件命名风格，设计思路，那些可以进行合理的统一规范。
- 怎么才能更好地形成技术交流（讨论分享）氛围，而非停留在相互问问题的阶段。比如对近期的项目做汇报，阐述技术细节。比如介绍目前前端领域流行的思潮，围绕这个展开讨论，如何更好的有机地融入公司框架。
- 让组件更加精小，而非多功能战车。玩过红警的人都知道多功能战车，它既能打天又能打地，还能承载运输战斗部队的工作，因而获此名。但是对于维护人员来讲，维护多功能战车可能会是梦魇。因为TA必须先大概了解原组件的设计思路，之后要考量修改点是否会影响其他功能。通常情况下，新增了一个功能需求，可能对做大量兼容。比如目前最难维护的组件就是ui:workspace。而且现象是越新增东西，越膨胀，越难维护。
维护者最希望维护那些功能少而精（相对专一）的组件了。于是这个过程其实对抽象能力要求很高。对公共的部分要有高度抽象的意识和能力。 - 如何让组件的设计（至少是整体设计思路上保持一致性）。曾有机会，我有幸（之所以说有幸，是因为软件开发上一般要求谁作为原作者找谁反馈）维护到了其他人的组件。发现在某功能的实现上，对方的思路和我完全不同，而且引入了一些莫名奇妙的magic number（魔法数字，就是那些不加注释，写死的，容易让人困惑的数字）。这给维护工作带来了麻烦。
我在想如何在整体思路上统一组件开发的代码结构，命名风格，让代码更易读。毕竟，团队协作中，代码并不是只给自己看。
整体而言自己渐渐就是走向了中观与宏观之间的技术把控。但并不是说忽略了微观层面的东西。也会根据兴趣，去学习es2015，es7，svg，canvas，深入css等等。但很明显，微观层面的影响力太小了，顶多是个人成为技术大牛。但我更想做到的是大家伙一起成功，这样的幸福感是不一样的量级。
结语
再过一百零一天，就是我来到LEADAL的整整第二个年头了。
101，百尺竿头，更近一步！
整整两年的时光，学到的太多，创造的也多，改变亦多，可谓青春无悔！
写在第101天
网友评论