程序员比较好的素养，这个“好”，其实不太明确。最近看到了各大互联网场的不断裁员，又欣赏到了阿里云崩溃、滴滴崩溃、腾讯视频崩溃的盛状。浏览脉脉的时候，看到一个帖子说，要提升自己的不可替代性，否则就要公司付出对应代价。这个不可替代性，不单单指的是技术很牛，没有其他人可以去解决这样的问题，还有一种情况是，自己写的代码，可维护性差，从而离开了自己，其他人就很难进行修改。简而言之，写出屎山代码，从而让其他人无法替代自己。
除了上述的辩证的“好”，还是要整理一下真正优质程序员应该有的素养与能力。
基本素养
- 会不会做需求分析？怎么理解问题的？
- 解决问题的思路是什么？想法如何？
- 会不会对基础的算法和数据结构灵活运用？
- 逐步理解业务，能够掌握业务。例如，查看平台数据产出情况时，发现上有数据出故障，那么就去了解上游任务因何失败。还有，有时间关注当前业务的上下游，串通整个业务。
- 深入了解业务，也可以通过这几个问题。项目当时的业务场景？个人负责的部门？为什么要这么做？做完后数据上有什么变化？项目中遇到了什么困难？整条链路是什么样的？
- 警惕关注点的退化，这会影响到学习的主观能动性。学生时代，可能还会学习从整体框架看待问题，但是工作几年后就不再关注整体性。
- 对项目额外的贡献/思考/积极性/归属感，让领导知道。怀才不遇才是最丢人的。
工程构建上
- 项目框架的设计能否满足需求，并且可以应对可能出现的需求变化。
- 程序是否易读，易维护。例如，必要的代码注释，合适的函数划分、目录划分等。（不过我发现我 leader 的代码也确实不写注释，当然也可能是代码能力好，一遍过，自己理解也容易）
- 重构代码的能力如何？
- 主动去测试自己的程序，无论是单元测试还是整体测试。相对来说，更推荐单元测试，debug 更方便。
- 有工程的概念，有发布流程的概念，敬畏生产环境。
- 代码最重要，紧接着文档，代码和文档保持一致性。
审视需求的能力
- 需求的背景是什么？
- 需求想要解决的问题是什么？
- 能不能换一种需求来实现这个问题？
- 能否简化一下需求？
审视需求，或许可以节约时间、简化开发。
想到了榜单评审中核对指标时，时不时会和产品讨论指标是否合理，来避免后续发现不合适更改需求与重新开发。
Reference：252
特殊场景需要培养的能力
- 对于互联网可能存在的开会多问题。养成做会议纪要的习惯，通过记录的方式来提高开会的效率。同时，也可以将开会当作一次讲座等，通过提炼重要的事项，保持自己的专注力。当然，如果工作过多导致精力不够，可以在开会时稍微摸鱼休息下。
一些通用的处理
- 学会拒绝 or 推迟任务。最近一段时间的工作，让我真的认识到工作是永远做不完的。几个方向的工作要同时进行，自己的时间和精力实在是不够用哇。
当前自己了解到的方法
- 能拒绝去做的任务，直接拒绝。
- 合理预估多任务并行时，多个任务总共的时间，将这个时间作为提供给对方的 DDL 时间。
- 同一类的任务一起处理，而不是有个任务来了就进行切换。来来回回切换任务体感不舒服。
- 判断各个任务的轻重缓急，也就是常说的四象限任务。
Thinking First：
- 如何将复杂的东西解藕、简化
- 如何写出更优雅的代码
- 思考未来可能的需求变化
- 思考未来可能的代码测试
- 思考未来可能的系统运维
除此之外，感觉有时候写代码的时候，需要将逻辑理顺+写下来，否则很容易写着写着就懵了。
上述这个非常正确！最近还是很容易没有思考全，导致改来改去的情况。