zoukankan      html  css  js  c++  java
  • “关于架构的讨论:烦人的细节” 读后感

    “关于架构的讨论:烦人的细节” 读后感

         本文先对bob大叔的观点进行了陈述,好的架构让我们直到项目的后期才需要决定使用Rails,或是Spring,或是Hibernate,或是Tomcat,或是MySql等等。好的架构也让我们能够轻松地改变这些决定。而Brown的观点,则与他不同,认为架构不仅仅是包含在“应用程序”中的内容。结构很重要,但是还有很多重要的内容,像非功能性需求、实际的交付机制(技术、框架、工具、 API等等)、基础架构服务(例如:记录日志、异常处理、配置等等)、集成服务(内部和外部的)、满足所有环境的限制(例如:运维和支持)等等。对我来说,所有这一切都与架构相关。

    我觉得都有一定的道理,如果是一个成熟的团队,有系统的计划,并且项目比较庞大,那么bob大叔的观点更适合因为他们的合作会使项目一个一个模块更加清晰,而不用担心其他人所负责的模块,只需构造相应的接口,就可以完全的将前台和后台分开,一直也维护起来更加方便,也为因为那些不确定的因素而修改代码提前做好准备。

    Bob大叔的结论认:你的架构应该告诉读者与系统相关的内容,而不是你在系统中所使用的框架。也就是说应该首先考虑与用户交互的层面,因为那才是用户直观的感受。

    那么如果是个小团队,人手不足,而项目又小,那么按照bob大叔的观点就会很麻烦,此时我更偏向于Brown的观点,一般这种项目的开发过程并不成熟,时间不允许拖,大部分是走一步看一部,那么就需要更早的确定各个模块具体实现的细节,而前台与后台就具有高耦合性,一旦到开发后期再做决定,那么就不便于对之前的代码进行修改,所以需要尽早处理这些烦人的小细节,

    Brown认为前台和后台如果没有尽早实现联系,那么一个软件就是虚的,没有脚踏实地,浮于表面,而此时处理数据库这种烦人的小细节就变得异常重要。

    Brown的结论是:

    1.将应用程序的代码和技术解耦很不错,而且是我们应该尽力做到的。这样得到的代码更易于做单元测试、易于替代、易于维护、易于修改等等。

    2.软件架构是与全局相关,而应用程序的代码只是全局中的一部分。

    3.如果你仍然把“交付机制”这样的重要决定推迟,并且不考虑如何解决重要的非功能性需求和约束,那么就不得不面临软件项目失败的风险

     

  • 相关阅读:
    [LeetCode] 500. Keyboard Row 键盘行
    [LeetCode] 502. IPO 上市
    [LeetCode] 495. Teemo Attacking 提莫攻击
    [LeetCode] 655. Print Binary Tree 打印二叉树
    [LeetCode] 654. Maximum Binary Tree 最大二叉树
    [LeetCode] 637. Average of Levels in Binary Tree 二叉树的层平均值
    Dubbo 在maven项目中的应用
    前后端分离springmvc和RESTful理解
    一个相对通用的JSON响应结构,其中包含两部分:元数据与返回值
    MAC OS查看端口占用情况及杀死进程
  • 原文地址:https://www.cnblogs.com/cts1234/p/10506098.html
Copyright © 2011-2022 走看看