网站用asp还是php,如何做古诗词网站,建设网站硬件需要,中国网站设计张泰峰 6月3日
写在前面
2019悄悄溜走一半#xff0c;无论是离别的忧愁#xff0c;还是成长路途的艰辛#xff0c;都在心中滚烫。
距离上一篇文章已经很久了... 懒惰的博主不能将这一切归结于我的时间、我的规划、我的工作#xff0c;只能怪自己懒......正所谓学如逆水行…张泰峰 6月3日
写在前面
2019悄悄溜走一半无论是离别的忧愁还是成长路途的艰辛都在心中滚烫。
距离上一篇文章已经很久了... 懒惰的博主不能将这一切归结于我的时间、我的规划、我的工作只能怪自己懒......正所谓学如逆水行舟不进则退不进到最后就只能退了。
今天突发一些关于架构的感悟执笔记录下来。 软件架构的出发点
软件架构是一个软件系统开发生命周期中最前端的部分也是最关键、最核心的部分。它决定了后续代码的走向能够决定项目的走向有时候甚至能够决定一家公司的生死。软件架构的成功要素有很多点这些点的一两个或更多个组成了不同级别的业务系统或用户系统
*1 可靠性
*2 安全性
*3 可伸缩性
*4 可定制化
*5 可扩展性
*6 可维护性
*7 用户体验
*8 可快速迭代性
面向用户的系统用户体验 、快速迭代、安全、可靠 这四点必不可少这些点围绕着的基础的技术选型、管理模式、规则、流程也就跟着对应的权重的不同去分配了。
假如公司A需要做一个工具appxx计算器、或xx记事本。 想要获得市场认可它的架构就需要大约 30% 用户体验 、20%快速迭代、 10%可靠。按照这个权重的分配去管理架构的技术选型、管理模式等等。一个工具app的安全性做的无懈可击是不会得到市场认可的一个电商网站的安全性可靠性不能保证会被市场所抛弃。
又假如公司B有一个对内的管理系统想要正确的结果首先就得保证 可快速迭代性 业务每天都在变化相反的用户体验、伸缩、安全、可靠都可以相对不那么迫切。
通过可快速迭代性迅速迭代可定制化需求和可扩展性需求提升了用户体验用户体验的提升带动用户量的增长则对可靠性、可维护、安全性、可伸缩性提出了更高的要求。
上面是我想要表达的软件架构的出发点是项目所处的市场的需求决定的。需求是什么决定了架构是什么。
架构是难以更改的。是的架构是非常难以更改的如果你的项目已经推出市场了除非重头来过承受彻底重构带来的阵痛。这里往往要面临更严峻的考验例如人事处理有很多c开发想要转java或有很多php开发想要转python再例如架构的改弦更张势必要有加班的埋头苦干一个月再走一遍来时的路~
举个栗子TDD TDD本质过程就是要贯穿从需求分析、设计、编码、测试、整个研发过程。它其实是需求驱动逐个满足每个的需求。 TDD的核心就在于把需求分析,设计,质量控制量化的过程在编写测试用例时就可以规避、重构、设计需求的架构。TDD其实就是一个以需求驱动的架构模式、开发模式。
或许你已经在做相关的架构处理了或许你已经吃到了一些苦头这个理论或许可以帮助你认识到要根据市场需求来制定合适的架构推导合适的架构细节。要慎重。既不可以过度设计也不可以设计不足这把量尺是市场需求。 架构以人为本
架构设计必须要考虑人在其中的重要因素合适的人做合适的事情。一个好的架构首要的就是要考虑所在团队的人的情况我们往往倾向于抓技术层架构忽略了怎么将合适的人放到合适的位置已有的团队人员能不能合理的在架构中发挥应该有的作用。
抽象的处理、框架的引进很重要的一点是如何解决人员素质、想法、环境的不一致。框架通过封装复杂的东西简化业务的复杂程度让对应的人能够专注对应的事情。抽象通过可以被共同理解的概念简化复杂的内部处理逻辑将人的目标聚拢在一起。
软件架构应该以人为本将最高效的人放在最高效的地方能够取得最大化的成果架构设计也就必须考虑人的因素。
例如我们有一个5人团队做一个项目团队成员比例大约是 1个leader 2 个核心 2个实习在设计这个项目的架构的时候你必须要考虑的是如何设计能把2个核心成员的力量放在合适的地方如何设计能让2个实习成员能够完成既定的任务。 假如将2个核心与2个实习放在一起看待过不了多久会出现一个情况核心成员感觉做的东西技术含量太低实习成员可能感觉东西难、累、赶长此以往项目会频繁面临人员变更。
我们倾向于集中精力做技术层架构而不是人员层架构方面工作的主要原因不是因为技术更重要而是因为技术更容易做。人际交往是很复杂的并且就效果而言从来都不会是很明晰和清楚的但是它们比工作的任何其他方面都更重要。写代码并非只是写代码而已而是与人有关——需要理解的东西包括那些人是谁他们能作出什么贡献和需要什么东西以及是多数派还是少数派等诸如此类。“如果你把架构重点放一部分在人员安排的身上那么就会发生更好的事情。
从人的角度衍生出的信息的交互
信息的交互其实是软件开发过程中需要重点关注的事情。信息的完整性、真实性影响着开发过程中风险的暴露。风险则决定了项目的成功与否所以我认为它是架构其中的一部分它常常被人忽略因为它既不属于技术也不属于人员更像管理工作但其实它也跟架构有明显的关系。
软件项目的风险无非体现在以下四个方面:需求、技术、成本和进度。任何信息的不对等都有可能导致需求完成有误、技术设计偏离、成本过大、进度延迟。怎么样规划合理的信息交互、制定合理的反馈机制是架构需要考虑的问题之一。
总结和感悟
架构的目的是贴合市场需求指定合理的技术规划、人员规划、信息交互规划架构是不仅仅局限于技术层面的。一个软件架构师你需要统筹全局深入了解需求了解业务的走向了解技术的价值所在。也需要制定或迎合人员的搭配制定信息交互的流程。
核心观点
就是不可以忽略市场需求在架构设计中的力量
更不可以忽略人在架构处理中所占的比例大小。
过度关注技术本身是一个本末倒置的行为。
阅读目录置顶)(长期更新计算机领域知识https://blog.csdn.net/weixin_43392489/article/details/102380691
阅读目录置顶)(长期更新计算机领域知识https://blog.csdn.net/weixin_43392489/article/details/102380882
阅读目录置顶)(长期科技领域知识https://blog.csdn.net/weixin_43392489/article/details/102600114
