更快地编写更好的代码：5 分钟阅读

关于如何在不影响质量的情况下更快地编码的小技巧

最近，我阅读了David Farley的“现代软件工程”，它详细阐述了现代软件开发核心的持久性原则。我认为这本书对于经验丰富的工程师和初级工程师来说都是一个很好的资源，尽管从不同的角度来看。

新开发人员会发现这本书是关于如何在不重新发明轮子的情况下设计和开发软件的好指南。当您刚刚开始编写应用程序代码的第一行时，Farley 先生会亲自指导您如何做出合理的决定。对于一位经验丰富的工程师来说，作者的书似乎是关于现代软件工程中的挑战和解决方案的复杂对话。

我想根据书中提到的内容和我作为软件工程师的个人经验，分享一些关于如何更快地编写更好代码的基本技巧。

人类代码

“代码的主要目标是与人类交流思想”

这是您开始编写代码时最重要的原则，但很多人都忽略了它。我见过可以编写复杂算法行的天才同行，但他们的行只有他们可读，而对其他人完全隐藏。我们确保遵循某些模式和原则的代码可读性，所以明天我们可以理解我们自己的程序行，或者其他人可以接受并继续工作。这不仅适用于人们经常变化的公司，而且适用于开源项目甚至你自己的宠物项目，这些项目可以发展并需要开发人员的额外帮助。

想想史前岩画：它们是几千年前铭刻的，但直到现在我们才明白其中的信息。

测试驱动开发

可测试性强烈鼓励模块化

随着代码的增长，保持其可读性意味着使其模块化，将代码分成模块，然后在需要的地方逐个导入它是许多工程师日常开发过程的一部分。开发人员必须能够测试每个模块，因此如果任何增量导致错误，他们可以注意到它。但这只是故事的一小部分。可测试性确保您的模块足够分离。换句话说，经验法则是模块的测试集旨在检查应用程序的特定功能。如果这不是真的，那么也许必须修改他或她的代码。

开发正确的模块化代码的方法之一是遵循测试驱动开发范式，这意味着首先您为每个模块开发测试用例，然后编写代码。因此，您更有可能发现模块中关注点分离的问题。

避免自欺

编写应用程序迟早会涉及一些错误修复过程。在分析错误时，我们中的许多人看到了明显的原因并立即着手解决。但这可能非常具有欺骗性，好像问题的根本原因在其他地方，那么您只是浪费了您的时间和资源。它经常发生在我身上，所以有时我会因为沮丧而将我的代码搁置好几天。但是每当我回来分析问题时，最终它都会很容易修复和清理代码。简而言之，不要让你的第一个假设欺骗你，否则你最终将无法完成你的最后期限和动力。

高性能

“如果你真的对代码的性能感兴趣，不要猜测什么会快什么会慢；量一下！”

David Farley强调了在软件开发过程中经验丰富的重要性。他的观点很简单：做事实核查，而不是仅仅依靠一些理论假设。例如，我们大多数人都知道多线程程序通常用于增强应用程序的性能。但这适用于所有情况吗？绝对没有！即使在一些微不足道的情况下，单线程程序也可以快几倍。简而言之，我们确实根据理论和经验设计了高性能的应用程序代码，但它必须通过数十次测试和测量来验证。事实上，在大多数项目中，度量是软件工程过程的重要组成部分。

拥抱变化，但明智地重写你的代码

“好的团队可能会在几个月内重写他们负责的一半软件；表现不佳的团队可能永远不会重写一半”

当我们编写代码时，随着我们学习和理解我们在一段时间内解决的问题，一次又一次地重写它们是很常见的。但我们必须能够明智地做到这一点，这样它就不会花费我们太多。因此，我们的耦合和代码内聚方法对于维持稳定的发展是非常必要的。例如，如果我们使用抽象（即抽象对象）来隐藏意外的复杂性（即处理与数据库的连接的一段代码，其中包含许多不受您控制的错误）并隔离第三方系统或库，那么我们很容易回来替换代码。这里的关键是重写你的代码是正常的，我们必须能够接受这种变化，但是我们必须学习如何设计我们的代码，以便在必要时更容易修改它（提示：问问自己你的代码是否足够可测试？）。

最后的笔记

在我的软件工程职业生涯之初，我的清洁架构和清洁代码。经过多年的经验，阅读David Farley的《现代软件工程》，感觉就像是从现代软件开发动态的角度对类似主题的延伸和探索。我建议大家在空闲时间阅读这些书籍。翻阅这些页面似乎是在短暂的休息时间与作者在办公室厨房就软件技术进行有趣的对话。

【更多阅读：禅与计算机程序设计艺术】

1. 清洁代码之道：一份实用关于如何编写和维护干净整洁的好代码的的方法 The Art Of Clean Code

2. 来自软件架构大师的 4 个真理

3. 程序员架构修炼之道：软件架构设计的37个一般性原则

4. 软件架构设计的核心：抽象与模型、“战略编程”

5. 软件架构的本质

6. 快看软件架构风格总结: 各种历史和现代软件架构风格的快速总结

7. 软件架构师成长之路: Master Plan for becoming a Software Architect

8. 软件架构设计杂记:  好作品是改出来的,好的代码是不断重构打磨出来的, 心性是历经艰难困苦修炼出来的

Write Better Code Faster: 5 min read

Trivial tips on how to code faster without compromising quality

Recently, I’ve read “Modern Software Engineering” by David Farley, which elaborates on durable principles at the heart of modern software development. I think this book is a great source for both experienced and junior engineers, though from different perspectives.

Fresh developers will find the book as good guide on how to design & develop a software without reinventing the wheel. Mr. Farley gives hands on instructions how to make reasonable decisions when you’ve just started writing first lines of your application code. As for an experienced engineer, the authors book would seem like a complex conversation about challenges & solutions in modern software engineering.

I want to share a few fundamental tips on how to write better code faster based on what was mentioned in the book and my personal experience as a software engineer.

Code for humans

“The primary goal of code is to communicate ideas to humans”

That is the most essential principle when you start writing your code, but yet many people are missing it. I’ve seen genius peers who could write complex lines of algorithms, yet their lines were readable only for them, and completely hidden for others. We ensure code readability adhering to certain patterns & principles, so tomorrow we can understand our own lines of program, or others can pick it up & continue working on it. And it is true not only for corporations where people change quite often, but also open source projects & even your own pet projects, which can grow & require additional hands of developers.

Think of prehistoric petroglyphs: they were inscribed a few thousands years ago, but yet we understand the message until now.

Figure 1: Prehistoric petroglyph in Acacus Mountains of Sahara, Libya

Test Driven Development

Testability strongly encourages modularity

As your code grows, keeping it readable means making it modular, Separating code into modules and then importing it piece by piece wherever needed is part of daily development process for many engineers. Developers must be able to test each module, so if any increment causes a bug they can notice it. But this is just a small piece of the story. Testability ensures that your modules are separated enough. In other words, rule of thumb is that the set of tests for a module are aimed at checking app’s specific functionality. If it is not true, then maybe one must revise his or her code.

One of approaches to develop right modular code is to follow Test Driven Development paradigm which means that first you develop your test cases per each module and then write your code. Thus you are more likely to spot problems with separation of concerns in your modules.

Avoid Self-Deception

Writing an application will soon or later involve some bug fixing process. When analysing bugs, many of us see obvious causes of it and jump on solution immediately. But it may be very deceptive as if the root cause of the problem is somewhere else then you’ve just wasted your time & resources. It happened to me very often, so that sometimes I would leave my code for days out of frustration. But whenever I came back and analysed the problem, it would be an easy fix & clean code in the end. In short, don’t let your first assumption to deceive you, otherwise you will end up with failing your deadlines & motivation.

Figure 2: Liam Neeson fixing bug

High-Performance

“If you are really interested in the performance of your code, don’t guess about what will be fast and what will be slow; measure it!”

David Farley emphasises the importance of being empirical in the process of software development. His point is simple: do fact checking instead of relying purely on some theoretical hypothesis. For example, most of us know that multithreaded program is usually used to enhance the performance of our application. But is this true for all cases? Definitely no! Even in some trivial cases, single threaded program can be several times faster. In short, we do design high-performance application code based on theory & experience, but it must be validated through dozens of tests & measurements. In fact, measurement is an essential part of software engineering process in most of the projects.

Embrace the change but rewrite your code wisely

“Good teams will probably rewrite half the software that they are responsible for in months; low-performing teams may never rewrite half”

As we write our code, it is quite common to rewrite them again and again as we learn and understand the problem we’re solving over some time. But we must be able to do it wisely, so that it doesn’t cost us too much. Therefore our approach to coupling & code cohesion is very imperative in sustaining stable development. For example, if we use abstractions (i.e. abstract objects) to hide accidental complexities (i.e. a piece of code dealing with the connection to the database which entails a number of errors that are not under your control) and isolate third party systems or libraries, then it will be very easy for us to come back and replace the code. The key here is that rewriting your code is normal and we must be able to embrace the change, but we must learn how to design our code so that it is easier to modify it if necessary (hint: ask yourself whether your code is testable enough?).

Figure 3: Super hero dealing with an old code

Final notes

I have read Robert Martin’s Clean Architecture & Clean Code in the beginning of my Software Engineering career. After many years of experience, reading “Modern Software Engineering” by David Farley feels like an extension and exploration of similar topics from the perspective of modern software development dynamics. I suggest you all to read these books in your free time. Going over those pages seemed like having an interesting conversation about software technology with the author in the office kitchen during short breaks.