开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《破碎 ParticleEffectsButtons》
今日推荐英文原文：《Want to Be a Good Programmer? Learn How To Write》
今日推荐开源项目：《破碎 ParticleEffectsButtons》传送门：
GitHub链接
推荐理由：为了把页面弄得华丽到花里胡哨，应对不同场景使用不同动画就显得很有必要。这个项目为按钮的显示和消失加入了相当好看的粒子效果，甚至还为消失的速率提供了不同的曲线，在切换按钮显示状态时就显得相当华丽，而且不仅适用于无框架页面，对于主流的 Vue 等这些框架也有相应的库推出，足够满足各种框架下使用的需求。
今日推荐英文原文：《Want to Be a Good Programmer? Learn How To Write》作者：Robert Quinlivan
原文链接：
https://medium.com/better-programming/want-to-be-a-good-programmer-learn-how-to-write-a1223fe1395d
推荐理由：写代码时试着同时为机器和人类而写，忽视任何一方都可能为工作带来麻烦
Want to Be a Good Programmer? Learn How To Write
Being able to read and write automatically gives you a leg up in becoming a better programmer
Whether you have decades of experience with programming languages or you’re just starting to learn, if you’re reading this article, then you already have some experience in another language: the English language.
I’m going to argue that being able to read and write automatically gives you a leg up in becoming a good programmer.
Having a solid grasp of communicating via written language teaches you an important skill in programming that has nothing to do with computer science per se and everything to do with expressing ideas.
We Spend More Time Reading Code Than Writing It
Code is not written for computers. Please write that down and underline it, and whisper it to yourself before you go to bed each night: Code is not written for computers.
Yes, the code you write will eventually (after going through a compiler, a byte code virtual machine, an interpreter, or all of the above) turn into instructions that a computer executes.
But that’s not the only reader the code has.
When a computer reads your program, it pulls a model of your code into its memory and CPU registers.
When a human being reads your code, they construct a model in their mind from the structure of your code.
Someone who has never seen your system and knows nothing about it will often skip the documentation and go straight to the code. That’s because code is still the best abstraction we have for describing how software works.
Think of a program as simultaneously two things:
- A valid set of instructions for a computer to accomplish a task.
- A structured essay for your code’s future maintainers on the topic of how this system works.
A Major Cost in Software Is Maintenance Cost
Programs are not static things. They are malleable. They are soft. They change with new product requirements, new technology, to implement improvements, and, of course, to fix bugs.
We rarely get to write detailed blueprints of our programs before we design them. On the contrary, in software engineering, the design is very often a result of development rather than the other way around.
And this design process never really ends. Long after the initial development of software, we will still be making changes. Ninety-nine percent of the time, the code we write will be modified in some way in the future. We call this the maintenance of a software system.
Your system could be a complex production system with hundreds of developers contributing dozens of commits a day via source control. Or it may just be a script that we wrote for our own use that we have to change years later.
In either case, there is some modification process that will take place, some of it predictable, and some of it not. The ease with which you or your team can implement changes is the maintenance cost of the system.
And it is often a major cost. Clunky old systems written decades earlier can seriously derail a project if changes in that old system require a large investment of developer time. Dependencies on complex, poorly maintained legacy systems can force us to reimplement data models and commit to expensive rewrites, just to get around thorny code.
Maintenance cost, in short, is a problem.
Programming Like a Writer
I know what you’re thinking. Isn’t this why we have documentation? We write docs for classes. We have inline documentation UIs like Javadoc and Sphinx. Sometimes we even have a dedicated department of people who specialize in technical documentation. Doesn’t that make our code more maintainable?
Yes, it helps. But it’s a drop in the bucket.
Structuring code in an intelligible and readable way goes way beyond documentation. Documenting every class and function in your project doesn’t automatically imbue your code with intelligibility.
If you write a program with zero consideration for design patterns and slap some comments on your classes, you haven’t written readable code.
But I’m not going to give you a list of design patterns to follow. You can look those up for your language of choice.
Instead, I want you to think about what makes a piece of writing in English readable. Good writing tends to have these qualities:
- It doesn’t use difficult dictionary words. It uses a simpler word whenever given the choice.
- It is geared toward its reader. A technical document aimed at a general audience will take care to define jargon or avoid it altogether. A horror novel will follow the conventions of that genre to satisfy fans.
- It says a lot in as few words as possible.
- It stays on topic. If it starts to wander off into another, related topic, it might make a reference to another chapter or a footnote where that topic is covered in proper detail. It doesn’t just prattle on in run-on sentences.
- It is expressive. Its structure suggests the broader meaning of the piece. It has a broader point.
All of these rules have the same goal in mind: for the reader to understand the subject matter. Good writing gets out of the way and lets the reader focus on what is being communicated.
By analogy, we can say the same thing about a well-written program:
- It doesn’t use special or unknown library functions and API calls that the average programmer is not familiar with when there is a simpler alternative.
- It avoids patterns that the maintainers of the project won’t be familiar with or will find overly challenging. (For example, trying to port C++ patterns into Java.)
- It is terse and to the point. No fancy syntax or tricks.
- Through the use of modularity and abstraction, it keeps modules small and focused on doing one thing and one thing only. It follows the UNIX design philosophy of small, composable pieces.
- It is expressive. Its patterns suggest the actual purpose of the system, and its structure is predictable. Once you learn how the program is structured, you also have learned how the system works.
What Does ‘Readable’ Mean?
The concept of readability is often brought up when talking about how expressive or intelligible our code is. What do we mean by readable?
For me, readability implies that:
- A person of average experience can pick up the project and figure out how it works just by reading the code.
- I myself can explain the structure of modules in my code and what each component’s purpose is in the broader program. I like to do this in the form of data flow through the system. (E.g., a call starts over here, hits this class, then it ends up over here.)
- The structure of the code suggests where and how a given change would be made.
Readability is all about lowering the barrier to entry for working on the code. The easier it is to read, the easier it is to make changes. That addresses our problem with maintenance cost.
Why Do We Ignore Readability?
We have a tendency to be overly focused on the basic functionality of our code. Churning through difficult algorithm questions has become a staple of the interview process, and résumés emphasize more algorithmic or data-oriented project work.
Certainly, our code needs to function, and algorithmic problems are challenging to solve. But just making code work is hardly good enough. It is a bare minimum requirement. Code also needs to be readable.
The cost of maintaining a complex system is often brushed aside as an annoying reality that we would prefer to forget about. But we do so at our peril. Unreadable code leads to rusty holes in our system which can, over time, slow the whole machine to a grinding halt. We need to be careful to patch up those holes but also design our own code to avoid leaks.
It also follows that we should place more emphasis on the skill of reading code and improving its quality by rewriting sections of it. An interesting interview question might be to provide a working program and ask a candidate to refactor it, step by step, to improve its readability.
Readability Comes From Revision
To iron out all the problems in this article, I spent time trimming and restructuring it. I also had a copy editor look over it before it went to press.
We should do the same with our code. When you program, make sure you are doing your own personal due diligence to find the correct design patterns for the problem you’re solving. Make sure that you have a rigorous code review process to not only catch defects, but also identify readability improvements we can make in working code.
Conclusion
There is a lot of overlap in the skills of reading and writing in English, and reading and writing in code.
Learning how to read and write effectively allows us to communicate our ideas broadly by choosing the best phrasing and structure for our words, given our audience’s needs.
That skill of expression translates well to the art of programming, and it’s something that all programmers should take care to cultivate.
The daily work of a programmer isn’t all about number-crunching and algorithmic analysis. It’s largely about solving a problem in a way that allows other programmers to contribute to the code you produce. That means we have to take care to produce code that is easy to understand and cheap to maintain.
And maintainable code, my friends, is readable code.
下载开源日报APP：
https://opensourcedaily.org/2579/
加入我们：
https://opensourcedaily.org/about/join/
关注我们：
https://opensourcedaily.org/about/love/
