七月比之前更加忙碌，但是却是充实的，七月初又折腾了一把，几个地区辗转劳顿，之后码到天昏地暗，几个项目中来回切换思路，在书写细节上，以及项目的架构和模块的组织上都略有收获。
有的时候，前端把后端拖的进度追回来，还是蛮有成就感的。
业务中使用的一些新的开发方式扩展了一些思实现思路，迭代中也想明白了一些事情，记录一些琐碎的，具体的东西，等项目都到维护阶段再补上吧。
很有意思的是，项目的类型和状态都各不相同：
- 有访问数量很平均，但是用量巨大的页面；
- 也有加载基数吓人的全网插件；
- 还有平时没有什么访问量，但是可能某些时段会有类似秒杀行为的页面；
- 当然，也有一些访问量一年加起来都不到之前这些的零头的系统。
虽然类型不同，但是每个页面/应用的注意重点却很相似：
- 首先是高可用，前后端分离，或者准备打底数据做风险预案，语法细节和书写风格其实无所谓的，经过编译，会变成统一风格的程序代码，而且在编译过程（如果你有最低追求，书写的时候也请开着lint，并配置自己合适的风格）；
- 然后是可维护，如果项目不是一次性的，或者说，还有继续开发使用的可能，那么一定不能写不可或者不便于扩展的逻辑上去，这个在开始准备项目结构的时候，需要想清楚再做，当然，一次性想好是可遇不可求的，而且在执行的过程中，一定会有新的需求，以及根据环境和时间做出的最优抉择，这个很有意思，如果项目是生命周期比较长的，或者是遗留问题代码比较严重的，要考虑如何吃掉问题，并减少对业务的影响；
- 接着是针对特点，进行重点实现，在基础实现之后，针对页面更偏重细节展示，还是整体功能可用方面，做偏重的修饰。
- 在进行当中，会有一个制约因素，就是时间，项目刚开始的时候，时间宽裕，应当先对需求分解，制定可以实现的技术方案，并且分期；
- 搭建基础demo，和自动化项目环境，有的时候或许会浪费你一些时间，但是如果产出的工具和模式可以复用，那么就是值得的，当然也要看具体的情况；
- 完成下一步细节的时候，这个时候要多进行沟通，但是请不要一个一个问题抛出去，把问题push到一个array里，然后concat一下，再发给别人，沟通会高效的多，除非有串行无法调节的问题，否则进行异步先完成；
- 最后联调的时候，技巧性的打日志和下断点可以提高解决问题的速度，当然，最稳妥的方式，还是看代码实现。
先写到这里，继续写代码了。
纸上得来终觉浅，绝知此事要躬行，就是这个道理吧。
–此致–
