- 综合排序
- 最热优先
- 最新优先
- 来自专栏技术一号位指南(小诚信驿站)
【技术一号位指南🧭】谈谈我眼中的架构师思考原则
然而我们还得在碎片化的时间中保持自己的成长速度，这里面如果只是靠简单的碎片化知识，容易导致我们思维不够体系化，学习到的知识比较碎片化，所以我们需要形成系统学习的习惯、天思考-周思考-月思考的不断沉淀知识 1.6、管理结果-调研思考对于日常管理，需要有足够的输入和思考才可以进行结果输出，不然很容易被带偏和误导造成失误。 1.8、管理时间-提高效率如何管理时间1.9、管理视角-全局视野无论是作为工程师、架构师、团队Leader、高管、CXO，一定要基于当前的工作可以向上看、向下感的全局视野看待问题。 视角的思考-如何活成自己讨厌的人1.10、管理成长-四心齐备成长这个事情已经变成了终身成长，那么在我们整个生命不同阶段的过程中如何保持自己一直成长呢？我思考以后发现需要有三心准备。 如何管理项目、管理团队、管理不确定性1.12、管理本质-抽象破圈设计模式、架构模式不外乎涉及到高内聚/低耦合，抽象/平台/扩展设计，SOLID原则；采用简单的方案解决技术问题，不炫技，直到问题变复杂，不做过度设计
1.3K31编辑于 2023-05-26 - 来自专栏正则
架构师之路 - SOLID设计原则
SRP 单一职责原则 OCP 开闭原则 LSP 里氏替换原则 ISP 接口隔离原则 DIP 依赖反转原则 在架构之路上和代码设计上，我们一定要明白上面的几个原则，在这几个原则的指导下，才能设计出优良的架构 SRP 单一职责原则 SRP是五大原则里最容易被误解的一个，很多程序员根据SRP这个名字想当然的认为这个原则就是指：每个模块都应该只做一件事。 所以这个类违背了 单一职责原则 原则。 这个原则是软件设计，系统架构中非常重要的原则。 当学习完设计原则后，我发现依赖反转原则，其实是其他几个原则的综合，接口的设计保证了单一职责原则，依赖反转的部分实现也满足了开闭原则,通过抽象进行约束很大程度上也是一种里氏替换原则,接口的设计又实现各个接口的隔离
38410发布于 2021-09-04 - 来自专栏大数据架构师成长之路
数据架构师成长思考总结
建立中心 当我们接手一个业务需求、面对一项挑战的时候，应当先思考这个需求的核心目标是干嘛的。 （价值的维度） 一个团队接手某项业务或需求，其背后都会有思考：我们是期望借着这个业务打造一个平台，提升整体行业的表现；还是突击这个业务方向，占领局部的商业蓝海······ 接到一个需求时一定要思考更大层面这事的价值 整体思想是 MECE（Mutually Exclusive Collectively Exhaustive）原则，即相互独立，完全穷尽不重叠、不遗漏的分类。 指的是找出事情发生的内在逻辑，思考的时候可以逻辑顺序作为参考。 我们在思考、做事、成长时应当随时使用，对于梳理复杂问题、进行决策支撑都有很大好处。
88240发布于 2020-07-08 - 来自专栏芋道源码1024
架构师应该遵守的编程原则
KISS（Keep It Simple Stupid） KISS原则是英语 Keep It Simple, Stupid 的首字母缩略字，是一种归纳过的经验原则。 KISS 原则是指在设计当中应当注重简约的原则。 说明这个原则最好的实例，是约翰逊向一群设计喷射引擎飞机工程师提供了一些工具，他们所设计的机具，必须可由一名普通机械师只用这些工具修理。 另外相类似的概念也可作 KISS原则的起源。 最少意外原则：程序代码应尽可能的不要让阅读者感到意外。也就是说应该遵循编码规范和常见习惯，按照公认的习惯方式进行组织和命名，不符常规的编程动作应该尽可能的避免。 如何把Kiss原则应用到工作中？
43520编辑于 2022-08-29 - 来自专栏编程之禅
架构师内功心法之设计原则
一.架构师内功心法之设计原则 1.为什么要学习软件架构设计原则 1.1.课程目标 通过对节课内容的学习，了解设计原则的重要性。 掌握七大设计原则的具体内容。 Principle 里氏替换原则 第7章 Composite&Aggregate Reuse Principle 合成复用原则 1.3.1.开闭原则 定义 开闭原则（Open-Closed Principle 所谓的开闭，也正是对扩展和修改两个行为的一个原则。强调的是用抽象构建框架，用实现扩展细节。 开闭原则，是面向对象设计中最基础的设计原则。 我们在设计接口的时候，要多花时间去思考，要考虑业务模型，包括以后有可能发生变更 的地方还要做一些预判。所以，对于抽象，对业务模型的理解是非常重要的。 总结 接口隔离原则和单一职责原则区别？ 总结 多用聚合组合代替继承原则 1.4.设计原则总结 学习设计原则，学习设计模式的基础。
60330发布于 2020-08-12 - 来自专栏漫谈测试
测试架构师领导力的原则
测试架构师的领导力是建立在把握和执行的某些原则上---信任，认知，安全，清晰度等要素，如下图。 既然如此，架构师需要不同的视角来容纳他们。对某种解决方案的特定模型抽象出关键点，这是支撑该架构的主要技能。三、通过关系带来安全称为成功的测试架构师通常取决于你建立战略伙伴的能力。 尽管你能够作为架构师影响产品的认知，但你往往不是产品认知的拥有者。作为架构师，你要对产品的商业认知有彻底的了解。你最终负责将其转换为技术现实。 四、要身体力行，以身作则对于任何给定的项目，你期望团队的成员遵循某些原则，如果你期望团队透明，你的做法该对团队透明。透明化。见什么人说什么话。保持开放、诚实的胸襟。做事正直。 最棒的架构师有一些在其架构知识范围内的技能，所以有些时候“身体力行”在技术上本质也是如此。遵循这种原则，你就会从另一方面看待问题。
22810编辑于 2024-08-17 - 来自专栏开源社
Apache架构师的30条设计原则！
| 作者：Srinath | 编辑：Corrie | 来源：ImportSource Srinath 通过不懈的努力最终总结出了30条架构原则，他主张架构师的角色应该由开发团队本身去扮演，而不是专门有个架构师团队或部门 Srinath 认为架构师应该扮演的角色是一个引导者，讨论发起者，花草修建者，而不是定义者和构建者。 Srinath 为了解决团队内部的架构纷争和抉择，制定了以下30条原则，这些原则被成员们广泛认可，也成为了新手架构师的学习途径。 一个避免这种情况的好办法就是有一个原则列表，这个原则列表是被广泛接受的，这个列表是人们讨论问题的锚点，也是新手架构师学习的路径。 *部分图片来源于网络 ? ? 作者简介 / AUTHOR 本文作者叫 Srinath，是一位科学家，软件架构师，也是一名在分布式系统上工作的程序员。
38210发布于 2019-08-15 - 来自专栏架构之美
Apache 架构师总结的 30 条架构原则
Srinath 通过不懈的努力最终总结出了 30 条架构原则，他主张架构师的角色应该由开发团队本身去扮演，而不是专门有个架构师团队或部门。而不是专门有个架构师团队或部门。 Srinath 为了解决团队内部的架构纷争和抉择，制定了以下 30 条原则，这些原则被成员们广泛认可，也成为了新手架构师的学习途径。 拿你的代码来说，你想要写的简单且容易理解的话，你就需要花更多的时间去思考。原则 2：YAGNI(You aren’t gonna need it)：不要去搞一些不需要的东西，需要的时候再搞吧。 此原则是原则 5 的一个具体表现。点评:是否有站在用户的角度思考问题呢？是否是为了用新技术而用新技术？原则 7：设计和测试一个功能，尽可能的独立。当你做设计时，应该想想这一条。 一个避免这种情况的好办法就是有一个原则列表，这个原则列表是被广泛接受的，这个列表是人们讨论问题的锚点，也是新手架构师学习的路径。 作者：Srinath 来源：ImportSource
37820编辑于 2022-03-10 - 来自专栏Jimoer
架构师必须了解的30条设计原则
前言 众所周知，架构师的角色，更偏向于策划、而非指挥，塑造、而非支配，其存在的意义，在于引导大家讨论、而非自己主宰一切。 但是，具体应该如何执行呢？ 基本原则 原则1 KISS (Keep it simple,sutpid) 和保持每件事情都尽可能的简单，用最简单的解决方案来解决问题。 原则2 YAGNI（你不需要它）原则 ，只在需要时构建。 原则23 最好的产品应当不需要用户手册，用户应该一看就会用。 原则24 当你无法在两个选项之间做出决定时，请不要通过配置选项的方式来呈现问题。这会给用户和架构师带来麻烦。 总结 作为一个架构师，我们应该像园丁一样思考、塑造、策划和去除杂草而不是定义和构建。虽然在短期内，由一位架构师来制定架构的确既快捷又实惠。但是，从长远来看，团队的力量才是最强的。 所以想成为 一名优秀的架构师，还是需要长期的磨练以及时间的验证，当然随时保持学习的状态也是非常重要的。当你学会更多知识，你便会更清晰的解决各种复杂的架构问题。 来源：Java面试那些事儿
44630发布于 2019-11-26 - 来自专栏架构狂人
架构师必须掌握的架构设计原则
今天给大家分享下，架构师必须要熟练掌握的软件架构设计和组织原则。 架构师的价值就体现在这里，架构设计对于流量的增长要有提前量。 非核心则购买 如果不是你最擅长，也提供不了差异化的竞争优势则直接购买。 Underpinning DevOps)，我认为也是系统改进提升的一般性原理，见下图： 原理一：系统思考 (System Thinking) 对于以开发为导向的组织而言，他们的能力已不仅仅只是生产软件 总结 尽管上述原则对架构师而言具有深远的指导意义，但在实际工作中，根据业务、时间、资源和团队情况灵活应用它们才能收到更好的效果。 这些原则并非僵化的规则，有时候甚至会被违反，不过要注意，这样的做法通常都有相应的成本，架构师需要在意并及时变通以弥补成本带来的损失。
58320编辑于 2023-08-16 - 来自专栏Java技术栈
架构师必须掌握的 10 条设计原则
01 遵循单一职责原则 函数是程序员的工具中最重要的抽象形式。它们能更多地被重复使用，你需要编写的代码就越少，代码也因此变得更可靠。较小的函数遵循单一职责原则更有可能被重复使用。 06 对模块应用良好的原则 寻找机会将软件项目分解成更小的模块（例如库和应用程序），以促进模块级别的重用。 对于模块，应该遵循的一些关键原则是： 1.尽可能减少依赖 2.每个项目应该有一个明确的职责 3.不要重复自身 你应该努力使你的项目保持小巧和明确。 08 将测试作为设计和开发的一部分 我不是测试驱动开发的坚定分子，但开始编码时先编写测试代码会使得代码十分自然地遵循许多指导原则。这也有助于尽早发现错误。 你还知道别的设计原则吗？欢迎留言！ （完）
56510发布于 2018-09-29 - 来自专栏java思维导图
架构师必须掌握的 10 条设计原则
01 遵循单一职责原则 函数是程序员的工具中最重要的抽象形式。它们能更多地被重复使用，你需要编写的代码就越少，代码也因此变得更可靠。较小的函数遵循单一职责原则更有可能被重复使用。 点击这里查看 6 大设计原则。 06 对模块应用良好的原则 寻找机会将软件项目分解成更小的模块（例如库和应用程序），以促进模块级别的重用。 对于模块，应该遵循的一些关键原则是： 1.尽可能减少依赖 2.每个项目应该有一个明确的职责 3.不要重复自身 你应该努力使你的项目保持小巧和明确。 08 将测试作为设计和开发的一部分 我不是测试驱动开发的坚定分子，但开始编码时先编写测试代码会使得代码十分自然地遵循许多指导原则。这也有助于尽早发现错误。 你还知道别的设计原则吗？欢迎留言！
43330发布于 2018-10-24 - 来自专栏四火的唠叨
思考、学习新技术的原则和方式
然而…… 他们却缺乏这样一种能力——思考。 欠缺思考容易导致这样的现象： 不会做设计。 和少数所谓的 “架构师” 接触过，他们 “只懂业务，不懂技术”，这样设计出来的系统只能满足功能性需求；而论坛上的一些具体问题的讨论话题，则暴露出一些跟帖讨论者 “只谈技术，不提业务”，譬如 “XXX 大容量的解决方案 当然，如果你觉得做软件设计的人可以不熟悉编码、架构师可以不首先是一名高级程序员，那我们也没有什么可谈了 :)。 如果你会学习，你可以成长得很快；如果你不会思考，你永远只能跟在别人后面。 在新技术的学习上我认为也应当多思考，不同的人有不同的学习动机。在非外界所迫的情况下，对于新技术的学习，我的观点可以概括为： 它要解决什么问题，就是所谓的问题域，是我关心的吗？ 它的实现和带来的效果上看，有没有很有意思的思路，是值得借鉴和思考的？ 这是最难讲的一个问题。
34810编辑于 2022-07-15 - 来自专栏JavaGuide
Apache架构师总结的30条设计原则！
Srinath 通过不懈的努力最终总结出了 30 条架构原则，他主张架构师的角色应该由开发团队本身去扮演，而不是专门有个架构师团队或部门。 Srinath 为了解决团队内部的架构纷争和抉择，制定了以下 30 条原则，这些原则被成员们广泛认可，也成为了新手架构师的学习途径。 拿你的代码来说，你想要写的简单且容易理解的话，你就需要花更多的时间去思考。 原则 2： YAGNI(You aren’t gonna need it)：不要去搞一些不需要的东西，需要的时候再搞吧。 此原则是原则 5 的一个具体表现。 Guide:是否有站在用户的角度思考问题呢？是否是为了用新技术而用新技术？ 原则 7： 设计和测试一个功能，尽可能的独立。当你做设计时，应该想想这一条。 一个避免这种情况的好办法就是有一个原则列表，这个原则列表是被广泛接受的，这个列表是人们讨论问题的锚点，也是新手架构师学习的路径。
37820发布于 2020-06-04 - 来自专栏A周立SpringCloud
Apache项目 架构师的30条设计原则
作者：Srinath 来源：ImportSource 本文作者叫 Srinath，是一位科学家，软件架构师，也是一名在分布式系统上工作的程序员。 Srinath 通过不懈的努力最终总结出了30条架构原则，他主张架构师的角色应该由开发团队本身去扮演，而不是专门有个架构师团队或部门。 Srinath 认为架构师应该扮演的角色是一个引导者，讨论发起者，花草修建者，而不是定义者和构建者。 Srinath 为了解决团队内部的架构纷争和抉择，制定了以下30条原则，这些原则被成员们广泛认可，也成为了新手架构师的学习途径。 一个避免这种情况的好办法就是有一个原则列表，这个原则列表是被广泛接受的，这个列表是人们讨论问题的锚点，也是新手架构师学习的路径。
65510发布于 2019-07-23 - 来自专栏Java架构师必看
架构师必须知道的架构设计原则
原则是比具体技术更抽象，更接近事物本质，也更经得起时间考验的东西。这些原则沉淀在架构师的脑海中，最终内化成他的 mindset，以潜意识方式影响和指导他的架构和设计工作。 对于面临企业遗留应用改造和云化迁移的架构师，可以重点参考这 12 条迁移原则。 Docker 容器技术可以认为是为云迁移量身定制的技术。 原理一：系统思考 (System Thinking) 开发驱动的组织，其能力不是制作软件，而是持续的交付客户价值。 这就是近年流行的微服务架构背后的组织原则。详见我之前发表的文章《企业的组织架构是如何影响技术架构的》[附录 6]。 系统思考要求我们加强团队合作，培养流式思维和瓶颈约束思维，找出瓶颈并针对性地优化。 4写在最后 上述原则是架构师必须深入理解和掌握的，但是不能盲从，实际工作中要根据业务、时间、资源和团队情况随机应变。原则有时甚至可以被违反，当然这样做一定有成本，架构师要意识这一点，并适时变通补偿。
1.4K20发布于 2020-08-17 - 来自专栏云云众生s
重新思考人工智能时代的最小权限原则
他们从工作笔记本电脑上的员工个人 Google 帐户 中获取数据以访问该系统，他们在该笔记本电脑上保存了帐户凭据，证明了这一原则。 如今，我们正处于对最小权限进行彻底反思的初期阶段。 最小权限令人痛苦的诸多原因 最小权限原则是在信息安全领域的基础概念，起源于早期计算和访问控制机制。它由 Jerome Saltzer 和 Michael D. 该原则旨在通过确保用户和程序以执行其任务所需的最低访问级别运行来最小化系统内的攻击面。 最小权限的传统方法通常围绕着严格限制用户访问仅与其特定角色相关的资源和信息。
47810编辑于 2024-07-25 - 来自专栏Java技术栈
Java架构师必须知道的 6 大设计原则
开发原则 面向对象的基本原则(solid)是五个，但是在经常被提到的除了这五个之外还有 迪米特法则和合成复用原则等， 所以在常见的文章中有表示写六大或七大原则的； 除此之外我还将给出一些其它相关书籍和互联网上出现的原则 原则分析 1）如果说开闭原则是面向对象设计的目标，依赖倒转原则是到达面向设计"开闭"原则的手段。如果要达到最好的"开闭"原则，就要尽量的遵守依赖倒转原则。可以说依赖倒转原则是对“抽象化”的最好规范！ 我个人感觉，依赖倒转原则也是里氏代换原则的补充。你理解了里氏代换原则，再来理解依赖倒转原则应该是很容易的。 2）依赖倒转原则的常用实现方式之一是在代码中使用抽象类，而将具体类放在配置文件中。 依赖倒转原则要求客户端依赖于抽象耦合，以抽象方式耦合是依赖倒转原则的关键。 3）此原则和里氏代换原则氏相辅相成的,两者都是具体实现"开-闭"原则的规范。违反这一原则，就无法实现"开-闭"原则，首先我们要明白合成和聚合的概念： 注意：聚合和组合的区别是什么？
1.2K30发布于 2018-07-30 - 来自专栏Linyb极客之路
Apache 的架构师们遵循的 30 条设计原则
基本原则 原则1：KISS(Keep it simple,sutpid) 和保持每件事情都尽可能的简单。用最简单的解决方案来解决问题。 此原则是原则5的一个具体表现。 原则7：设计和测试一个功能得尽可能的独立。当你做设计时，应该想想这一条。 原则25：总是要为配置设置一个合理的默认值。 原则26：设计不良的配置会造成一些困扰。应该总是为配置提供一些示例值。 原则27：配置值必须是用户能够理解和直接填写的。 （小编点评：不同阶段采用不同的做法，照抄往往会东施效颦） 总结 作为一个架构师，应该像园丁一般，更多的是修剪花草，除草而不是去定义和构建，你应该策划而不是指挥，你应该去修剪而不是去定义，应该是讨论而不是贴标签 一个避免这种情况的好办法就是有一个原则列表，这个原则列表是被广泛接受的，这个列表是人们讨论问题的锚点，也是新手架构师学习的路径。
56320发布于 2019-08-06 - 来自专栏Java技术栈
厉害了，Apache架构师们遵循的 30 条设计原则
作者：Srinath 翻译：贺卓凡，来源：公众号ImportSource Srinath通过不懈的努力最终总结出了30条架构原则，他主张架构师的角色应该由开发团队本身去扮演，而不是专门有个架构师团队或部门 Srinath认为架构师应该扮演的角色是一个引导者，讨论发起者，花草修建者，而不是定义者和构建者。 Srinath为了解决团队内部的架构纷争和抉择，制定了以下30条原则，这些原则被成员们广泛认可，也成为了新手架构师的学习途径。 总结 作为一个架构师，应该像园丁一般，更多的是修剪花草，除草而不是去定义和构建，你应该策划而不是指挥，你应该去修剪而不是去定义，应该是讨论而不是贴标签。 一个避免这种情况的好办法就是有一个原则列表，这个原则列表是被广泛接受的，这个列表是人们讨论问题的锚点，也是新手架构师学习的路径。 - END -
43520发布于 2019-09-26
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号