这一周,我们上课看了梦想改造家,了解了架构师的作用,了解了软件架构
- 根据要解决的问题,对目标系统的边界进行界定。
- 并对目标系统按某个原则的进行切分。切分的原则,要便于不同的角色,对切分出来的部分,并行或串行开展工作,一般并行才能减少时间。
- 并对这些切分出来的部分,设立沟通机制。
- 根据 3,使得这些部分之间能够进行有机的联系,合并组装成为一个整体,完成目标系统的所有工作。
同样这个思考可以展开到其他的行业,比如企业的架构,国家的架构,组织架构,音乐架构,色彩架构,软件架构等等。套用三国演义的一句话,合久必分,分久必合。架构实际上就是指人们根据自己对世界的认识,为解决某个问题,主动地、有目的地去识别问题,并进行分解、合并,解决这个问题的实践活动。架构的产出物,自然就是对问题的分析,以及解决问题的方案:包括拆分的原则以及理由,沟通合并的原则以及理由,以及拆分,拆分出来的各个部分和合并所对应的角色和所需要的核心能力等。
在每个人都必须自己完成所有生活必须品的生产的时候,是没有架构的(当然在个人来讲,同一时刻只能做有限的事情,在时间上还是可能会产生架构的)。一旦产生的分工,就把所有的事情,切分成由不同角色的人来完成,最后再通过交易,使得每个个体都拥有生活必须品,而不需要每个个体做所有的事情,只需要每个个体做好自己擅长的事情,并具备一定的交易能力即可。
还有学习了架构指标架构指标 | 子项 | 描述 | 策略 | 致命阶段 | 备注 |
可用性 | ISO 9241-11 定义:产品在特定使用环境下为特定用户用于特定用途时所具有的有效性、效率和用户主观满意度。产品是否容易上手,用户能否完成任务,效率如何,以及这过程中用户的主观感受可好,是从用户的角度来看产品的质量。可用性好意味着产品质量高,是企业的核心竞争力。 | 尽量让系统和功能相匹配、尽量简洁而自然、 做好异常预防和异常处理、提供相关帮助文档、及时获取有价值的反馈 | |||
有效性 | 功能可用,出错少 | 严格的功能测试,降低bug率 | 初期 | ||
效率 | 系统反应速度快 | 使用主流技术、优化数据链路、做性能测试 | 中期 | ||
用户主观满意度 | 和用户在一起,忌闭门造车 | 用户调研,小版本内测 | 初期 | ||
可靠性 | 软件在一个运行周期内、在一定的边缘条件下,软件的出错机率、性能劣化趋势等,又称稳定性。按业务量评估,在可预见的用户数、并发数、使用次数边界条件下,系统运行良好。 | 服务器承载容量设计、技术框架选型、边界测试 | |||
响应时长 | 服务器、接口、网页等的响应时长在边界内保持良好 | 系统构成尽量简洁、所含各项技术细节都可靠 | 中期 | ||
功能异常 | 产品不经常闪退、点不动、拒绝服务 | 系统构成尽量简洁、所含各项技术细节都可靠 | 中期 | ||
可维护性 | 当系统出现问题时,快速定位并解决问题;预留足够的监控统计抓手,易于监控和统计;代码是否容易被人理解,是否容易修改和增强功能。 可维护性和可复用性、可扩展性等有交叉的地方。构建可维护性好的代码,对企业的长期发展非常重要。 |
技术框架、程序结构、功能注释、运行日志、开发文档、发展预判预留、符合标准规范 | |||
维护成本 | 问题定位处理成本 | 功能注释、开发文档、运行日志 | 中期 | ||
二次开发成本 | 代码修改增强成本 | 技术框架、程序结构、功能注释、开发文档 | 后期 | ||
可统计性 | 数据可统计性 | 监控抓手预判预留 | 中期 | ||
可监控性 | 异常可监控性 | 监控脚本等手段 | 后期 | ||
安全性 | |||||
服务器安全 | 服务器操作系统、网络等的安全 | 操作系统和网络等安全加固 | 中期 | ||
数据库安全 | 数据库数据安全 | 数据库安全加固、程序防止sql注入 | 中期 | ||
数据传输安全 | 数据传输过程的安全防护 | 用户数据严格过滤、敏感数据加密传输、HTTPS | 中期 | ||
交易安全 | 涉及交易的功能重点保障 | 重点功能全面加固 | 中期 |