B4 You Start a New Project ...
一个开发项目从立项到结束需要做许多事情，需求分析、梳理抽象、系统/模块划分、服务化、数据结构设计、前后端架构、技术架构、运维、监控等等，它涉及抽象、架构、设计、评估、攻关、调优、团队培训等等。
生命周期
开始的阶段，我们需要非常快速的建立原型，让它跑起来，引入最终用户来试用，这个时候，挑战来自开发速度以及可复用资产。
项目管理
,
信息保密
不能全部开发人员都能拿到整个项目的代码和数据库设计
商业智能(BI)
为未来的商业智能团队打好基础，项目一上线就做好数据采集。
Quality Control (both product level & code level)
,
需求分析、梳理抽象
但是在非开发人员的群体眼里，业务架构又是如此重要，重要到他们根本不关心你的技术架构是什么样，除了系统不要出故障、不能太慢之外，他们关心的是：
-需要有什么样的系统/模块/服务来更有效率支撑业务？
-系统/模块/服务流程是否顺畅？
-能否适应业务的快速变化？
-新的活动/规则出现是否尽量少开发，甚至不用开发？
服务化 之 微服务架构
https://martinfowler.com/articles/microservices.html
数据结构设计
http://en.tekstenuitleg.net/articles/software/database-design-tutorial/intro.html
前后端架构
-OCP: (开闭原则)吗 。 一个好的设计，对扩展应该是开放的，对修改应该是关闭的。
一个优秀的框架需要对分工提供良好的支持，每个人都可以先从一些简单任务开始，逐步的从修改一个文件扩大到修改一个目录再到独立实现一个特性。
前后端架构之框架选型
没有选择是痛苦的，有太多的选择却更加痛苦。而后者正是目前前端领域的真实写照。新的框架层出不穷：
- 它难吗？
- 它写得快吗？
- 可维护性怎样？
- 运行性能如何？
- 社区如何？
- 前景怎样？
- 好就业吗？
- 好招人吗？
- 组建团队容易吗？
*每一个框架都得评估数不清的问题，直到耗光你的精力。这种困境，被称为“布利丹的驴子” *
- -为什么会有这样的东西出现？
- -它解决什么问题？
- -怎么解决？
- -它的缺点是什么？
- -它带来什么新的问题？
技术架构
MySQL读写分离、负载均衡
mq 、 搜索、个性推荐
运维、监控
分布式服务框架的治理、RPC协议、长短连接、路由设计、容错、流控、灰度、降级、一致性、可靠性。
团队、培训 等
最后聊一下关于技术的组织架构，这并不是讨论架构师岗位的范畴... 但随着业务发展，除了交流能力、协调等能力之外，组织的架构能力尤其重要，组织的划分会决定整个团队的效率，如：
- -什么时候组建架构师团队？
- -架构师跟项目还是独立成部？
- -不同职能是否垂直管理还是按功能团队组织？
- -是否需要成立技术支持部门来应对干扰和收集问题？
- -是否需要PMO？
- -业务高速发展，大量进人时，组织架构上怎么快速消化？
跟技术架构一样，没有标准范式，只有根据不同业务场景而变，在不同公司、行业、特别是不同的发展阶段，对组织方式的要求也不一样，有些甚至是反模式的，但是如果有效，也是需要阶段性执行。
【etc】
编程领域，创新无处不在。但对一个工程团队来说，最难得的是标准。标准意味着：
- 招人容易。因为标准的东西会的人最多，而且人们愿意学它 —— 因为知道学了就不会浪费。
- 养人容易。因为网上有很多教程可用，即使不得已自己做教程，性价比也是最高的。
- 换人容易。标准就意味着不是私有技术，一个人离开了，就能用另一个人补上，而不会出现长期空缺，影响业务。