Binary World Builder Programming Maxim

1. Keep It simple and straightforward (Keep It Stupid)

2. Do not self-replicate (Don ' t Repeat yourself)

3. The competent person solves the problem. The wise man bypassed the question (a clever person solves a problem. A wise person avoids it) –einstein

4. Silence will be understood as endorsement (silence is construed as approval) (Picked from Kevin blog)

I didn't see anything! I didn't see it!

"Broken Window Theory" and "become inertia theory" has a macroscopic connection.

The programming community is like a real community. Each work is a microcosm of a developer. The more bad code is published, the easier it is to reflect the status quo. If you don't work hard to write good, neat, and stable code, you'll be with bad code every day.

Similarly, if you see someone writing bad code, you're going to have to ask that person. Note that wit should be on the pitch at this time. In general, programmers are willing to admit that they do not understand the software development, and will thank you for your kindness. Helping each other is good for everyone and turning a blind eye to the problem will only make the problem persist.

5. No smoke (there is no smoke without fire)

Code smell a Chinese translation is generally a "bad smell", or "code taste", it is a hint in the code somewhere there is a mistake, developers can use this smell (odor) in the code to hunt down the problem.

The code is poorly designed and can be seen in some places. Like what:

A. Super-large or super-large functions

B. Large Annotated Code

C. Logical repetition

D. If/else nested too deep

programmers often call them code smell, but I personally think the name "code Alert" is more appropriate because it has a higher sense of urgency. Improper handling of the fundamental problem will eventually get burned.

6. First think well, post programming (Think, program later)

The term "agile development" has been frequently abused recently and is often used by programmers to disguise their poor planning/design phases in software development. We are the designers, we should be happy to see that the product has made substantial progress in the proper direction. But unexpectedly, UML diagrams and use case analysis do not seem to satisfy our wishes. So, when you don't know what you're doing or don't know where you are, our developers often write code in a muddle.

It's like you're going to eat, but you don't even think about where to eat. Because you are so hungry, you can't wait to find a restaurant and set up a table. Then you get in the car and you think (find a place to eat) along the way. It's just that it takes more time, because you're going to have more U-shaped corners and parking in front of the restaurant, and maybe the last time you wait is too long to eat. To be exact, you should finally be able to find a place to eat, but you may not be eating the food you want, and it may take longer than you would have to order at the restaurant you want to go to.

7. Never assume that the computer assumes any premises for you (never assume the computer assumes anything)

8.Leeroy Jenkins Behavior

in the 1980s, Toyota's line-of-assembly lines became famous for its innovation in defect prevention methods. Each member found to have a problem in his or her own department has the right to suspend production. This approach is intended to be a more difficult and costly repair/replacement/recall issue that would be subject to immediate production, problem solving, and no further production.

programmers always make productivity the same as the wrong assumption of fast coding. Many programmers go directly to code design without hesitation. Unfortunately, this kind of Leeroy Jenkins reckless approach will lead to the development of software is very sloppy, poor code needs to be constantly monitored and modified-it may be completely replaced. Ultimately, productivity involves more than just the time it takes to write code, but also the time it takes to debug. A little inattentive will be "penny Wise lost Watermelon." Pound foolish )

Leeroy Jenkins Behavior: A player in the Wow game regardless of everyone alone to meet the enemy, leading to the eradication regiment.

9. Don't be desperate (relying on someone too much)

a common element of a software development team (bus factor) is the total number of core developers who will affect the overall project process. For example, if someone gets hit by a car or a child or someone is on the job, the project may be out of order or even put on hold.

bus factor refers to the common elements, which is a metaphor for some common factors in the development process. If crowded bus factor more, bus is more unstable, so to control the bus factor, so as to avoid problems.

In other words, what would you do if your team suddenly lost a main member? Is the business still on or off?

Unfortunately, most software teams are stuck in the latter case. These teams develop their developers into "domain experts" who will only handle their own areas of expertise. At first, this seems to be a reasonable approach. It works well for automotive assembly lines, but why not for the software development team? After all, it's not always possible for every member to master the nuances of the program, right?

the problem is that developers are not easily replaced. Although the "drawer method" is effective when each member is available, the drawer method immediately collapses when the "domain expert" suddenly fails to work due to a change in personnel, illness or sudden accident. (So,) the software team has some seemingly superfluous backup forces that are essential. Code review, pair programming, and shared code are used successfully to create an environment in which each developer is at least ostensibly familiar with the parts of the system that are outside the realm of their own expertise.

10. Broken window theory (broken window theory)

in the book "Pragmatic Programmers," there is a passage explaining the "broken window theory": Don't Keep "broken windows" (poor design, bad decisions or bad code). Find one and fix one. If there is not enough time to make the proper repairs, keep it up first. Perhaps you can put the offending code in a comment, or display an "not implemented" message, or replace it with virtual data. Take some measures to prevent further deterioration. This shows that the situation is still under control.

we've seen a neat and tidy system crash immediately after the "broken Window" appears. While there are other factors that drive software crashes (which we will be exposed to elsewhere), ignoring the "broken window" will definitely speed up the system crash faster.

In short, good code can lead to good code, and bad code can lead to bad code. Don't underestimate the power of inertia. No one wants to tidy up bad code, and no one wants to mess up the perfect code. Write your code and it will be more likely to withstand the test of time.

"Pragmatic programmer", author Andrew Hunt/david Thomas. The book, which is written directly to the program, passes through a growing set of specifications and technology barriers in software development, taking a look at the core process-creating code that users can accept, work, and maintain, on demand. This book contains content from personal responsibility to career development, until the code is kept flexible and easy to adapt to the reuse of architecture technology. From this book you will learn to prevent software spoilage, eliminate the pitfalls of replication knowledge, write flexible, dynamic and adaptable code, avoid the same design, use contracts, assertions, and exceptions to protect your code.

The broken window theory (broken window theory): It is a kind of cognition about the influence of environment on people's psychological implication or inducement. The theory of "broken window effect" means that if someone breaks a window glass of a building and the window is not repaired in time, others may be subjected to some suggestive indulgence to smash more windows. The problem must be rectified and remedied in time.

11. Haste to waste

managers, customers and programmers are becoming increasingly impatient. Everything needs to be done, need to do it right away. Because of this, quick fix issues become very urgent.

no time for proper unit testing of a new feature? Well, you can finish the test run first and then you can go back and test it at any time.

when accessing the Y property, will you encounter strange object reference errors? In any case, put the code in the Try/catch statement block. We're going to catch the big fish!

Is it familiar? This is because we have done it before. And in some cases, it is beyond reproach. After all, we have deadlines, and we have to meet our customers and managers. But don't operate too often, or you'll find your code unstable, with lots of hot fixes, logical duplicates, non-tested scenarios, and error handling. In the end, you either get things done hastily or get things done well.

12. If your only tool is a hammer, you tend to think of everything as a nail.

you see that? I already told you, dynamic records are very effective in this project.

programmers have a tendency to narrow their horizons when it comes to their tools. Once a method "makes sense" on one of our projects, we will use it on all the projects that follow. Learning new things seems to be a torment, sometimes even uneasy. From start to finish thinking, "If I did it the way I did it, it wouldn't be so much trouble." Be sure to abandon this idea and do as we know it, even if it's not the perfect solution.

It's easy to stick to what you know, but in the long run it's much easier to choose a tool that fits the job. Otherwise, it will be incompatible with your career.

13. Two birds in the forest, than a bird in the hand

If you can talk about system architecture and refactoring, then find a time to get things done. It is important to weigh the pros and cons of the changes in order to make things simpler and easier to work with. Of course, brevity is an ideal goal, but there will always be code that can be improved by refactoring. In the programming world, code changes frequently and easily for code. But sometimes you have to make sure that the code is valuable to the customer. So, you face a simple dilemma: you can't stone. The more time you have to refactor the old code, the less time you will have to write the new code. There is also a need to find a balance between improving code and maintaining programs in a timely manner.

14. The greater the capacity, the greater the responsibility

There is no doubt that software has become a fundamental and important part of our lives. Because of this, developing excellent software is especially important. The bug in table tennis is one thing, the bug in the shuttle guidance system or the air traffic control system is another matter. Slashdot once published a story about a small mistake in Google News alone that evaporated a company's stock by $1.14 billion. For other examples, see the 10 serious consequences of a software bug. These examples illustrate how much power we are exercising. The code you write today, whether you want it or not, might someday come in handy in important applications, which is frightening. Write properly qualified code!

Binary World Builder Programming Maxim