七月比之前更加忙碌,但是却是充实的,七月初又折腾了一把,几个地区辗转劳顿,之后码到天昏地暗,几个项目中来回切换思路,在书写细节上,以及项目的架构和模块的组织上都略有收获。

有的时候,前端把后端拖的进度追回来,还是蛮有成就感的。

业务中使用的一些新的开发方式扩展了一些思实现思路,迭代中也想明白了一些事情,记录一些琐碎的,具体的东西,等项目都到维护阶段再补上吧。

很有意思的是,项目的类型和状态都各不相同:

  • 有访问数量很平均,但是用量巨大的页面;
  • 也有加载基数吓人的全网插件;
  • 还有平时没有什么访问量,但是可能某些时段会有类似秒杀行为的页面;
  • 当然,也有一些访问量一年加起来都不到之前这些的零头的系统。

虽然类型不同,但是每个页面/应用的注意重点却很相似:

  • 首先是高可用,前后端分离,或者准备打底数据做风险预案,语法细节和书写风格其实无所谓的,经过编译,会变成统一风格的程序代码,而且在编译过程(如果你有最低追求,书写的时候也请开着lint,并配置自己合适的风格);
  • 然后是可维护,如果项目不是一次性的,或者说,还有继续开发使用的可能,那么一定不能写不可或者不便于扩展的逻辑上去,这个在开始准备项目结构的时候,需要想清楚再做,当然,一次性想好是可遇不可求的,而且在执行的过程中,一定会有新的需求,以及根据环境和时间做出的最优抉择,这个很有意思,如果项目是生命周期比较长的,或者是遗留问题代码比较严重的,要考虑如何吃掉问题,并减少对业务的影响;
  • 接着是针对特点,进行重点实现,在基础实现之后,针对页面更偏重细节展示,还是整体功能可用方面,做偏重的修饰。
    • 在进行当中,会有一个制约因素,就是时间,项目刚开始的时候,时间宽裕,应当先对需求分解,制定可以实现的技术方案,并且分期;
    • 搭建基础demo,和自动化项目环境,有的时候或许会浪费你一些时间,但是如果产出的工具和模式可以复用,那么就是值得的,当然也要看具体的情况;
    • 完成下一步细节的时候,这个时候要多进行沟通,但是请不要一个一个问题抛出去,把问题push到一个array里,然后concat一下,再发给别人,沟通会高效的多,除非有串行无法调节的问题,否则进行异步先完成;
  • 最后联调的时候,技巧性的打日志和下断点可以提高解决问题的速度,当然,最稳妥的方式,还是看代码实现。

先写到这里,继续写代码了。

纸上得来终觉浅,绝知此事要躬行,就是这个道理吧。

–此致–

IMG_20140628_165120