@
Gaays 感觉产品需求不清楚,后续迭代有浪费:是团队合作的常态问题,不同环境程度不同,本质是计划、沟通、工作方式、相关角色能力的问题。
这种就是提升你的影响力,不论是你带头,还是你能影响带头的人,至少是做到有效暴露问题(不是直接跟人家对喷)。这个是另外一些问题上的历练:能不能我们把问题聊清楚、能不能通过什么手段规范化版本迭代、等等。
在自己的实现手段方面,如果这个事情暂时不清楚,我建议在你的控制范围内,做最小化的补丁。这个时候的实现思路不能是“我要注意扩展性、健壮、抽象、优雅 xxxx”,而是“在不特别恶心的情况下把事情办了”。对恶心的 patch 代码做意图注释“因为这里和什么冲突了,所以只能 xxx”。间隔一段时间再总结重构,这时候你积累了很多理解,起码一次解决一大批问题。另外通过完成需求,积累自己的权威性;你的权威到位了,技术债小暴雷是你申请重构资源的机会,不要害怕技术债。总之一句话:不要过早优化。
另外我这个人提建议总是向正向提的,正向很辛苦,任何时候你都有 walk away 的权利。我写的内容是“如果你想要坚持,可能有什么方向”,而不是“这些是你应该坚持的理由”。