那一种笔记软件更好用_如果您只能做一件事情来制造更好的软件，那将是什么？...

那一种笔记软件更好用

好的技术实践是我们制作优质软件所要做的–这是软件工程的工程部分。 设计。 编码。 测试和评论。

如果您只能做一件事情来制作更好的软件，那将是什么？ 您在哪里可以获得最大的收益？

持续集成–使代码运行

持续集成是一个显而易见的起点。 您需要先构建软件并使它运行，然后才能执行任何有用的操作。

让开发人员更频繁地签入并相互同步。 更加频繁地构建系统-每天至少要启动一次，然后在每次签入时进行构建。这意味着可以简化和自动化构建系统的步骤。 确保每次都能成功构建系统-没有错误或警告。 这意味着人们可以运行它，并在需要时进行尝试。 确保它将正确运行。 这意味着在构建和部署步骤中添加测试和检查。 建筑物信息辐射器，以便每个人都知道建筑物的状态以及建筑物何时损坏。

如果没有持续集成 ，您将无法敏捷 ，并且需要适当的持续集成，然后才能沿着Devops路径前进到持续交付或持续部署。

而且持续集成也可以在顺序瀑布交付中使用 。 在这些环境中的开发人员可能减少了检入更多代码的次数，但是知道您可以构建和运行系统并看到它早于而不是晚才工作仍然具有真正的价值，尤其是在大型企业系统和大型程序中，依赖关系得到了解决。而所有这些部分一起工作是一个巨大的挑战。

开发人员测试他们自己的工作–使代码正常工作

使开发人员负责测试自己的工作 ，并通过在持续集成的基础上尽可能地使其自动化，是加快软件交付速度并降低成本的唯一方法–过多地依赖于手动测试和交付给测试团队会减慢工作速度你太失望了

在过去几年中，我与之交谈的几乎每个组织都将更多的测试职责推给开发人员 ，并在Google和现在的Microsoft的领导下，将更多的测试人员推入开发团队（或从组织整体移出）。 “更加敏捷”。

这意味着更多地依赖开发人员编写良好的自动化测试（单元测试，使用Selenium或Watir的基本UI回归）以及在Continuous Integration或开发人员的IDE中进行静态分析检查 ，以查找常见的编码错误和安全漏洞。

但是，即使是优秀的开发人员，开发人员在测试中也会遇到什么限制 。 一旦让开发人员编写测试（在他们编写代码之前或之后， 没关系，现在TDD已死 ），您将最终获得大多数简单的单元测试或UI回归测试，并且不会走得太远从幸福的道路出发 ，证明代码可以完成开发人员认为应该做的事情，因为这是他们完成工作所需要的。 他们的假设和盲点将在测试以及代码中得到反映。 很少或没有负面测试。 或可用性测试。 还是安全测试。 或压力测试。 或系统级集成测试。 所有这些仍然必须由某人完成 -除非您希望客户为您找到错误。

团队需要很长的时间才能学会如何编写良好，高效的测试 ，并且需要建立一套能够捕获实际错误的测试，而不是仅仅挡在前面。 但是，如果您这样做正确，则可以在保持快速运行的同时交付良好的代码，并从测试中获得更高的价值。

代码审查或配对–使代码良好

获得更好代码的另一种方法是让开发人员进行代码审查 。

代码审查应首先解决代码中的问题-检查正确性， 防御性代码保护 （错误处理和API合约以及线程安全和数据验证），安全性（正确使用安全性库进行访问控制和输出编码，保护机密数据，记录和审核...）。 关于使代码更好-更易于理解，更安全，更容易更改。

代码审查很昂贵，所以做对了 ：轻量级，基于风险，首先使用静态分析来发现低级错误和不良编码做法，以便审查者可以将时间花在寻找更重要的问题上。

除了尝试查看代码，您还可以尝试使用配对作为另一种方法来查看代码。

配对与评论不同 –目标和优先级不同。 优秀的审稿人甚至会发现通过结对编程开发的代码中的问题， 因为审稿人会寻找不同的东西 。 但是研究证明 ，有纪律的结对编程将为您提供更好的结构化，更简洁的代码，且错误更少。 与代码审查相比，配对是向程序员介绍系统的更好的方法。

结对编程的缺点？ 由两个人完成一个人的工作的成本–一对好的人比一个人工作的速度快，但是经验不足或技术水平较低的团队成员会使这对人的工作慢下来。 焦点疲劳。 配对可能会令人筋疲力尽，这意味着人们不能一劳永逸地完成工作，直到他们的工作变得肤浅或紧张。 和社会问题。 喜欢它的人非常喜欢它。 但是不喜欢它的人根本不会做。

重构–编写代码–设计–最后

那设计呢？ 协作设计研讨会？ 设计评论？ 设计中的威胁建模是否要考虑安全性和操作风险？

我们做所有这些事情。 但是，随着我们继续遍历设计并随着代码库的增长， 重构 （保留并有时恢复设计并保持代码可维护性）变得越来越重要。

学习您的IDE重构工具和重构背后的基本思想很容易。 但是学习如何正确进行重构并不容易（尽管您可以在短时间内从Woody Zuill和Llewellyn Falco的“ 2分钟以内的更好代码 ”视频中中学到很多东西）。 了解为什么某些重构方法比其他重构方法更好。 如何节省重构时间。 如何安全地做。

Mariusz Sieraczkiewicz用迈克尔·费瑟斯在残酷重构和代码生物学方面的工作建立的矩阵，很好地解释了如何以及何时进行“日常重构” ：

1. 从阅读和注释代码开始，也许进行一些临时（快速，一次性）重构以更好地理解它
2. 查找变量和条件的有意义的名称
3. 提取方法以分解大量代码并表达算法
4. 摆脱明显的重复
5. 移动方法并提取类以隔离职责。

我同意Sieraczkiewicz的观点，这些简单的步骤“将治愈这个星球上的大多数代码库”。 然后，他继续描述了更大，更基础的“战略重构”（又名“ 根管重构 ”）：重构为模式，引入新的建筑构造。 承担更高风险和成本的工作。 这是重构结束，重新设计和架构开始的地方。

您将如何做才能开发出更好的软件？

持续集成可以很快得到回报：透明度和团队关注点的变化几乎是立竿见影的。

开发人员测试是一个旅程，而不是目标。 大多数开发人员要花很长时间才能熟练掌握它，并且要花很长时间才能建立一套值得您依赖的测试。 您越早开始越好。

代码审查也可能需要很长时间才能得到回报。 开发人员和管理人员需要花时间进行审阅并建立规范，而开发人员也需要时间学习如何正确审阅代码以及如何提出和接受批评。 但是代码审查（或配对）将为您提供更好的代码。

重构更像是一项复合投资–您今天付出了一点，以节省将来的很多钱。

如果只有一件事情可以做，以制作更好的软件，那会是什么？ 您将从哪里开始？

翻译自: https://www.javacodegeeks.com/2014/12/if-you-could-only-do-one-thing-to-make-better-software-what-would-it-be.html

那一种笔记软件更好用