在深圳生活与工作已一月有余，在此期间学到了四件事：
- Done is better than perfect
- 预估排期应考虑多重因素
- 说到做到，让对方信任自己
- 分析清楚再动手
有时候针对某些需求，需求方并不要求尽善尽美，而是希望快速完成最小可用版本并持续迭代，至于样式以及交互是否优秀，需求方在早期阶段并不关心。否则在时间比较紧的情况下，自作聪明，用了大量时间去处理边际问题，这在需求方看来是愚蠢的，因此 Done is better than perfect。
同样的，在进行需求排期时，不能仅考虑自己的开发时间。加入团队后一周，自己负责开发小程序的一个独立功能模块，在排期时，尽管 xx 提醒我可以多加一些时间，但我依旧填写了 5 天。
我觉得这个时间够用了。过去独立开发中大型项目，使用 JS 栈可以较好的满足大部分需求，前后端通吃，极少延期。但是加入团队后，完成一个项目需要多方配合：代码审查、前后端联调、UI 检查等。
于是，在实际处理该需求时，周一周二用了接近两天时间把上周的遗留问题处理掉了，周三开始新功能开发，到了第二周的周二完成了最小可用版本，但该版本代码耦合，不易管理且有逻辑问题；除此之外，还需要 xx 进行代码审查，在修正某些语法、风格以及逻辑上，用了一定的不太乐观的时间；最后，在与服务端联调时，接口若有异常，则服务端就需要时间进行修正。
显而易见的，最终从开发到上线的时间远大于 5 天。如果完不成，那就不要答应，否则给了对方预期，结果却没完成，对方心理落差会增大，久而久之对方如何信任自己呢？
在该功能上线后，由于核心逻辑不清晰、代码过于耦合，我便在 xx 的建议下为核心功能整理了一份时序图。果真，参考时序图重构代码思路异常清晰、重构非常快速。
另外还有两点感悟：
1、在有限的时间内做有效率的事情；
2、唯手熟尔；
在工作中偶尔遇到过解决某些问题时状态不佳却又很想搞定的情况，尽管知道可能休息下再去解决，或许答案就在眼前，但自己偏偏执意要搞定它，结果用了很多时间却依旧无果。
在 xx 审查代码时，会给出一些思路或纠正某些问题，其中有些技巧或思路一看就知道是怎么回事，但在自己开发过程中却没想到。无他，唯手熟尔。
上方内容是在回郑州的飞机上整理的，离家一月有余，也该回去看看了。有意思的是，大学四年期间，尽管回家只需 30 分钟，但通常两三个月也没想过要回去。现在离家在外，却暗暗地下决心无论再忙，也要趁着周末定期回去。幸运的是，团队提供一定时长的远程工作机会，这样就可以多待一些时日了。
当然，远程的前提是自己要取得团队的信任。方法也很纯粹：言而有信、说到做到，用实力证明自己，做一个尽可能靠谱的人。
