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

前后端架构

https://12factor.net/zh_cn/

-OCP: (开闭原则)吗 。 一个好的设计,对扩展应该是开放的,对修改应该是关闭的。 一个优秀的框架需要对分工提供良好的支持,每个人都可以先从一些简单任务开始,逐步的从修改一个文件扩大到修改一个目录再到独立实现一个特性。

前后端架构之框架选型

没有选择是痛苦的,有太多的选择却更加痛苦。而后者正是目前前端领域的真实写照。新的框架层出不穷:

  • 它难吗?
  • 它写得快吗?
  • 可维护性怎样?
  • 运行性能如何?
  • 社区如何?
  • 前景怎样?
  • 好就业吗?
  • 好招人吗?
  • 组建团队容易吗?

*每一个框架都得评估数不清的问题,直到耗光你的精力。这种困境,被称为“布利丹的驴子” * --

  • -为什么会有这样的东西出现?
  • -它解决什么问题?
  • -怎么解决?
  • -它的缺点是什么?
  • -它带来什么新的问题?

技术架构

MySQL读写分离、负载均衡
mq 、 搜索、个性推荐

运维、监控

分布式服务框架的治理、RPC协议、长短连接、路由设计、容错、流控、灰度、降级、一致性、可靠性。

团队、培训 等

最后聊一下关于技术的组织架构,这并不是讨论架构师岗位的范畴... 但随着业务发展,除了交流能力、协调等能力之外,组织的架构能力尤其重要,组织的划分会决定整个团队的效率,如:

  • -什么时候组建架构师团队?
  • -架构师跟项目还是独立成部?
  • -不同职能是否垂直管理还是按功能团队组织?
  • -是否需要成立技术支持部门来应对干扰和收集问题?
  • -是否需要PMO?
  • -业务高速发展,大量进人时,组织架构上怎么快速消化?

跟技术架构一样,没有标准范式,只有根据不同业务场景而变,在不同公司、行业、特别是不同的发展阶段,对组织方式的要求也不一样,有些甚至是反模式的,但是如果有效,也是需要阶段性执行。

【etc】 编程领域,创新无处不在。但对一个工程团队来说,最难得的是标准。标准意味着:

  • 招人容易。因为标准的东西会的人最多,而且人们愿意学它 —— 因为知道学了就不会浪费。
  • 养人容易。因为网上有很多教程可用,即使不得已自己做教程,性价比也是最高的。
  • 换人容易。标准就意味着不是私有技术,一个人离开了,就能用另一个人补上,而不会出现长期空缺,影响业务。

Subscribe to coderange

? We hate spams as much as you do.
You can unsubscribe with one click.