Starting with Dash iOS, don’t be too obsessed with perfect code. I read it in the mood to kill him, serious nonsense. Each paragraph puts forward a correct concept first, and then expands to express the concept of harm. This kind of writing technique is shameful.

The pursuit of code quality is a good programmer’s own requirements

A lot of programmer cultures are built on the ideal of perfect code: code that not only works, but must also be clean and elegant. We pride ourselves on cleverly building solutions to difficult problems. However, this kind of perfectionism can be detrimental to team success, because perfectionism often leads to personal disagreement.

I think it’s a very natural goal for any craft, craft, practitioner to want to make it better. First of all, the author’s standards are very low. And I think that running, clean, elegant code is perfect, right? It’s just good not perfect. Perfectionism is bad for team success. Is 20 people writing with their eyes closed good for team success? Is the software prone to failure because of poor quality, poor performance, poor maintenance, unstable functionality, or is the software prone to failure because it is easy to maintain, iterates quickly, and is released a few days late? Some teams fail because they’re too perfectionist and that’s why they’re not perfectionist. Right? Excuse me?

There are no perfect code standards that everyone agrees on.

Because you’re not going to make all the money in the end, why don’t you? You’re a salt fish and no one else can dream, okay?

The unremitting pursuit of many people in this world, constantly pushing themselves, the pursuit of perfection to promote the world to become more beautiful. You can’t stop doing something just because it’s less than 100 percent. Good people push themselves to the limit. This is what a good man demands of himself.

There may be limitations, there may be compromises, and I think as an engineer, you have to make sure that your code is quality, even if it’s not “perfect,” but you have to make sure that your code is quality, unless you’re a salt fish with no ideals.

Striving for perfection is not about the details of a business project

We strive for code quality, but we don’t have to write perfect code to commit. You can iterate as you write. It can be a refactoring of the realization. Maybe our project also has a time limit. Of course, we need to get the functionality done first, but that’s the difference between a good engineer and a mediocre engineer: mediocre engineers write mediocre code, and good engineers do the best they can with these compromises.

Once again. Code quality is a reflection of a person’s ability to constantly strive for perfect code. If your goal is always to run, you can’t write good code.

The standard of code is not that it can be used, but that it can be maintained

The only requirement for a code base is that it be available

That would make a gym teacher cry. Which product around you is designed to work?

It’s shortsighted to think that code can pass just because it works. The life cycle of a software project doesn’t end when you write the feature. As software projects mature, requirements may change and new requirements may be added. It is also possible that you write code that someone else uses and someone else misunderstands your Api and causes problems with the entire software. It is possible that you write logic that is just not found (such as thread synchronization) and later debugging personnel. So the goal is just to be useful, not to think about the later issues, and then it will take more time. Striving for perfection means counting those maintenance costs into the present. The best outcome is to write bug-free maintainable code now.

Big companies value software quality not because it’s cool, not because they’re bad engineers, but because it’s the best way to do it. Instead of going to see what these great top companies are doing, just sit at the head of the village and listen to the village party secretary?

How can you maintain a hundred styles written by a hundred people without a code specification?

I was on a team that had a code standard that said, “No more than 7 lines of code.” In hindsight, this rule might as well have been absent.

Such silly rules are certainly better than nothing, but that doesn’t mean the code specification isn’t important. Specifying the maximum length of a code misses the point: a function should only do one thing. We should see if the function is too complex to write this long. It’s not as simple as saying no more than 5 lines or 10 lines.

Specifications can be flexible to change, it is difficult to say a space or a TAB is good, but more code for others to facilitate maintenance of the need to have a unified specification, the context of the convention. If everyone were to code in their own way it would be like individuals speaking their own dialect all over the country. Yes, that can be heard, but considering the engineering efficiency, it’s not cost-effective. The only difficulty is that a lot of people probably don’t know what to make uniform rules.

Merge invalid code to save for future change?

I usually merge pull requests quickly, even if it makes a big change to the code. There are two reasons for this. The first is that waiting for PR changes can be excruciating and can demotivate team members. The second, more subtle point, is that it is important that basic code remain malleable: meaning, preparation, and expectation to change. If we allow imperfect code to be the backbone, we encourage a higher rate of change.

Change my world view. Is waiting for PR demotivating? Do you need a PR for six months? It is also a question of quality. Usually a programmer commits at least once a day. Two or three times a day is normal. How often do you review code written by a programmer in half a day? I think either your review efficiency is wrong or the code he wrote is really incomprehensible.

The second point I think is a little funny, the summary is: when the code is written badly, the maintenance people will change it and increase the rate of change. Think about it like it makes sense!




Good engineers are also valued for making people around them better

Don’t argue with your team when they write code that is different from what you want. Keep in mind that healthy working relationships in a team are valuable in the long run.

I didn’t expect you foreigners to watch the news broadcast, build a harmonious society ah.

Why code Review? A good programmer can point out code problems and improve quality. As the technical lead, if you don’t care about the code, I’ll do it. Why should review every direct merge? Everyone has permission to push to master. Boost happiness?

Every engineer has worked their way from novice to journeyman to master. We will certainly get help from more experienced people in the middle, which is also the embodiment of the open source sharing spirit we advocate. I think if every good engineer doesn’t refuse to help the engineer around him who wants to write good code. This is also a kind of spiritual inheritance.

The last

Some code is bad, just bad. It has nothing to do with whether he succeeded or not. Since we write code for a living, we should pursue code and have our own aesthetic judgment about it.

A man’s bad character has nothing to do with his money. Dash’s success simply shows that such code quality can deliver a stable product with the amount of code on the project. That’s all. It’s not enough.

Code quality is really just the bottom line. At this bottom line, it is possible to talk about stability, scalability, performance and architecture. Da Vinci would not have found it admirable to paint an egg.

Perfect Code is an Illusion