小故事：架构师需要做什么？

资讯频道 → 非技术

3顶
0踩

2016-02-15 16:05 by 副主编 mengyidan1988 评论(7) 有6760人浏览

架构师

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

本文是一篇模仿问答的小故事，作者用幽默的风格简单分析了架构师要做的工作：
我想要成为一名软件架构师。

引用

这是年轻软件开发者很好的选择。

我想要带领团队，并在数据库与框架、webserver等方面作出重要的决策。

引用

噢，那你根本就不想成为软件架构师。

我当然想了，我想要成为重要决策的制定者。

引用

那很好，不过你列出的内容中并不包含重要的决策，这些都是不相关的决策。

什么意思？你是说数据库并不是重要的决策，你知道我们在上面花了多少钱吗？

引用

也许花的太多了。但是，数据库并不是重要的决策之一。

你怎么能这样讲？数据库是系统的核心，是进行所有数据系统化、分类、编入索引和存取工作的地方；没有数据库的话，就不会有系统。

引用

数据库只是一个IO设备，它恰巧为分类、查询与信息报告提供了一些有用的工具，但这些都只是系统架构的辅助功能而已。

辅助？这太离谱了。

引用

没错，就是辅助。系统的业务规则也许能够利用其中的一些工具，不过那些工具却并非相应业务规则所固有的。需要的话，可以用不同的工具来替换现有的这些；而业务规则不会改变。

嗯，没错，不过必须重新进行编码，因为在原本的数据库中这些工具都用到了。

引用

那是你的问题。

什么意思？

引用

你的问题在于，你以为业务规则是依赖数据库工具的，实际上并不是。或者说至少，在提供优秀架构前并不应当是这样的。

这简直是疯了。如何创建不使用那些工具的业务规则呢？

引用

我不是说它们没使用数据库的工具，而是说它们并不依赖于此。业务规则无需知道你使用哪个数据库。

那么如何在不了解使用什么工具的情况下，获得业务规则呢？

引用

让依赖倒置过来，使得数据库依赖业务规则。确保业务规则不依赖于数据库。

你在胡言乱语。

引用

恰恰相反，我在使用软件架构的语言。这是依赖倒置原则：低层准则应当依赖高层准则。

一派胡言！高层准则（假设指的是业务规则）调用低层准则（假设指的是数据库）。因此高层准则会根据调用方依赖被调用方的原则，而依赖低层准则。这个谁都知道！

引用

在运行时的确如此。不过在编译时，我们想要的是依赖倒置。高层准则的源代码应当不提及低层准则的源代码。

得了吧！怎么能在不提及的情况下进行调用呢？

引用

当然没问题。这就是面向对象的所涉及的内容。

面向对象是关于真实世界的模型创建，将数据、功能与有凝聚力的对象相结合。是关于将代码组织成直观的结构。

引用

他们是这么说的？

大家都知道，这是显而易见的真相。

引用

没错，确实如此，然而，在使用面向对象准则时，的确可以在不提及的情况下进行调用。

好吧，那要怎么做？

引用

在面向对象设计中，各个对象会彼此发送消息。

没错，这是当然的。

引用

而sender在发送消息时，并不知道receiver的类型。

这取决于所使用的语言。在Java中，sender至少知道receiver的基础类型。在Ruby中，sender至少知道receiver能够处理所收到的消息。

引用

没错。不过在任何情况下，sender都不知道receiver的具体类型。

是这样，好吧，确实如此。

引用

因此，sender可以在不提及receiver具体类型的情况下，设计receiver执行某个功能。

是这样，没错。我了解了。不过sender仍旧依赖于receiver。

引用

在运行时的确如此。不过编译时则不同。sender的源代码并不会提及或者依赖receiver的源代码。事实上receiver的源代码依赖于sender的源代码。

不会吧！sender仍依赖于它所发送的类。

引用

也许从某些源代码来看，会更清楚一些。下面这段是Java写的。首先是sender：

package sender;
public class Sender {
      private Receiver receiver;
  public Sender(Receiver r) {
    receiver = r;
  }
  public void doSomething() {
    receiver.receiveThis();
  }
  public interface Receiver {
    void receiveThis();
  }
}

下面是receiver：

package receiver;
import sender.Sender;
public class SpecificReceiver implements Sender.Receiver {
  public void receiveThis() {
    //do something interesting.
  }
}

引用

注意：receiver依赖于sender，SpecificReceiver依赖于Sender，在sender中并没有receiver相关的信息。

是啊，不过你在撒谎，你把receiver的接口放在sender类中了。

引用

你开始懂了。

懂什么？

引用

当然是架构的原则。Sender拥有receiver必须实现的接口。

如果这意味着我必须使用嵌套类，那么……

引用

嵌套类只是实现目的的手段之一，还有其他办法。

好吧，等一下。这又跟数据库有什么关系？我们最开始讨论的可是数据库。

引用

再看一点代码吧。首先是一个简单的业务规则：

package businessRules;
import entities.Something;
public class BusinessRule {
  private BusinessRuleGateway gateway;
  public BusinessRule(BusinessRuleGateway gateway) {
    this.gateway = gateway;
  }
  public void execute(String id) {
    gateway.startTransaction();
    Something thing = gateway.getSomething(id);
    thing.makeChanges();
    gateway.saveSomething(thing);
    gateway.endTransaction();
  }
}

业务规则没占多大份量。

引用

这只是个例子。还能有更多这样的类，实现很多不同的业务规则。

好的，那么Gateway到底是什么？

引用

它通过业务规则提供了所有数据存取方法。按以下方式实现：

package businessRules;
import entities.Something;
public interface BusinessRuleGateway {
  Something getSomething(String id);
  void startTransaction();
  void saveSomething(Something thing);
  void endTransaction();
}

注意：这是在businessRules之中。

ok，Something类又是什么？

引用

它代表着简单的业务对象。我将它放在entities之中。

package entities;
public class Something {
  public void makeChanges() {
    //...
  }
}

引用

最终BusinessRuleGateway实现，这个类知道真正的数据库：

package database;
import businessRules.BusinessRuleGateway;
import entities.Something;
public class MySqlBusinessRuleGateway implements BusinessRuleGateway {
  public Something getSomething(String id) {
    // use MySql to get a thing.
  }
  public void startTransaction() {
    // start MySql transaction
  }
  public void saveSomething(Something thing) {
    // save thing in MySql
  }
  public void endTransaction() {
    // end MySql transaction
  }
}

引用

另外，注意业务规则在运行时调用数据库；不过在编译时，数据库会涉及并依赖于businessRules。

好吧，我想我明白了。你只是在利用多态性来隐藏从业务规则实现数据库的事实。不过仍需要一个接口，向业务规则提供所有的数据库工具。

引用

不，完全不是这样。我们没有尝试向业务规则提供数据库工具。而是通过业务规则，为它们所需要的内容创建接口。实现这些接口就能调用合适的工具。

是啊，不过如果所有业务规则需要用到每个工具，那么只需把工具放在gateway接口中。

引用

啊，我看你还是没明白。

明白什么？这已经很清楚了。

引用

每个业务规则只为自己所需的数据访问工具定义一个接口。

等一下，你说什么？

引用

这就是接口隔离原则（Interface Segregation Principle）。每个业务规则类只用到数据库的某些设施。因此，每个业务规则提供的接口只能访问相应的设施。

不过，这意味着需要很多接口，以及很多的小型实现类，它们又会调用其他的数据库类。

引用

很好，你开始理解了。

不过这太乱了，浪费时间。为什么要这样做呢？

引用

这样做能够条理分明，节省时间。

得了吧，为了代码，弄出来一大堆代码。

引用

恰恰相反，通过重要的架构决策，可以延缓不相关的决策。

这是什么意思？

引用

记得最开始，你说想做软件架构师不是吗？你想要作出所有真正重要的决策。

是啊，我是这样想的。

引用

你想要决策的是数据库、webserver和框架相关的方面，对吗？

是啊，你说那些都不重要。只是不相关的内容。

引用

没错。就是这样。软件架构师所作出的重要决策指的是，让你不对数据库、webserver和框架进行决策。

不过必须得先决定那些吧！

引用

不用的。事实上，在开发周期中，这些都可以稍后再决定，在信息更充足的时候再决定。

如果架构师提前确定框架，却发现框架无法提供所需的性能，或者带来了无法忍受的约束，这就成了灾难。

只有架构师决定推迟决策，待信息足够时才作出决策；在架构师的决策下，不使用缓慢而过于耗费资源的IO设备和框架的团队，才能创建快速、轻量级的测试环境；只有其架构师关心真正重要的东西，延缓那些不重要的，这样的团队才是幸运的团队。

胡说，我完全不明白你的意思。

引用

好吧，还是好好看一下本文，不然只能再等10年你才能明白了。

作者：Robert C. Martin
原文：A Little Architecture
译者：孙薇

分享到：

3
顶

0
踩

评论共 7 条请登录后发表评论

7 楼我会是微博 2016-02-20 15:16

面向接口编程，别乱来

6 楼 yixiandave 2016-02-18 10:10

gordon_two 写道

我觉得应该将复杂问题简单化，将简单问题保持简单。
坚持接口优先原则的，其实是僵化的思维结构，99%的领域问题是简单的，却增加了100%个接口，我觉得不妥

但是你不能保证省下99%的简单问题不会在后面某次需求变更后变成复杂问题，这是很常见的情况，这样的话重构的代价就太大了。当然交付后就不用管的项目除外

5 楼 gordon_two 2016-02-17 16:11

4 楼白云天 2016-02-17 15:45

把简单问题复杂化，复杂问题简单化，玄之，哈哈。

3 楼猿哥哥的成长记 2016-02-17 14:47

2 楼 neo_it 2016-02-16 14:14

谁写的鬼文？思维混乱，言不达意。
整篇想说的就是：构架师要先清楚业务需求，再来决定软件框架。
就这么简单的一点，需要唧唧歪歪说这一大家通？

1 楼 snow8261 2016-02-15 16:46

写的非常好！

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

数据库设计规范（通用版）.7z

数据库设计规范，可以供大家下载参考。规范项目数据库设计

软件设计规范

范围：CPU上可以识别的代码和数据。全部的代码总和。要求：从定义开始的设计。完整性，彻底地定义从无开始的整个设计。这是因为软件之软，也是因为硬件平台的多样性和特殊性。完整把握，从头设计是第一原则。因为软件世界自己并不能统一，还有继续分化的趋势。没有根本一致的基础可能是软件的本性。退回到一无所有是处理软件问题的根本。在这样的视野下，操作系统只是一个部分，一个模块，不同的操作系统任你选择；语言的选择是运行环境的选择（每种语言有每种语言的运行时布局）；所谓框架只是“类库＋运行环境”的一种构造。没有对其负载能力、操作强度进行评估前，这些东西（操作系统、语言、框架）还都不能纳入设计规范。性能：运行过程的收敛（长时间运行的均态）。操作强度设计（串行处理速度），负载能力设计（并发处理的量）。可靠性设计。软件问题的3个方面： 1、硬件，软件的操作对象和运行软件的数字系统（CPU系统和数字加速硬件） 2、交互操作（界面），专业界面设计 3、软件调度性能，实时的自动化过程（设备控制和自动测量）和用户交互过程（请求服务过程和干预过程；本地交互和远程交互），程控和网络访问的调度（服务器）。软件项目的3个部分：（把3个阶段由纵向横过来，进行统筹）分解文档，集成平台，可维护性要求。软件设计必须有自说明特性。不能对文档产生依赖性。软件代码中合适的地方，需要对文档进行恰如其分说明。原则是，每段代码，每处需要理解的地方，如果和总体架构相关，就要有说明。软件领域需要简化。需要还原软件本来的面目。EDA有泛滥的趋势，软件的各个方面都需要简化。软件形态、需求分析、文档说明、开发工具等。需求分析过分强调适应生命周期的变化和没有需求分析是一样的。不切实际的面向未来的需求架构的直接结果是软件的复杂和错误百出。软件只有一个，而观察的视角很多。要采用最适合的观察视角，让软件一目了然。软件的生成过程和观察过程是两个不同的观念。生成过程又可以区分为：研究过程和工程过程。研究过程可以通过结果，研究报告反映；工程过程则必须采用过程刻画。软件规范使用的语言一定要有普遍语义，但描述本身具有特殊性；不能强求它的全球唯一。一定要雄视全体，才能选择正确的立足点，这就要求对目前的软件技术有一个了解；要考虑纳入新的发展，那么规范应该分层，把一般的和具体易变的成分分开；要有具体的指导意义，越具体指导意义越大，但通用性则越小。所谓架构，可能是十分具体应用的代表；不同类别的应用必然有不同的架构。软件架构本身是“应用架构”。因此，不能规范具体的架构。到是可以做：应用架构规范的规范。逻辑架构的特殊性。可以判断，任何一款实用的软件采取的软件逻辑抽象都是别样的，特例的逻辑。否则，软件不可能那么轻快实用。软件逻辑，鬼魅也。而需求分析，必须是现实实用的，而不是同构/仿真的－这似乎是反对象分析的。因为这里强调的是和软件的交互界面，这个界面远远没有反映现实世界的结构。须知，软件强调的是数据处理，是输入输出。否则，就不能达到最简化。可能现实世界的结构映射，最适合的方式是数据库－采用纯数据结构进行映射。除此之外，能有更合适的技术吗？面向对象建模是吗？那么对象又如何与现实世界的对象绑定在一起呢？这再次表明，在软件技术和需求分析之间有鸿沟。软件技术作为特殊的技术，有它的有限性。也反映了，包含软件应用在内的现实架构已经固定。如果软件是数据处理，是输入输出，那么软件结构也就可以确定了！可视化、用户操作界面解开了另外的软件世界，因为可视化可以代表用户更抽象的逻辑。用户希望操作可视对象，象操作现实对象一样。软件从模拟现实对象的过程中继承了其结构。工业控制也开启了新的软件世界，因为软件要从分离的输入建立“综合感知”，感知到设备状态，然后做出响应。软件有其固有的物理属性，也就是计算的量。算法领域，无论算法的论证多么曲折，求得的结果，物化为软件，总是“早已熟知”的软件。这一区分，是定义软件规范的基石。算法构造领域是和软件完全不同的领域，算法不是软件。算法类似数学系统。也一如数学系统那样多样。软件构造。算法总要转化为软件，这就是软件构造问题。寻址系统，数组。软件把自己的生成作为问题，给算法开辟了新的领域。软件生成，是一个“构造－编译”问题。手工构造，自动编译。语言的发展，是一个软件生成的历史。所谓统一建模，所谓设计模式，其实都是软件生成的问题。需求分析。需求分析本质上是独立的。所谓OOA，面向对象的建模，把程序构造概念上升到需求分析领域可能是不对的。一个先验的，复杂的难于掌握的限制，只会让人对需求分析望而却步；即使勉强掌握，难求对需求分析的创造性发展。需求分析应该专注于需求分析本身，独立发展，一切为了准确、快捷的分析。需求分析层次高一些，抽象一些，自由一些，这样可以充分表达需求的本质。反而可以促进更高级别的程序自动生成。软件生成的历史。软件生成是为了解决人机沟通，让“计算机语言”更接近普通人的思维逻辑。把这种“高级计算机语言”翻译成可以执行的代码，就是软件生成（代码生成）的任务。而软件编制是专业人员的事情，因此语言问题的本质其实不那么重要。须知，经过培训，莫尔司码的电报发报可以比说话的语速还快！因此，计算机语言的前途迷茫；实际上也确实迷茫，历史上语言的层出不穷本身就说明了问题，至今仍然如此。在当今，必须建立这样的观点：语言是因人而异的；面对一个语言的时候，要清醒，首先明确“这是为谁设计的语言”；也就是说，需求分析之前的需求是要明确，让什么人来设计软件，然后为他们选择合适的语言。软件生成除了代码生成，还包括另外一个意思：软件构造。这在前面已经论述过了。只是，这里的软件构造机制已经在语言中奠定了。手工参与的软件构造只是语言给出的构造机制的应用。手工的软件构造就是语言构造机制的复制，产生大量的代码，应付实际问题的量。立体构造。这里还有一个立体问题，实际问题的构造可能产生立体构造，如同建筑，基本的构件组装出复杂的立体结构。这里是建筑设计师的功劳。可能目前我们在语言层面上混淆不清的关键也在这里，没有区分语言和立体构造的责任。一个趋势是语言本身总是试图包揽建筑师的责任。把立体构造独立出来，带来的问题是：这个构造本身必须能够证明自己是正确的。1）能产生软件2）构造逻辑上正确，确实能解决应用问题。构造本身有一个属性，它有通用性。根本原理是通用的；总体构造本身具有一般性，也就是抽象性、实际问题无关性；局部构件具有通用性。也就是说，这里存在容器和容量的区别，构造是容器，实际问题是装在容器中的量。一个好的容器要能顶住容量的压力；一个好的建筑架构要能满足负载和抗振性要求。而架构本身的承受能力是客观的，只与架构本身有关。这也就是说，架构本身自我构造的，因此也就是科学。可能软件构造本身是澄清问题的工作，明确“容量”的特点，为软件构造的选择提供准确的依据，杀鸡不要用牛刀。实际问题的“容量”很容易测量，因为它反映为应用的规模，流程的流量。（架构是什么？架构是否存在？如果我们所说非虚，那么如何为架构下一个定义－一定是一个由具体业务流量和模式支撑的架构）软件（算法）的构造。一个是数据的复杂性（内在互相关系），一个是计算方法（步骤和缓冲）。从宏观角度，数据关系是更根本的东西。目前的高级语言，变量和流程（顺序、分支－步骤；循环－缓冲和迭代）研究的多，而数据复杂性构造不足。同构现象。CPU指令集合可以说是硬件直接实现的软件。软件帝国从这里提取软件精神，并升华它。从硬件的角度，从寄存器和指令执行流程，体现出的是变量和迭代（顺序更迭，循环往复）。（迭代流程）基于固定寻址的变量，经过寻址接口，可以处理任意数据，从而把迭代流程变成了一般流程。CPU的基本过程，产生了指令和数据，指令天生具有子程序的基因（一般流程），数据天生具有数据结构（寻址能力）的基因。高级的构造一般也是这种结构的类似：设计一套类似CPU的机制，支撑程序和数据；独特的“寻址机制”和“CPU处理能力”是实现构造的核心机制；迭代是所有这种机制的动力学和构造方式。而数据化是“寻址机制”的基础。抽象是数据化的工厂，也因此必须研究抽象技术。抽象技术。所谓抽象，就是具体化，是范围的界定和比对（两种具体化对象之间的比对）。如果范围界定的完整，那么比对建立的联系就是普遍联系，普遍联系也就是所谓抽象原则。评价标准。软件架构需要评测。这种评测是“在商言商”似的评测。评测的基础是软件架构的具体化。当掌握了架构的构造方法，每种架构本身也就具体化，是一种具体的架构。一种具体化的架构，就可以识别；可以识别则可以客观评测。可以按照立体架构的“压力”、“流量”等概念进行评测。需求的把握－需求的变化。我们希望永恒不变的需求，核心需求和需求方式（表现和满足步骤）；而事实上需求总在演化。软件必须无条件、最大限度地方便需求的表达和需求的满足。软件可能永远只是皮肤，需求源于现实核心深处，软件是一件衣服。这种观点下，软件是没有中心的一种架构。软件架构和需求之间联系的定量评测。软件和算法的分开软件的构造作为软件的通用属性需求的独立推论：算法是应用的算法。比如数学公式的计算、图形图象的处理、频谱分析、词法和语法分析。因此算法不是通用的软件算法。也因此软件构造是软件规范的一部分，因为它是通用的软件构造技术。计算技术和应用之间有明显的区别，是两种不同的成分。软件规范是纯粹的，只关心计算技术。而不关心应用建模。计算方法本身早已经被发现了（也就是怎么自动计算，或者说什么是可计算的），剩下的问题只是应用问题。把应用问题的解决纳入软件计算模式。自动计算技术在汇编指令集合那里得到了说明。所谓软件设计是把这种计算方式发扬广大。所谓算法，就是明确问题，然后发现用自动计算的方式解决问题。从这个意义上说，软件是应用问题导向的。那么，也就是要以问题为中心谈论软件。不同类型的问题需要的解决方式有独特的强调。这也就反映为所谓不同的软件技术。所以，区分软件计算技术和应用问题的成分，是软件规范需要首先识别的东西。解决问题。本质上是把问题装到变量里面的过程，是放大CPU寄存器的过程。表示层：（把局面、环境；起点和终点需要定义在一个世界里）装进去，组织起来。计算层（展开层）：基于表示，定义问题解决步骤（定义运动和过程）。需求分析。问题描述采用的方法可能应该和软件算法完全分开。否则不能发现问题描述的创造性方法，不能表达问题本质。阐述问题，写文章我们有某篇布局之法；哲学研究我们有严谨的逻辑方法。需求分析，我们一定可以创造自己的方法。这是什么方法？满足使用要求，满足使用流程。离散/隔离各个需求。事实上，面向外部的分析理解和面向内部的分析理解之间有鸿沟。因为这是两个不同的世界。在两个相差悬殊的世界之间，搭建的构造也必然多种多样，以奇为平常。那么，建立联系的媒介少的可怜。可能问题本身也正在于这种联系的分析和设计。软件的量，是静态的。强调这部分就忽略了活跃的、奇异的、动态的部分。软件的出现不仅仅是被动地适应显示需求，同时也改变了现实需求本身。这种和现实需求融合在一起形成的状态，正是软件活跃的部分。在以前，仅仅以“应用软件”指称是不够的。（操作系统、编译软件、应用软件）在范畴上，分为三个层次，或说3个范畴域： 1、活跃的、黏性的动态层次。应用层。和现实之间的界面，是设备逻辑。需求简化、解决方案的奇异性；应用算法的专业性。这是软件形象最活跃的部分。这里用的是抽象（业务流程）和具体（设备能力）统一的思维方法，构造逻辑的软件过程同时又是可以用具体进行描述的；动态的、物理的分析手段（物理的量）。业务流程的设计几乎就是艺术设计。 2、中间层。程序构造层。语言、编译技术、数据结构、设计方法（过程、数据、对象）等可以形式化的计算机科学的任务。对程序能力进行抽象，设计程序自动化生成的一套系统：语言、计算系统、编译系统。这是在静态和活跃部分之间的层次。这里的观念：设计方法、主程序、程序过程（和应用层的过程不是一一对应的）。 3、静态层。软件的量，度量层。所有程序构造过程的差别消失了。这是软件的静态观点。每层都有对软件的自己的理念，概念、过程和模型。两个层的对比，则凸显出不可调和的差别。也是所有关于软件的不成熟的印象、抽象产生的地方。在应用层，抽象的、逻辑过程强一些。想象的部分占据主要的部分。需要对现实的业务，基于设备的具体能力，进行构造。 3个范畴定义了“软件”和“程序”的分别。第1层和第3层论述的是“软件”，而第2层论述的是“程序”。软件和程序的研究方法不同。程序研究方法是完备的，而软件不完备。程序开发应当体现软件特性。1）是逻辑的过程，总体的过程和子过程的观察和校验程序。2）软件的量层次上，软件的规模、运行强度和稳定性指标的自测试程序。第二阶段一定要有一个标准。软件如衣服，软件的交付文档应当显示出衣服是如何编织起来的。（相对于需求，软件是衣服，非核心；相对于硬件，软件是衣服，包裹）要有一个理论说明。架构也是衣服的一个部件，类似衣服的连接方式，模块集合的重心比对。衣服是一个没有核心的结构。软件也一样要显示出这个特性。无论如何，我们需要有观察软件的眼光，无论一套软件依据什么样的理论产生。什么是软件？描述是软件的存在形式（文本格式）。软件一定是可执行的（这是软件的严肃性，精确、定量）。软件是异化的，一般异化为具体、特例（对抽象力最好的归结方式）（没有完美满足需求的软件，相对于需求，软件只能满足固定的需求，而不能满足需求的变化，即一款软件总是具体的；由一般产生出具体的思考方法，也就是构造的方法；或着是磁力打造，一个好的理论一定对现实素材有吸引力，向磁铁一般；这也是在矛盾中建造现实的方法，只要是具体的就肯定是可以分析出潜在矛盾、不完美的，问题不仅仅是分析、认识现实，还要能够构造现实；不存在完美的现实，只存在完美的理论科学研究的方法是简化。工程的方法是‘相似’，复制发现事物时的状态，那么事物的表现就会复现。在具体化这里，软件和硬件工作的方法在结果上实现了一致。只是方向不同，软件是从一般进行到具体；硬件一开始就是从具体出发，层层构造，搭建系统。硬件的设计明显具有以工艺、器件为核心的特征。配合器件的特新，进行外围设计。在硬件领域，是‘具体’为上；在软件领域，是‘具体’为下。）对具体性的解释：组成所有物资的电子、质子、中子是圆的、相同的，但是这些相同的东西组成的原子则有几百种不同。每次量的规模的添加，都导致特殊性的添加。对于软件来说，也是如此。如下的概念是母庸质疑的，软件如同大山，沟壑鲜明。（这种巨大的特殊性，一定是和巨大的需求特殊性相应的）。 “软件以文本形式存在；软件在执行着；软件以个例的形式存在”，归结为在一起就是“软件是具体的”。低一级别的定义：软件与数据和逻辑相关（数据和逻辑是软件的基本语义）。软件与过程相关（积分（存储，数据的数据化）和步骤（逻辑）；过程是步骤的遍历，是数据的消长变化）。执行的异化。区分独立执行和整体执行的概念。独立执行的代码称为模块，否则只是‘片段’。独立性和数据完整性相关，数据越庞大那么不独立的代码片段越多，模块就越大。模块独立性具有比和整体执行所要求的更大的自由度，也就是说整体只是使用了模块一部分的执行能力。模块独立执行获得的自由度是应该能够度量；模块的执行设计应该为了获取更大的自由度；自由度是模块可执行性质量的评定指标。对于整体执行的设计来说，自由度设计可能是设计过程的主导方法，它和全面、完整的需求理解相关，也和需求变化相关；因此自由度设计也是需求定位的设计。软件的量，也就是软件的能力。这是理解软件解决问题的方式的基础。比如逻辑能力、计算能力、存储能力、图象能力等。软件是运行的，软件是自我构造的，软件的全体的各个环节都有自己的量。编译、操作系统、文件管理等各环节都是不同分工的软件实现的。需要构造在功能层次上的互相配合，解释这种完整性。显然每个部分都具有独立的完整性；完整性和完整性的配合构成一个总体的系统。因此未必要求系统的完整性、长期性、稳定性。反过来，系统满足需求的快速性、快速变化适应性、和现实一起变化、消长的特性、瞬态响应特性可能更接近系统的本质。这好比太极拳，要在一个完满的氛围里运动。软件能力是比代码高一个级别的抽象。又是构成软件内涵的基础语义。 ‘设备能力’的概念更基础，可以统一所有其它能力；又可以作为以硬件为中心的观念的基础。能力的获得在于‘二分’。在于互相支撑的界面，支撑在一起的双方互为能力。 1．所谓需求分析，我们总是在创造一套新的方法和语言。而最有效的需求分析是自然语言分析。借助人们心目中的全部理解所用到的描述形式。也就是进入到实际存在的需求中去理解需求，分析需求。因为领域、术语、行业表述习惯的原因，这个阶段千差万别。 2．其次是电脑的使用方式－电脑技术（外设、通信和电脑本身的硬件形态），尝试去设计合适的使用方式和硬件解决方案。这里有使用环境、专业技术、成本、时间，以及个人习惯等原因，同样是一个精彩的过程。对领域工作方式的熟悉、外设相关的专业技术背景、折中技术决定了这是一个经验至上的活动。这就是电脑使用方式的确定。 3．进一步，确定使用者角色。使用者和使用地点关联。使用地点也就是前面电脑使用方式的一部分。这是一个沟通过程，也是对有了电脑辅助参与，相关领域习惯改革的问题。 4．然后，进入二元分析阶段：使用者管角度、客观功能角度，分析功能，并完成二者之间的映射。这个阶段，功能被量化。职能量化。职能和功能之间会有模糊，有授权的转移。这个阶段就是充分考虑这些问题。 5．然后，进入传统的需求分析阶段。计算架构和功能描述的规格分析。使用者界面规划（详细、规格级别）。界面规划、功能、架构三者之间组成互动的具体化过程。最后会产生系统级别的文档。运行实体、接口；系统运行态、实体接口的输入输出规格。 6.然后，实体级别的程序构造阶段。算法构造和程序构造。主要是从资源占用的角度确定宏观的算法。在这个阶段，是程序文档化阶段。文档这个属于是这个阶段的工具。最后会产生严格的程序模块的文档。所有这些文档组合起来，可以构成运行流程。这些文档化的程序就是逻辑化的程序本身。 7.最后，编码阶段用一种具体的语言，按照模块文档的接口、资源、算法要求，编制代码。

软件设计方案（编程规范总则）

1、排版 1）程序块要采用缩进风格编写，缩进的空格数为4个，对于由开发工具自动生成的代码可以不一致； 2）相对独立的程序块之间、变量说明之后必须加空行； 3）较长的语句要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读； 4）循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分，同3）； 5）若函数或过程中

开发中基本的规范和约束 + 设计模式

一、基本的规范对于基本的规范和约束，每个合格的团队都会有一套自己的。一方面统一标准，增加可读性和可维护性另一方面也方便离职后出现 Bug，后来的维护者也能更快的去定位并解决问题。 1.1、命名大驼峰、小驼峰或者下划线命名都可 1.2、注释合理使用注释。并非注释越多越好。目标：源程序的文档化二、一些应该熟知的编程思想不管业务逻辑是否复杂，不妨先绘图在动手，把一个模块继续...

软件界面设计守则之易用性的详细规范

软件界面设计在现在的互联网时代越来越火，想必做设计的也都知道，它也是要遵循一定的设计守则，其中易用性就是软件界面设计中的守则之一。但仅仅知道这一点还是不够的，因为易用性的背后还有很多的一些小细则，今天我们就来对这些小的细则进行统计分享。 1.完成相同或相近功能的按钮用Frame框起来，常用按...

阿里巴巴开发规范

一、编程规范 1.1、命名风格（1）不能以下划线或者美元符号开始和结束；（2）不能使用拼音和英文混合方式，不能直接中文方式；（3）类名使用UpperCamelCase风格，但是DO/BO/DTO/VO/AO/PO/UID除外：正解：MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion 反例：macroPolo / ...

软件设计和开发规范（国标）.rar

软件设计和开发规范（国标）

软件设计原则

软件设计原则，更好的设计我们的应用。

7.3.项目开发设计流程规范与技巧

一个项目从客户提出需求，到需求分析，再到设计、开发、测试等，经过一系列的环节后，才能达到正式使用和上线的效果。为了标准化开发流程，提高开发效率，特将项目开发的一下规范和技巧，做一些说明。项目开发流程，如下图所示。这里贴一个流程图：客户提出需求、我们整理需求、设计页面原型、编写功能需求补充文档、与客户沟通核对原型和需求、调整原型与需求、确认原型与需求、数据库UML建模、UML建模确认、数...

软件设计和开发规范（国标） (转)

软件开发规范，包括：1-操作手册（GB8567——88）.doc2-测试分析报告（GB8567——88）.doc3-测试计划（GB8567——88）.doc 4-概要设计说明书（GB8567——88）.doc5-开发进度月报（GB8567——88）.doc 6-可行性研究报告（GB8...

java开发种规范全集

最近在公司没事，整理了一些开发规范

软件开发编程规范及原则

推荐分享一个大神的人工智能教程。零基础！通俗易懂！风趣幽默！还带黄段子！希望你也加入到人工智能的队伍中来！http://www.captainbed.net/strongerhuang 我的网站：https://www.strongerhuang.com 我的知乎：https://www.zhihu.com/people/strongerHuang.com Ⅰ、写在前面不...

软件界面设计守则之规范性详细细则

在上一篇的分享文章中，我们分享了软件界面设计中的易用性细则，今天我们来分享下软件界面设计中的规范性细则。通常界面设计都按Windows界面的规范来设计，即包含“菜单条、工具栏、工具箱、状态栏、滚动条、右键快捷菜单”的标准格式，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。那么，具体到...

RESTful API 最佳实践

如何设计自己的 Http 接口符合 RESTful 风格，一文秒懂

软件开发设计规范书的撰写

整个软件开发过程是一个相当复杂的流程，并不是简单的靠几个设计工程师自己在那边写软件就完，而是要有从头到尾，包括很多人，不同专家，不同的专业，不同的知识放在一起，最后才造成一个完善的软件产品。从决定开始，到计划、设计，最后到写程序、执行，然后还有测试、纠错、保证稳定、发行、部署、调试，整个过程是一个相当长的过程，并不是一个简单的程序。要为了保证软

项目开发文档编写规范

在开发项目的过程中，我深刻的意识到，文档存在的意义并不是无用的报告，简洁明了的文档不光能记录你当下所做的，还能在繁重的工作中分神思考下一步该做什么时为你节约精力，并且在项目周期内，使整个项目保持一致性。所以，软件开发文档的编写是很有必要的。我参考网上的资料，结合自己项目开发时的心得，分享一些经验。

软件设计和开发规范(国标)

包括：1-操作手册（GB8567——88）.doc 2-测试分析报告（GB8567——88）.doc 3-测试计划（GB8567——88）.doc 4-概要设计说明书（GB8567——88）.doc 5-开发进度月报（GB8567——88）.doc 6-可行性研究报告（GB856...

程序设计规范(转载)

程序设计规范1. 文件夹与文件的命名规则1.1 文件夹命名① 根据系统设计所规定的结构，建立相应的文件夹，根据需要建立子文件夹② 文件夹的名称应尽量能够表达其意义，尽量使用英文命名，绝对不能汉字③ 文件夹名称的必须全部使用小写字母 (如 “ /example ” )1.2 文件命名① 文件的名称应尽量能够表达其意义，尽量使用英文命名，绝对不能汉字② 文件名称全部使用小写字母(确保平台兼容

软件开发规范

为什么一份合格的代码不应只满足于实现功能，更应该遵循良好的规范提升程序稳定性，减少代码隐患，降低故障率增强可扩展性，大幅提高维护效率统一标准，提升多人协作效率，方便新人快速上手系统设计不允许出现两段相同的逻辑块，必须抽出为公共方法，差异性使用参数控制，避免修改时多处修改遗漏不允许出现两段相同的处于同一逻辑组的赋值布局，必须抽出为单独的include/merge 不允许父类中出现子类的实现方法，如果需要的话可以定义父类抽象方法，交由子类实现不允许activity内多个fragment之间的

3顶0踩