项目破题，时时牢记
项目之初，需求不明，死线（dead line）已定。
"压力山大，谋定而后动", 基于业务，权衡利弊，发现风险，积极沟通，设计方案而后动。
需求改动频繁，排期总是被压缩。
需求变更通常有三种原因：
- 源于竞争态势的变化，战略的快速调整。
- 敏捷的产品开发实践，小步快跑，渐进明细。
- 产品设计人员没有想清楚。
眼光放在项目目标，思考自己能做些什么。大家需要的不是你的抱怨，而是你的“补位”
总是缺人手，加班不断，且代码质量差。
- 项目确实过于紧急，基于目前的人数，无论什么样的开发者都会吃不消。
- 业务频率正常，团队生产力低下
对于1, 暴露的问题在于内和外
内： 对业务的增量没有充分预估，做好人力储备，或技术架构对人力内调不支持。
外： 缺乏跨团队借调人力的能力。
对于2，需要定位原因，是前端团队自身工作流问题，还是与其它团队配合问题。分而治之。此时最好不要再抱怨“缺人手”，以免更加被人“不看好”。
前后端联调环境搭建耗时，且定位问题麻烦，导致联调时间不可控。
UI过于纠结界面细节，导致交付时间不可控。
- 精益求精永远是没错的，但还是要从项目的紧急程度来看问题。好的FE需要一定的沟通能力。
- FE需要协同UI，UE 制定组件化视觉规范。
移动端，设备多，兼容问题多，导致自测时间不可控。
- 移动时代虽然让FE脱离了恼人的各种IE，却又带来了更多的平台的兼容问题。我们希望通过一个个可复用，经过测试的组件来减少日常开发的跨终端的测试。
- 试想，如果每次开发，80%以上的模块都是复用可靠且兼容的组件开发，那么这些兼容性问题，将会随着组件库的丰富，越来越少。
领导说，PM说，UI说，UE说。信息不对等，到底听谁说？
毫无疑问，无论“是谁说”，最后都得听领导的，别问我为什么！（但又不能事事都问领导，轻重请自行把握）
基于历史原因，总是无法采用更恰当的技术方案，导致团队技术脱节。
- 要解决这个问题，首先我们必须承认，根本不存在完美的技术方案和架构。我们需要拥抱变化，为向未来的技术和架构过渡做好准备。
渐进式架构与技术债务
- 基于团队的不同形态设计适合不同阶段的架构与技术堆栈。同时，需要以开放的心态看待
- "技术债务"，就像我们通常不喜欢欠债，但有时候贷款也是为了创造更大的利润。关键在于管控和权衡。
何时可以启用新技术与架构？
- 对于不重要不紧急的产品
- 如果没有，就在组内做技术驱动的技术产品，比如团队网站，以此来打磨新技术或架构。然后选择一个恰当的时机在新项目里推行。
一边加班，一边吐槽，一边被吐槽。
满满的负能量，自以为嘴上爽了，你可知被你吐槽的人是怎样看待你？你又何曾把他看做是你团队里面的"自己人"?
走人了，换了个团队，问题依旧。
是的，当你带着抱怨离开这个团队，你可能会发现又跳进了另一个坑。
其实，也许你原本可以改变，但你选择了放弃。
当你能为团队做更多事，更多补位，那你的价值也就提升了。
而"走"往往只是一种无奈的回避。