本周工作思考
- 对web端技术设计及评审的一些简单思考
- 项目开始前的技术设计及评审已经成为研发流程中的重要一环，从我们自身发展的角度，技术设计及评审的过程都是很重要，也是非常必要的。其实在研发过程中，我们或多或少受到CMMI，敏捷开发，面向对象开发，领域驱动等各类软件开发方法或者开发流程思想的综合影响，所以大家在写技术文档时思路和角度也不太相同，就目前的总体流程而言我们一直在持续改进，就是敏捷开发与持续交付 -> 总结反思改进 -> 敏捷开发与持续交付 这样的一个迭代式的开发到交付的闭环;
- 持续改进，提高过程效能的这个大的发展原则下，需要持续优化和细化核心流程，同时持续精简繁冗非必要流程，当前这个识别过程随着业务和组织的发展，长期看是动态的，阶段性上是稳定的，因为根本目标是通过优化过程，提高开发效能，在不同的发展阶段，公司的发展目标所有侧重，也会直接体现在研发过程的设计和优化上；
- 敏捷交付是一个大过程，它由很多的小流程和微流程组成，设计环节就是其中很重要的一环， 我们目前没有规范约束设计方面的的所有过程，只是在设计阶段做了一个里程碑的的环节，从内容上看，它可以包括需求确定之后的所有需要设计的内容，甚至可以包括关键需求分析和领域建模的内容，从实践角度来说，也推荐设计文档里可以包括需求分析，领域建模，对象分析，架构设计，功能设计，项目管理分析及安排等一系列需要在开发阶段前置的内容；因为项目的情况不同，所涉及的设计粒度和范围也是不同的，所以现阶段不太可能就设计内容和设计过程做太具体点的规范，但是我们需要持续的优化和丰富，以期形成可裁剪的标准化模板；同时我也知道在园艺设计上，有一种路线设计方法，在公园的路线规划上，期初先设计几条主干道，然后开放公园，后面根据人们走出来的路，规划建设其他辅路和游园路线，这方式是主干道规划 + 通幽小径自决的方式，这种方式有一定的优势，但不一定适合所有的公园；
- 目前的从我的角度观察，web端的技术设计文档存在有几个需要优化的问题
- 项目实现后的设计变更无法反应到最初的设计文档上
- 设计文档对新伙伴和Code Reviewer的说明作用不大
- 设计文档缺乏对工程能力沉淀的指导作用
现在的重点项目代码量一般比较大，涉及到大量css和html，实现细节繁博，从Code Review和后续迭代来看，技术文档有要努力达成3个重要目标：
1 作为未来业务和框架迭代的技术基础和指导，可以包含一些关键需求的分析及对未来可迭代方向的思考，以及当前设计的描述及其背后的逻辑推演过程等等
2 成为工程建设的素材来源和思考根基，可以包含一些工程上思考，是否有组件化的功能，需要提取哪些可复用的功能，可以使用哪些方法提升开发效率，测试效率等等；
3 成为个人和团队的技术产物的沉淀，可以包含一些该项目在技术选型上思考，以及同类项目，或者同Pod类似项目上的技术思考，或者业界同类功能的实现分析； - 技术评审不是设计的结束，设计伴随着项目的过程甚至是后续的迭代，开发过程中可能要随时更新或者修整之前的设计并尽可能的补充到技术文档上，现阶段我们项目类的技术文档，我建议追求精深简洁一些，数量上不必繁冗，对于长期的项目，比如i18n开发，搜索类，OTJ甚至可以用一篇文档持续更新，这样可以较好的保证设计思路的连贯性和完整性；
- 另外，技术文档不比代码，文档不是给机器看的，技术文档是纯给人看的，我们的目的是让别人更快的看懂，所以多考虑下别人的阅读体验和不同层次的技术理解能力及技术感受力