2014, 7 ways to become a better programmer

This article is translated by bole online-haofly. Reprinting is prohibited without permission!
Amy jollymore. Welcome to the translation team.

Programmers always make a lot of decisions, right? If your New Year's to-do list is still blank, you can consider using the ideas of the following programmers. Even the smartest people have room for growth. The following is an excerpt from kevlin Henney's 97 things programmers should know.

1. Check your code before blaming others.

Question your preference with others. Tools from different vendors may have different built-in presets or different vendors may provide different tools.

When someone wants you to report a problem that you cannot repeat, check out what they have done. They may do something you don't think of, or do it in different order.

My principle is that if I encounter a bug that I cannot avoid, I will first consider a compiler error, and then I will check whether the stack is damaged. This can be achieved through tracking code, which can effectively remove problems. The problem of Multithreading is another source of errors that is hard to find, usually accompanied by machine errors. When a system uses multiple threads, all simple code errors will multiply. Such compatibility issues cannot be discovered through debugging and unit testing, so simple design is the most important.

In short, before you blame your compiler, please remember Sherlock Holmes's advice: "When you exclude all the impossible, then the rest, no matter how impossible it is, it must be the truth." Dirk Gently also said something similar.

-- Allan Kelly

2. Continuous Learning

We live in an interesting era. With the development of globalization, you must know that a large number of people are competent for your work. You need to keep learning to maintain your competitiveness. Otherwise, you will become an outdated person and always do the same job until you are no longer needed, or the day when the job is outsourced to others cheaply.

So what are you going to do? Some generous bosses will provide training to broaden your skills. Other companies will not give you free time and money to do any training. Therefore, to ensure the stability of your work, you must be responsible for your own education.

Here is a list of methods for continuous learning. Many of them can be found on the Internet at will:

• Read books, magazines, blogs, Twitter, and other websites. If you want to conduct more in-depth research on a target, consider adding an email list or newsgroup.
• If you really want to focus on a technology, you can start to write some code.
• Being a top person in the industry may impede your learning. You must work with your mentor whenever possible. Although you can learn from anyone, you can learn more from people who are smarter or more experienced than you. If you cannot find a mentor, continue to look for it.
• Use a virtual mentor. Find some authors or developers on the Internet. You will like and read everything they write. Subscribe to their blogs
• Understand the frameworks and libraries you are using. Knowing how they work makes it easier for you to use it. If they are open-source, you will be lucky. Use the debugger for one-step execution to observe how they work internally. You will see the code written and reviewed by really smart people.
• When you have done something wrong, Fixed a bug, or encountered a problem, try to find out what happened. Some other people may have encountered the same problem and posted 2 to the Internet. Google is very useful at this time.
• A good way to learn something is to teach and talk about it. When people want to listen to your explanation and ask you questions, you will learn more actively. Use the lunch-'n'-learn method at work, which can be a user group or a local association.
• Join or create a research group (Community mode) or a local user group to study the language, technology, or law you are interested in.
• Go to the meeting more. If you cannot go, many meetings will publish the content online for free.
• Want to work for a long time? Listen to the blog
• Have you ever run a static analysis tool on a code library or have some warnings in your ide? Understand what they reported and why
• Follow the advice of efficient programmers to learn a new language every year. Learn at least a new technology or a new tool. Create a branch to add your idea so that you can use it in your current knowledge base.
• Not everything you should learn must be related to technology. Learning something in your work field can help you better understand your needs and solve some business problems. It is a good choice to learn how to improve work efficiency and how to work more efficiently and less efficiently.
• Back to school

If you have the capabilities of NEO in the matrix, you can directly download what we need to go to the brain. But we do not, so it takes some time to learn. You don't have to study all the time. A little time is enough, such as once a week. We always have to live out of work.

We should not be left behind when technology develops so rapidly.

-- Clint shank

3. Don't be afraid to destroy something.

Everyone with industry experience has undoubtedly worked in an unstable project. This system is very difficult to reconstruct. Usually, changing one place will touch another unrelated place. Every time you want to add a module, the programmer's goal is to make as few changes as possible and be cautious in every version. This is just like building a skyscraper as a building block, which can easily cause disasters. Correct modification is a headache because the system is already ill. It needs a doctor, otherwise the situation will get worse and worse. Although you already know what went wrong with your system, you are still afraid to "break the eggs and cook your omelet ". A skilled doctor knows that a knife is required for an operation, and she knows that it is only temporary and will soon heal. For initial pain, the procedure is very valuable, and patients usually get a better state than before the procedure.

Don't worry about your code. Who will worry if you are interrupted for the time being? Fear of change will bring your project into this state. Taking some time to restructure the project will save you a lot of time. Another advantage is that a team's experience in dealing with this damaged system will help you understand how to make it work. Learn to use this knowledge, rather than conflict with them. Everyone should not spend their time on what they hate. Redefines internal interfaces, reassembles modules, reconstructs, copies, and pastes code, and simplifies the design by reducing dependencies. You can reduce Code complexity by eliminating extreme situations. They usually produce improper coupling. Gradually transition the old architecture to the new architecture and test it while changing it. Trying to perform a major reconstruction on a large project that may cause many problems, these problems may be good enough to give up all the previous efforts in the middle.

As a doctor, you should not be afraid to remove the diseased part to leave room for healing. Attitudes are contagious and encourage others to modify delayed projects. List A list of projects that a team feels good about. Although these tasks may not produce significant results, you have to persuade the management to reduce costs and accelerate development of new versions. Never stop caring about the overall "health" of the Code ".

-- Mike Lewis

4. Be a professional programmer

The most important feature of a professional programmer is his/her sense of responsibility. Professional programmers are responsible for their careers, estimates, schedules, errors, and works. A professional programmer will not push these responsibilities to others.

If you are a professional, you will be responsible for your work. You have the responsibility to read and learn. You have the responsibility to catch up with the industry and technology trends. Many Programmers think this is the job of their superiors. Sorry, this is a big mistake. Do you think the doctor will do the same? Do you think the same is true for lawyers? No, they will use their own time and money to learn. They spent a lot of off-duty time reading journals and making plans. They always update themselves, and we must do the same. The relationship between you and your employer is just to fulfill the contract. In short, if your employer promises to pay you a salary, you have to promise to do the job well.

Professional programmers are responsible for the code they write. If they do not know whether the code will work normally, they will never release the code easily. Imagine if you want to release an uncertain Code, are you still a professional programmer? Professional programmers do not want QA to discover their errors, because they will not release code without strict testing. Of course, QA may find some problems, because nothing is perfect. But as professionals, what matters is our attitude. We must not let QA find any problems.

All professionals work in teams. They are responsible for the future of the entire team. This is not their personal work. They help each other, teach each other, learn from each other, and even include what others need at any time. When a teammate falls down, others will care about it because they know that they all have mutual needs.

Professionals will not tolerate a large list of bugs. A huge bug list is very careless. A system with hundreds of thousands of problems in the problem tracking database is a tragedy caused by carelessness. In fact, in most projects, if they are very dependent on the problem tracking system, they will always be careless. Only a very large system can have such a long bug list. At this time, it requires automatic management.

Professionals will not make things messy, and they will be proud of their work. They keep the code clean, well structured, and easy to read. They followed the default standards and made good practices. They will never rush. Assume that you are able to get out of your body when a doctor gives you an open heart procedure. The doctor has a deadline (literally ). He must be completed before the cardiac lung function loses excessive blood cells. What do you think he should do? Do you want them to be as hasty and chaotic as a typical software developer? Or do you want them to say "I will be back later "? Or do you want them to observe discipline with caution and seize the time to believe that their own practice is the best way to do it now. Do you want chaos or professionalism?

Professionals have a sense of responsibility. They are responsible for their own business. They are responsible for the normal operation of the Code. They are responsible for the quality of their work. Even if the deadline is imminent, they will not give up their principles. As a matter of fact, when the pressure is getting higher and higher, professionals may even have tighter requirements for these principles because they think they are right.

-- Robert C. Martin (Uncle Bob)

5. Use code analysis tools

The value of testing is instilled in developers in the early stages of their programming journey. This year, the rise of unit testing, test-driven development, and agile methods have been widely used in every process of the development cycle. However, testing is only one of the many tools that can improve the code quality.

Back to the early stage, when the C language is still a new technology, the CPU time and storage format are very precious. The first C language compiler noticed this, so some semantic analysis reduces the number of convenient codes. This means that at the compilation stage, only a small part of errors can be detected. To make up for this, Stephen Johnson wrote a tool called lint, which can take out some redundancy in your code and implement static analysis that has been removed from its similar C compiler. However, static analysis tools add a lot of useless warnings or unnecessary warnings about style issues.

Currently, languages, compilers, and static analysis tools are very different. Memory and CPU time are also very low, so the compiler can undertake more error detection. Almost every language has at least one tool to check for illegal formats and common problems. However, sometimes hidden errors are not detected, such as potential NULL pointer references. For more complex tools, such as splint for C and pylint for python, they are configurable. That is to say, you can use a configuration file to select what errors and warnings the tool will send in the command line or IDE. Splint even allows you to comment out your code in the comment to give others more tips about running the program.

If everything fails, you find that you are looking for some simple bugs or violations that your compiler, IDE, or lint tools have not captured, you have to collapse all your static analysis tools. This is not as difficult as it sounds. Most programming languages, especially those that claim to be dynamic, use their abstract syntax tree and compilation tools as part of their standard library. It makes sense to understand the details of the standard library of the development team that you are using in this language, because this allows you to discover valuable things, this is very useful for static analysis and dynamic testing. For example, the python standard library contains an disassembly program, which tells you to generate byte code for some compilation programs and target programs. This seems to be an inconspicuous tool for the compiler author's Python-dev team, but it actually plays an unusual role in daily work. This library can decompile the information of your last stack trace, which will give you proper feedback, because the bytecode command will throw the last uncaptured exception there.

Therefore, do not put the test at the end of the quality assurance work, make good use of analysis tools, and do not be afraid to display your mistakes.

-- Sarah Mount

6. Use Ubuntu philosophy with your friends

Many times, we write code independently, which reflects our personal understanding of the problem and a very personalized solution. We may be part of the team, but we will still be independent because it is a team. It is easy to forget that independently written code will be executed, used, extended, and dependent by others. This is a social aspect that is easily overlooked in software development. Software creation is an activity that combines technology and social networking. We only need to look up frequently to realize that we are not working in isolation. We all have the responsibility to improve the possibility of personal success, not just for development teams.

You can write high-quality code in an isolated environment, but you will lose yourself. From a perspective, it is a self-centered approach (not arrogant, but self ). This is also a Zen point of view, which is the process of writing code for you. I always try to enter this step because it will bring me closer to high quality, but then I will fall into this step. What is the current stage of my team? Is my link the same as that of my team?

In Zulu, Ubuntu's philosophy is summarized as "umuntu ngumuntu ngabantu", which can be roughly translated as "a person is a person through (other) persons. "(people are connected with each other. I will be better because it is you and your behavior makes me better. On the other hand, when I do my own things badly, you will also get worse in what you do. For developers, we can understand "a developer is a developer Throuth (other) developers. "(developers and developers are mutually related), you can also say" code is code through (other) code. "(Code and Code are mutually related)

The quality of the code I write will affect the quality of the code you write. What if my code quality is poor? Even if you write neat code, but because you will use my code, your code will be reduced to a level similar to the quality of my code. You can use many models and technologies to reduce the loss, but the loss has already been caused. I suggest you do things other than things that must be done, because I will not consider you when doing my own things.

I will think that my code is very neat, but I still think that I can do better if I use the Ubuntu philosophy. What is Ubuntu philosophy? It looks like a neat piece of code. It is not a simple code, but a work of art. It is related to creative art. Using Ubuntu philosophy with your friends will help your team maintain your values and enhance your principles. If someone else has access to your code under any circumstances, it will become a better developer.

Zen is personal. Ubuntu is also a kind of zen for a group of people. We almost never see code that is only for ourselves.

-- Aslam Khan

7. You must care about your code

Without Sherlock Holmes, we will know that good programmers can write good code. Bad programmers... No. They will generate garbage that we must clean up. Do you want to write good things, right? You actually want to be a good programmer.

Good code is not born out of nothing. It does not come from luck just like the planetary alignment. To get good code, you have to strive for it. This is hard. If you really care about good code, you will write good code.

Excellent programs do not come from technical capabilities alone. I have seen some very competent programmers who can write impressive algorithms. They are familiar with the standards of programming languages, but they write the worst code. These codes are very painful to read, use, and modify. I have also seen more humble programmers who insist on writing simpler code. They write very elegant and expressive programs and enjoy working with them.

Based on my years of experience in the software industry, I have come to the conclusion that the real difference between General programmers and Great programmers is attitude. Excellent programs use professional methods and try to write the best software under the constraints of the real world and the pressure of the software industry.

There must be a good plan for code paving. To become a good programmer, you must make good plans and really care about code-cultivate positive opinions and develop a good attitude. The great code is carefully crafted by a master craftsman, and is never done by a programmer at manhu or a programmer who claims to be a master of code.

-- Pete goodliffe

We wish you all the best in 2014!

Http://radar.oreilly.com/2014/01/7-ways-to-be-a-better-programmer-in-2014.html

2014, 7 ways to become a better programmer