时间：20170824
坐标：北京
天气：晴
手上的项目做了快一个月了，遇到了各种问题，有些是新遇到的，一些则是之前存在，一直没有解决，今天要聊的话题是一个已存在很久的问题。
在学校做过几个小型项目，技术难度不大遇到过几次难的项目，都被砸手里了，不了了之，原因都一样，项目开始一直纠结于技术选型，迟迟没有着手做，项目没有合理的排期，或者有了排期，没有按照排期严格的执行，导致最后没能完成。这也导致了后面做项目，面对排期都会十分恐惧。
这次的环境不同，工作中，必须给出排期，并且严格按排期执行，规定时间做不完，需要承担相应责任，甚至可能丢掉工作，不再是之前在学校里，几个同学间做着玩的场景。这一点在之前我也提到过。
因为项目后期还需要维护，我首先考虑到是项目的可维护性，面对项目的脚手架选择犯了难，挑来挑去最后选了 React 官方的脚手架，目前来说问题较少，应用广泛，社区较为完善。缺点是相对于团队内部同事定制的脚手架，需要配置的项比较多，不过我是在项目搭建好之后才知道团队有现有的脚手架……
第二次迟疑是在技术选型，在我看了好几天的 Redux 才勉强看懂原理之后，才发现同组的兄弟姐妹都在用 MobX，我又重新开始看 MobX，幸好相对于 Redux 更容易上手，否则一期提测肯定会被 Delay。
第三次迟疑是在代码组织结构上，开始实现之前考虑的都是最完美的解决方案，例如元数据 Data 和 展示数据 showData 之间可以通过一个 make() 方法进行转换，但实现时，会发现 Data 数据结构非常复杂，通过 make() 方式转换代价比较大， make() 的内容会非常复杂，最后数据的转换被放在每次数据获取以及数据更新时。
第四次迟疑是，面对数据逻辑整理不清晰时。七个模块的逻辑想不通，不知道如何下手，最后发现考虑的太久已经浪费了很长时间，无奈之下，把七个模块拆分解决，却发现实现非常方便，容易解决。
面对选型，没有最完美的解决方案，如果是高手，熟悉多种技术，可以在项目中应用相对最优解，但对于这种急于解决问题而且还需要花费时间接触新知识的场景而言，使用业内广泛使用且轻量化的技术则是更好的选择。面对结构组织，新手没有足够的经验，可以借鉴周边已有项目，进行参考，对于选型以及结构，没有最完美，只有相对而言最合适，当你还在纠结选型的完美与否时，别人已经又写完一个组件了。面对代码实现考虑不清楚，不妨先写 demo 验证猜想，动手实现会带来新的灵感。
目前来说，一切进展顺利对我而言是最好的消息。
