架构学习分享:软件架构设计的三大原则

作为一个程序员,需要不断的学习、成长,丰富自己,提升自身价值。

软件架构学习不一定是想成为架构师才去学习,哪怕是一个普通的程序员,也应该学习软件架构相关知识,这样可以增加对开发的理解。

我之前有看过李运华老师的《从零开始学架构》,受益匪浅。这里我结合自己的理解给大家分享软件架构设计的三大原则:合适原则、简单原则、演化原则。

合适原则:

原则宣言:“合适优于业界领先”

现在互联网时代,技术的迭代非常快。很多架构师在设计架构的时候的希望用更新的技术来进行设计,以期望达到更好的效果。

但是,更新的技术往往不是最优的选择,哪怕新技术的效果很卓越。新技术带来了更好的效果的同时,也可能还有很多问题,比如:不够稳定,社区不够活跃,文档不够丰富,还有很多BUG等等问题。而这些对公司来说,都需要消耗时间、人力和金钱。

对于架构师而言,不是一定要设计出最牛逼的架构,而是要结合当前环境,公司成本设计出最合适最合理的架构方案。基于这种情况·,选择不那么新,但是系统稳定,社区活跃,文档丰富的技术来进行架构设计显然要合适合理得多。

简单原则:

原则宣言:“简单优于复杂”

做程序员的朋友们应该都有过类似的情况,当接到某个需求时,明明可以很简单的搞出来,偏偏想搞一个复杂一点的来展现自己的技术,我也有过这种情况,哈哈哈。

而架构师,我估计这种情况也存在。但是不管是开发还是做架构,我们都要明白,我们的最终目的(或者说是公司的目的)是什么,那就是更高效更低成本得解决问题。因为我们(公司)都是很现实的,是要赚钱的,那就必须考虑成本。特别是对于架构而言,因为架构是“房屋的框架”,开发都是基于架构设计开发的。架构复杂度每增加1分,开发的复杂度可能就会增加10分,对了,开发完成后还需要考虑运维的成本。

所以,架构设计在满足高可用、高性能、高扩展等等的前提下,一定要尽量简单。

演化原则:

原则宣言:“演化优于一步到位”

我觉得这个原则不只是适用于架构设计,还适用于产品设计。

再牛逼的架构师或者产品经理都不可能一步登天,一下子就设计出完美的架构和产品。

而事实上,优秀的架构和产品都是一步一步迭代出来的。比如:我们每天都在使用的微信,微信2011年推出至今,已经十年了,但是在十年前推出的微信和现在的微信天差地别,因为微信这十年一直在根据用户的使用情况和市场的发展等因素做着更新迭代,以满足用户使用。

而产品的不断迭代更加说明了产品活跃的生命力。如果产品不迭代了,那么在这高速发展的社会下,将很快就会被淘汰掉。

产品如此,架构设计也一样,架构设计也需要根据技术的发展,用户量的增大,业务的扩展进行不断地迭代升级,最终演化成优秀的架构。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
前言 客户需求重于个人简历 简化根本复杂性,消除偶发复杂性 关键问题可能不是出在技术上 以沟通为中心,坚持简明清晰的表达方式和开明的领导风格 架构决定性能 分析客户需求背后的意义 起立发言 故障终究会发生 我们常常忽略了自己在谈判 量化需求 一行代码比五百行架构说明更有价值 不存在放之四海皆准的解决方案 提前关注性能问题 架构设计要平衡兼顾多方需求 草率提交任务是不负责任的行为 不要在一棵树上吊死 业务目标至上 先确保解决方案简单可用,再考虑通用性和复用性 架构师应该亲力亲为 持续集成 避免进度调整失误 取舍的艺术 打造数据库堡垒 重视不确定性 不要轻易放过不起眼的问题 让大家学会复用 架构里没有大写的“I” 使用“一千英尺高”的视图 先尝试后决策 掌握业务领域知识 程序设计是一种设计 让开发人员自己做主 时间改变一切 设立软件架构专业为时尚早 控制项目规模 架构师不是演员,是管家 软件架构的道德责任 摩天大厦不可伸缩 混合开发的时代已经来临 性能至上 留意架构图里的空白区域 学习软件专业的行话 具体情境决定一切 侏儒、精灵、巫师和国王 向建筑师学习 避免重复 欢迎来到现实世界 仔细观察,别试图控制一切 架构师好比两面神 架构师当聚焦于边界和接口 助力开发团队 记录决策理由 挑战假设尤其是你自己的 分享知识和经验 模式病 不要滥用架构隐喻 关注应用程序的支持和维护 有舍才有得 先考虑原则、公理和类比再考虑个人意见和口味 从“可行走骨架”开始开发应用 数据是核心 确保简单问题有简单的解 架构师首先是开发人员 根据投资回报率(ROI)进行决策 一切软件系统都是遗留系统 起码要有两个可选的解决方案 理解变化的影响 你不能不了解硬件 现 在走捷径,将来付利息 不要追求“完美”,“足够好”就行 小心“好主意” 内容为王 对商业方,架构师要避免愤世嫉俗 拉伸关键维度,发现设计中的不足 架构师要以自己的编程能力为依托 命名要恰如其分 稳定的问题才能产生高质量的解决方案 天道酬勤 对决策负责 弃聪明,求质朴 精心选择有效技术,绝不轻易抛弃 客户的客户才是你的客户! 事物发展总会出人意料 选择彼此间可协调工作的框架 着重强调项目的商业价值 不仅仅只控制代码,也要控制数据 偿还技术债务 不要急于求解 打造上手(Zuhanden)的系统 找到并留住富有激情的问题解决者 软件并非真实的存在 学习新语言 没有永不过时的解决方案 用户接受度问题 清汤的重要启示 对最终用户而言,界面就是系统 优秀软件不是构建出来的,而是培育起来的 索引

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值