Starting from Dash iOS open source, don’t pursue perfect code too much

(Screenshot of Dash iOS source code)

Some time ago, the author of the well-known Apple platform documentation tool Dash open-sourced its iOS version. This is the result of a dispute between the two parties after Dash was suddenly removed from the App Store. We will not comment on this matter, but people are happy to see open source. After the iOS version of Dash was open-sourced, it received praise from some developers, but unexpectedly, its code caused some controversy.

In the minds of developers, open source means showing off and pursuing code, but Dash can be said to have shattered this view. But as Turadin said, how well the code is written does not hinder its commercial success.

What do you think of the pursuit of hacker codes?

We found an article shared by Daniel Irvine, a senior programmer in London, who believes that hacking code should not be pursued.

introduction

The characteristic of ***ists is that they excessively pursue perfection in one thing. They are never completely satisfied with anything, so they often fall into deep contradictions, not knowing that there is no absolute perfection in the world. They devote their energy to every aspect of work and life, and strive to improve it, and never get tired of it. What about ***ists among programmers?

Many programming cultures are built on the ideal of the best code: code that not only works, but is also clean and elegant. We pride ourselves on cleverly building solutions to difficult problems. However, this kind of maximalism can be detrimental to a team's success, as it often leads to personal disagreements.

However, there is no universally agreed upon standard for best code. Everyone has a slightly different aesthetic for best code, which means that each of us has our own idea of ​​what best code looks like. If we are all driven by maximalism - wanting our code to look the way we want it to look, then we will end up at odds with our teammates as we each fight against each other to make the codebase look the way we want it to look.

As I've grown as a programmer, I've discovered a few tricks that can help teams avoid conflicts over hacked code. Let's take a look at them.

Don't be bound by dogma

The only requirement for a code base is that it is usable. A simple way to verify that it is usable is if it has full test coverage and passes. Beyond that, every measurement is subjective.

When you read other people's code, don't think about how it would be if you wrote it. Don't try to rewrite the code in your mind, just let it exist the way it is.

Reduce the standards you set for your code

Tab or Space? Two or four spaces? Put your opening bracket on the same line or on a new line? I wonder if there would be no such debate if there was only a single programming language? The standard way to solve this problem is to set coding standards for the team, which will bring consistency to the team's code.

Unfortunately, it is difficult to come up with complete coding standards. There will always be gray areas that lead to potential disagreements, such as naming, patterns, object modeling techniques, etc.

Moreover, the rules set by their team sometimes backfire.

I was on a team that had the following rule for coding standards: "Functions should be no longer than 7 lines of code." In hindsight, this rule might as well not have existed. While I still agree with it, it caused a lot of confusion and debate. People had to constantly think about it. Some people on the team never believed in it. All in all, our team spent a lot of time and energy trying to maintain this rule.

Think about how much better that time would have been spent pair programming or improving code together. All rules have a price, and despite them, you may still have disagreements.

While I still write code according to the rules of short code—usually fewer than seven lines—I disdain writing code according to those rules.

Let the codebase be its own standard, rather than writing down rules.

Don’t get hung up on pull requests

I usually merge pull requests quickly, even if it's a big change to the code. There are two reasons for this. The first is that waiting for a PR to be modified is tedious and demotivates team members. The second point is more subtle, it's very important that the code base remains malleable: meaningful, ready, and expected to change. However, the "pull request first" culture hinders this. It promotes the concept that code in the master branch is "gold" and should never be changed again. If we allow untested code to make it to the trunk, we will encourage a higher rate of change. The team learns to always ask: "Is the code I'm looking at clean enough?"

This is a bit counterintuitive: allowing the main program to write insecure code can actually improve the quality of the program.

So, what's a better way to review pull requests?

My strategy is this. I'll first read through the entire set of changes, noting anything that might be important. Then I'll prioritize his feedback, limiting it to three suggestions at most. I'll ignore the rest.

I rarely comment on style issues, like misplaced whitespace or indented parameter lists. If the code is extensible, someone will probably clean it up later. In the meantime, these style issues aren't hurting anyone.

Looking at the world

For anything more than a few dozen lines of code, the best is in the eye of the beholder. If you expect everyone to solve a problem in exactly the same way, you're making a mistake. If you have a grand vision for your code, you're going to be disappointed.

Give your teammates space to develop designs and code that they agree on, and encourage everyone to play an equal role in the design of the system.

Don't argue with your team when they write code that's different from what you wanted. Remember, maintaining healthy working relationships within the team is valuable in the long run, so you may have to sacrifice your personal vision for quality.

Programmers should spend some time every day reviewing and reflecting on the development of their development skills. Think about the efficiency of each day for yourself and the team. The work done this month may not be done next month. This is especially true when the growth of team skills is from novice to expert. So make sure you take fewer detours, because the initial detours will be more than the help provided by others.