软件开发的7个情操
在责任编辑中，我将表明那些缺点中的每三个的涵义，并提及当中牵涉的很多不可否认的较好作法。
要聚合高效率，可信和可扩充的应用软件，要自学并遵从很多较好的课堂教学，流程语言，标识符检查和等。
但她们每一人都为这八个白银情操中的三个或三个服务项目：
曾效力
精确性/可信性/可信性
可扩充性
稳定性
可宠信性/可扩充性
扩充性
工作效率
在责任编辑中，我将表明那些缺点中的每三个的涵义，并提及当中牵涉的很多不可否认的较好作法。
为何那个指示很关键？
我早已写出了这八个情操，依照须要对它展开了次序，这是更必要性的。但我将以向后的次序展开表明。
假定我（三个顾客）允诺三个流程，因而给了我三个应用软件，该应用软件被指出总的来说是轻松的。
哦，好的：据传这是轻松的，但我晓得在现实生活当今世界中没甚么是轻松的。因而，假如它要失利，我宁可它以工作效率失利，其原因有三个：
假如流程拥有其他六个缺点，那么开发最终的优化将容易得多。
尽管工作效率失利，但假如流程仍可扩充，我将有机会增加基础平台的功能以获得所需的吞吐量。
假如可伸缩性失利，但流程具有可宠信的部分，则我可以识别标识符中的瓶颈，并用更好的组件替换它，同时仍然宠信其余部分。
假如该流程不可宠信，但它很灵活，那么我可以调整我的数据，以便只要足够灵活，现有例程就可以对其展开处理。
假如流程既不灵活，我希望它至少是可维护的，因为这样我就可以对其展开探索，发现问题并展开必要性的更改并构建另三个固定版本。
假如流程是一堆乱七八糟的标识符行，没可读性，组织或文档，那么我希望它至少是健壮的，因而几乎没须要修复的可能性。
假如它既不健壮，我希望它至少是有效的，因为三个有效的流程将运行一段时间，直到发现很多弱点。因而，即使在这种情况下，流程的其他部分仍可能起作用。
最后，假如该流程甚至没效果，那么除了从头开始编写另三个新流程之外，别无他法。而这次，确保它实现了设计的八个缺点。
计划
从规划的角度来看，有很多略有不同的方法：
假如您只是设计三个无法确定其未来的原型，那么请着重于有效性，健壮性，可扩充性，稳定性和可宠信性。这应该足以产生具有较好成功前景的可信，可部署的应用软件。因而，假如演示成功完成，因而您的应用软件将得以发展，那么您应该能够以最小的努力使其具有可伸缩性和工作效率。
假如您打算设计三个流程以在短期内保持稳定（寿命已接近已知），则应着重于有效性，健壮性，可扩充性，扩充性，以及（假如须要）工作效率（是的，可扩充性，因为总是须要展开更正性修复）。
而且，假如您打算长期发展进一步的发展，那么将您的全部八个情操都投入关注。
1.曾效力
看起来似乎很明显，但标识符的第三个（也是主要的）缺点是它在功能上是apt的，即它的行为符合预期。当您的流程对用户没用时，您不能指望它的快速性或可宠信性将使您的流程受到赞赏。
但，就功能而言，不能通过较好的技术规范来指定。这更多是三个测试问题。
2.坚固性/可信性/可信性
健壮性是对流程展开自动保护以防止错误或任何条件的安全，此类条件会使流程在预期的流程之外运行。很多常见的其原因是数据丢失，出现空值，格式错误或数据不一致。结果可能会突然终止正在运行的线程，耗尽内存，进入无限循环，甚至在不希望的时刻跳转到有效例程。
获得强大流程的很多规则：
最小化类中成员的可见性：默认情况下为私有，除非须要通过子类访问（然后应该对其展开保护），除非须要访问每一流程包（然后应该为公共）。
在线程之间共享数据时，请适当地保护它，以避免数据冲突。
始终保持变量的一致性：每一变量要在每时每刻都包含三个有效值。这意味着在该值有效之前，您不应将任何值加载到变量中。这特别意味着在初始化时不存储默认值（如null）。
类成员变量：应该最好在构造函数中初始化，并提供所有必需的值。
局部变量：在一种方法中，最好延迟变量声明直到有三个有效的初始值。
（我承认在某些情况下，例如对状态机展开编码，在当中值得存储空值以避免过多的流程复杂性）。
要小心大对象创建不排气存储器，特别是那些意味着连续的存储器分配（阵列和基于阵列的结构：String，StringBuilder，ArrayList，ArrayDeque，等等）。相反，请考虑使用基于链接的替代实现。在处理大文件时，请始终选择基于流的算法。
编码循环时，请尝试在声明中建立三个清晰可信的退出条件。最初避免使用内部存在异常退出条件的无限循环。
始终选择强类型：不要使用String类型，而是用于存储透明的用户数据（以及内部ID）。对于所有其他数据，选择了最具体类型可供选择：int，double，Date，URL，Path，等。
请遵从Postel的规则：为输入参数选择最通用的类型，为输出参数和返回值选择最特定的类型。
如有必要性，请尝试避免递归：有可能在堆栈耗尽中产生大量迭代。
使用递归结构时，请避免出现指针循环的可能性（例如，提供每次迭代中馈入的输入参数以跟踪遍历状态）。
提供一整套具有最大标识符覆盖率的单元测试（请阅读我即将发表的有关单元测试的文章）。
推荐模式：无状态，枚举
3.可扩充性
几乎是不言自明的。可扩充性是流程易于开发人员阅读，编辑和修改的过程。由于从第三个版本开始，几乎没流程是100％轻松的，因而迟早须要手动编辑以更正错误或展开改进。
很多使标识符可维护的规则：
最小化每一范围内的声明数：
最小化方法中的行（如有必要性，在其他方法中分配它）。
最小化类/接口中的成员（如有必要性，在其他类中分配它）。
最小化包中的类/接口（如有必要性，在其他包中分配它）。
最小化库中的应用软件包（如有必要性，在其他库中分发它）。
最小化部署中的库（考虑多部署分布式应用流程）。
坚持标准命名风格。
避免重复标识符。取而代之的是，给每一设计的抽象三个具体的责任，并提供三个公共/受保护的API，该API应在须要的任何地方宠信。
自动文档化是最好的文档，但内联注释总是受欢迎的（只要它写得很好因而有帮助）。
推荐模式：抽象，继承，组合。
4.稳定性
当流程不须要严格的参数或前提条件时，它就是灵活的。除其他外，这允许以不同的方式使用同一例程，或处理不同种类的数据。
很多有助于获得稳定性的作法是：
请遵从Postel的规则：为公共声明（输入参数，返回值）选择最通用的类型。
始终基于接口展开设计：通过三个或三个公共接口对模块的主要功能展开建模，并通过那些接口在模块之间建立依赖关系。
组合类时，应优先考虑组合而不是继承。
每一模块至少应包含： 对于每种功能，都须要三个公共接口以及与服务项目一样多的公共方法。
接口的一种抽象实现，以帮助开发人员将其子类化。
可能会发生一种公共异常，当中子类的数量与特殊情况一样多。
三个公共工厂来聚合该接口的实例。
稳定性不能太高。它的局限性是：
为了始终在方法/类/模块之间保持较高的凝聚力。
为了始终保持方法/类/模块之间的低耦合。
推荐模式：抽象，工厂，抽象工厂，组成，继承，侦听器，映射的进程。
5.可宠信性/可扩充性
当可以从各种流程或环境中执行API时，该API是可宠信的。设计可宠信标识符时，最关键的规则是确保其基于接口，因而与其他流程/模块的耦合度低：
最优选地，核心接口应该没上层。
它的方法应该具有低耦合性：它的输入/输出参数类型最好属于标准运行时库。
它的使用应尽可能简单。
假如核心功能是依照那些条款设计的，那么我们只需封装核心接口即可构建所需的外观。例如：假如您打算编写指示行实用流程，请不要将核心功能放在main类中。而是按照表明编写自己的接口，类和工厂，以便您获得可宠信的核心模块。然后，添加三个CLImain类模块，该类具有从何处调用内核的外观。这样，您将来可以添加其他外观。
注意：此处设置的外观只能用于多态分配，其职责通常不只是转换和传递参数和错误。
推荐模式：抽象，外观，适配器，构图。
6.扩充性
扩充性定义为流程随着底层平台功能的增加而以相同（或可接受的相似比率）增加吞吐量的能力。
底层平台通常是依照硬件功能（CPU速度，内存速度和大小，网络带宽）来衡量的，但在开发更高级别的应用流程时，您可能还会考虑到较低级别部分的功能：缓存大小，线程池，磁盘配额，应用软件容器，数据库的索引功能等。
扩充性通常遇到的障碍：
流程中的瓶颈：在处理多线程设计时，请尝试最大程度地减少关键区域的数量和长度。避免进入关键区域的典型技术是宠信缓存中的对象。
内存滥用：在处理大量数据时，避免须要连续的内存分配。总是喜欢流+缓冲，或者至少是segmentation。
大量资源依赖： 最大程度减少大量资源利用的次数和持续时间。
假如要相对于硬件衡量可伸缩性，则要一起评估您的流程和基础平台（操作系统，虚拟机等）（您不能在不可伸缩的平台上构建可伸缩的流程！）。
推荐模式：池，缓存，单例，流式传输。
7.工作效率
流程的工作效率（或性能）是它产生最多结果而仍然消耗最少资源（通常是CPU时间和内存）的能力。从步进曾效力 于工作效率 被称为优化。
这是有关优化的三个最关键的建议（读一本书）：
第一：不要这样做。
第二：好的，假如要这样做，请保留到最后。
如您所见，当我决定将工作效率作为应用软件开发/开发中要实现的最后一项缺点时，我正在遵从那些明智的建议。其原因很简单：优化可能是应用软件开发中最困难和最复杂的任务，因而很容易出错。不做明智的建议是一种尝试，它使您从一开始就将优化作为主要要求引入的初衷就失去了勇气。
相反，第二条明智的建议会指导您首先构建三个运行较好的流程，并最终对其展开优化。如何？我的回答：首先确保它是有效，健壮，可维护，灵活，可宠信和可扩充的。这样，引入优化可能会变得非常简单（例如，通过将工作效率较低的实现替换为更好的实现，由于使用了接口，该实现对于现有标识符应该是透明的）。看看这八个情操是如何关联的？
（阅读我即将发表的文章：应用软件优化的八个白银法则。）
推荐模式：单例，池，高速缓存。
推荐的反模式（小心处理！）：侵入式编码。
原文作者：didiao java原文链接：应用软件开发的7个情操_didiao java的博客-CSDN博客文章来源：CSDN侵删