It’s a metaphor.
One of the principles of agile software development is the use of metaphors. I copied it here.
Programmers are a community, and when we say a community, we must mean that it has something in common, otherwise we can’t call it a community. And every group must have a shared value, otherwise can not form a group.
What do we mean by shared values?
For example, people who believe in Christianity, they come together as a group, what are their common values? Or, to put it another way, what is guiding them?
The Bible, of course.
Every Christian holds the Bible as the most sacred thing, and it’s the norm for Christians to follow the teachings of the Bible, right.
Similarly, we programmers, of course, have our own bibles.
So as a programmer, when you’re writing code, do you ever think about what your bible is?
Starting this week, I’ll be explaining my understanding and thinking about the way to code. This is the first part: The Programmer’s Bible.
Technology is just a tool
Because of my past experience, my coding experience has traversed the back end, the mobile end, and the front end, so I know what the daily work of programmers in almost every direction looks like.
Of course, if we talk about the technologies involved in each of these directions, they are certainly different, and even the technologies do not overlap much.
The people on the back end mostly use Java and work with the Java ecology, and their vocabulary is: concurrency, clustering, caching, performance, etc
There are several types of people on mobile, iOS,Android Native, React Native or Flutter, and they use different technologies such as OC,Java or JavaScript
The front end is mostly dealing with JavaScript or TypeScript, and they are more concerned with compatibility and experience, style, etc
Doesn’t seem to intersect too much?
Not at all. As far as I’m concerned, there’s no difference. No matter what technology direction I work in, my principles are pretty much the same.
Imagine, what do you think about technology?
You’ll find that in your coding career, you’ll encounter all kinds of technologies, new languages, better frameworks, more functional syntax, technologies for big data, etc., and you’ll probably think that you’re familiar with certain languages and that you’re better off using them.
I think this is a complete mistake.
I think of all the languages or frameworks or all the open source stuff as tools, they’re all my tools. Think of myself as an architect, and I have a lot of tools that I can think about when I’m building.
I’ve never limited myself to what I use, and I’ve done that over the years, going from being a backend architect, using Java, writing an Android program in Java, writing an iOS program in OC, writing a cross-platform desktop program in TypeScript, I went into the world of responsive programming with Kotlin+ vert. x, and these languages, technologies, and frameworks were just my tools.
I had a whole bunch of tools, and I realized that when IT came time to write the next program, the next problem, I actually had a whole bunch of tools to choose from.
As a programmer, I’ve never been pious about a particular language, but I think programmers have their own religious beliefs, and I’m looking for a coded “Bible” that I can religiously follow, protect, and defend.
This is the programmer’s bible.
Three principles
I think that as a programmer, the most sacred of all are the three principles, which almost completely define how a programmer should code.
It is not an empty theory, every principle can be achieved through technology. Whether or not they are followed is also what makes a good programmer.
These three principles are the programmer’s bible,
They are:
- Write code that meets your requirements
- Write maintainable code
- Write easy-to-read code
Code that meets the requirements
This should be pretty easy to understand.
The code we write is not created out of thin air; it must address a specific need.
Of course, requirements can come from many sources, such as customers, product managers, or project managers, perhaps from some of their own ideas. It doesn’t matter.
But the bottom line is this: Write code that meets your needs
Writing code is the process of implementing a contract. The people who make the requirements expect us to understand and implement their requirements. They don’t understand and understand how we implement their requirements with the code, but the important thing is that they think they define a contract with us.
Please use the code to achieve our requirements, please
If you can’t do that, I don’t think you should call yourself a programmer.
Write maintainable code
Writing code that works is easy, but writing maintainable code is a huge challenge.
Many programmers have gone through the same pain, perhaps getting into a piece of code that is outrageously poor in terms of maintainability, but still has to move on. As a result, the common situation is that fixing a BUG becomes more difficult and leads to more bugs, and adding a stable new feature becomes less and less possible. Managers who don’t understand the code are also overwhelmed, so it becomes inevitable to add new people to a bad project, or to extend the workday, but in most cases it doesn’t get any better, and it could get worse.
Many programmers must understand what I am talking about, right? I have experienced similar projects, and I remember that the whole team spent almost several months fixing bugs. Every day, there was a special person to count the daily BUG fixes, and the leaders also cheered for everyone.
But in the end the project failed irreversibly.
Of course, we won’t go into specifics, but whatever it is, as programmers, we can’t deny the fact that:
The lines of code that we are responsible for writing make it harder to divide and collaborate, like a bunch of people who hate each other.
This is a typical example of non-maintainable code.
As a programmer, you are responsible for making your code maintainable. Of all the features of technology, I think one of the most important is:
The code must be maintainable
As a programmer, you strive to write maintainable code.
Write easy-to-read code
Code readability is divided into three levels:
- Machine readable code
- Code you can read
- Code that other people can read
No matter how poorly written your code is, as long as it takes an input and produces a desired result, your code is machine readable.
The next level of requirement is to make yourself understand. A lot of people think, how can you write code that you can’t read?
, of course, I’m not let you to read you write the code last week, but let you read your past, you already have a period of time is not involved in the code, I believe that there must be some people may be in their past to write the code may not be very understand, you have to be difficult to think about to understand what is first write the code.
The highest requirement is to let others understand, in our group of programmers, there is almost a common denominator, is not willing to take over other people’s code. I think one of the main reasons for this is that code written by others is not easy to read.
This also reflects the difficulty of writing code that can be read by others.
To write code that is easy to read, you have to write code that is concise, you have to write code that is elegant, and there are very few programmers who can do that.
They’re the Bible.
Of course, any programmer who follows and does the above three principles is a good programmer, and vice versa.
So I call these principles “the Bible.”
With a little thought, these principles almost invariably apply to the way you code, whether you’re back end, front end, mobile or any other technical direction.
This is the highest principle I think of as a programmer.
I keep them in mind, reverently observe them and guard them.
Do you ever think about your principles as a programmer?
With principles in mind, let’s talk about mission
So that’s the principle that I’m going to talk about in this lecture. As a programmer, you have to have principles that you feel you have to live by.
Once you can establish the right principles for yourself, it will force you to become a better and better programmer, because only good enough can protect your principles.
I find it hard to imagine a bad programmer writing code that meets requirements, writing code that is maintainable, and writing code that is easy to read.
Your principles are always there for you. Once you have them, what’s next?
The next step is mission. Have you ever thought about the question, as a programmer, what is the mission of coding?
Next, continue to talk about the way of coding: The way of coding (2) : the mission of coding
Visit [micro speech code path] official website taoofcode.cc – use our small power to spread the code path
Visit myDDD – Full stack Domain Driver website: myddd.org