一些情况

1.本人毕业于2014年，福大软件工程专业。
2.从大一C语言学的一头雾水，考试冒冷汗，中间的各种专业课，说真的，且不说《算法与数据结构》，就说Java语言，操作系统，计算机网络等等，没有一门是有把握，考试能轻轻松松的。最终，还是迷迷糊糊把大学的专业课上完了，不是很有自信心的毕业了。
3.真正对代码开始有感觉，还是在大四下开始的实习。
4.很感激第一份工作，是学长给的机会。说真的，当时对算法很没信心（即使是现在也是有些阴影），学长问的冒泡排序都写不出来，渣成狗了。还好面试的不是算法岗，只是初级的Java工程师，实际工作中，就是围绕增删改查实现业务。
5.说到学长，不得不感激他对我的信任，感激他在工作中给予的帮忙和指导。他对代码质量的要求，事情要做的比别人好的不服输心态，对我影响很大，我也在努力坚持。
6.从毕业到现在，换了好几次工作了。舜亚（后来改成和齐家签合同了），美图（差不多4个月），ws（待了将近1年半），到现在在卖咖啡

回顾

8月21之前

这是在ws的日子。
我所在的部门是负责做客户使用的系统，在公司做的算是最上层的组件了，核心数据或关键业务都不在我们这边。

关于技术

我负责的是web系统，主要有两大功能：报表和自助配置。整体上来说，报表是比较简单的，自助配置是比较复杂的。

感悟

• 不要拷贝代码，能抽取复用的，就不要犹豫
• 不要用魔法数，推荐使用常量或枚举
• 该加索引还是要加的，可以借助explain查看执行计划
• 要善用封装和抽象（比如session 相关的key可以封装在SessionUtil工具类，避免到处散落session key，功能调整时比较不会落掉代码；又比如，正则表达式校验可以考虑根据业务封装个Util类，而不是在使用的地方直接暴露正则），以此提升代码可读性和可维护性
• 对于使用Spring开发项目的，能用Bean就不要用静态类，静态方法。这些对于单元测试是不友好的
• 借助阿里巴巴、sonarLint、checkStyle等静态代码检测工具，发现代码坏味道，统一项目的代码风格，提升代码质量和可读性
• 约定项目使用到的专有名词，并形成文档。避免一人一个说法，一个接口一个写法
• 要熟悉吃饭的工具，比如IDEA的快捷键，调试，插件（比如：jrebel，git/svn，translation等），重构功能；又比如Chrome的调试工具，调用栈，Network等等。工具是第一生产力
• 框架性的东西如果有疑问，可以直接看源码
• 对于SDK类型的系统，需要提供接入手册，升级文档，版本变更说明，兼容性说明，并维护常见问题记录。你想想，当你使用某个SDK的时候，什么文档都没有，还得硬着头皮接入，维护的人又经常无法及时响应，内心会有多少只草泥马；同样，你做为SDK维护者，如果每天都是回答一些重复问题，做一些重复动作，如果接入者能自助完成，你该有多轻松！
• 对于SDK类型的系统，如果SDK是自身和其他项目都有在使用，最好不要在其中写只和自身有关的功能，可以考虑暴露扩展点来实现，SDK要尽量保证通用性
• 对于SDK类型的系统，如果可以，最好能记录每个接入方当前使用的SDK版本，这样对于升级和问题调查都有帮助
• 移除无用代码。项目都是越来越复杂的，无用代码很容易干扰视线，无形中增加耦合度。版本控制可以让你找到历史记录
• 监控（运营指标和系统健康/运行状态）能让你了解系统运行状态，对全局有个把握

关于团队

• 不要让一粒老鼠屎，坏了一锅粥。对于影响团队积极性的行为，需要引起重视，努力想办法解决，不然一个团队就没有凝聚力，进而影响到项目的进度和质量
• 需求设计文档、原型设计等需要约定一些通则，定义团队内使用的业务术语，一些大方向的约定，减少不同角色间的沟通。比如：需求文档可以提炼出一个通用模板，避免遗漏一些经常需要又容易忘记的内容；比如约定前端界面风格，错误提示处理等等
• 根据团队情况，灵活安排回顾会（我更倾向搞个团队内的吐槽大会），会议的原则是：对事不对人！回顾会的目的：让团队对过去一个阶段的工作情况做总结和反思，表扬优秀的成员，收集团队遇到的困难和不和谐的事情并寻找和制定解决方案，对于解决方案需要指定成员负责落实或监督。回顾会不适合定期展开，比较适合根据团队工作情况和任务情况灵活安排
• 如果团队有紧密依赖其他团队的，在合作过程中难免会有磕磕碰碰。因为分工，团队间存在一些信息不对称，比如:互不清楚对方系统技术细节,导致不清楚哪些功能或设计为什么无法实现; 互不清楚对方团队工作饱和度，导致无法及时沟通。这种情况下，建议团队间一起开个技术分享会或者茶话会，解决双方的疑问，增加互信
• 团队的领导者，建议能适当的和团队成员聊聊天，收集意见或建议

关于产品

• 对于产品的理解程度，会影响到新增功能的取舍，影响到开发人员的技术实现，进而影响到系统迭代能力。个人认为，好的开发人员要向产品经理靠近，或者说要提升自身的产品思维

8月21号之后

换了工作，一开始以为帝都来的和尚们会念经，面试的时候，把自己的姿态放得比较低，并没有尝试争取更高的待遇。然而，入职后发现，他们的经也是难念，技术能力并没有那么高的高度，团队间的协作能力也是打个问号。

存在以下问题:

• 基础组件/中间件要么缺少抽象，要么缺少文档，要么功能不全，要么直接就是假功能
• 基础服务组件没有平台化，各个业务线各部署一套，不好维护，发布和版本维护都是头疼（现在又开始在做平台化了）
• 答疑号响应慢。有些是因为没有对日常答疑进行汇总整理成wiki，导致问题重复解答；有些是权限设计不合理，授权只能找答疑号
• RPC服务没有订阅机制，导致一个系统不清楚都有哪些调用者，更别说调用者的项目负责人信息，涉及到版本变更，就很难通知到位
• 代码提交日志很随意，经常看不出变更原因或背景
• 入职一来，就一次团建，整个公司的。部门的并没有看到
• 领导权力斗争吧，之前想要自己重新搭建基础服务和平台，折腾了2个月，后面还是妥协了，继续使用旧的基础服务和平台
• 框架太老，Spring还是3.x
• 上线流程，还有可以提前审批，或者解耦的地方。

好的方面是：

• 监控告警平台（基于cat改造）
• 线上日志系统（基于ELK）
• 网络隔离（测试环境和生产环境隔离，以及其他隔离）
• 一些之前工作没有使用过的技术：HBase、MQ、配置中心、netty（用于推送、rpc服务）、hessian（老的rpc技术）、调度系统、基于客户端的分库分表、fastFDS（分布式文件存储）等等，对我来说都是新鲜的，值得学习研究的

关于技术

• 项目使用到的配置文件要定期清理，移除无用配置，对于一些无法直接看出用途的配置，增加相关注释，提供参考文档或使用说明
• 增加项目的readme.txt文件，介绍项目整体的代码结构，记录一些关键信息或重要变更
• 代码提交记录尽量提供有用信息，比如：修改原因，背景说明等等
• 注意使用连接池或者复用连接，避免导致连接资源耗尽，接口响应慢等问题
• 日志不要随便打或拷贝，要打的有意义，也要打对信息
• 代码语义化，有些代码完全不清楚设计意图或实现的需求
• 模板代码提取，避免到处写类似代码（是的，有些重复代码，IDE还没那么智能识别）
• 代码要有一定的分包策略，体现模块和抽象，提升代码复用的便利性
• 学会查看异常堆栈，有遇到同事不会查看最原始异常（也就是报错的根本原因）的，也是惊呆了