Pareto's Law says that 80% of the results depend on 20% of the causes. This is also known as the 28 Principles, and almost every field of human attempts is related to it.
In the field of software development, this principle can be summed up as the fact that most problems are caused by a few poor coding practices. Eliminate these problems and your job will become easier and your efficiency will increase.
Surprisingly, this is the most common and can be maddening since it has nothing to do with your coding level. A typo in a variable or function name can wreak havoc on your code. What's more, they are often not noticeable.
How to solve it? Working in a good IDE or programmer-specific text editor can significantly reduce spelling errors. One more thing you can do: try to choose variable or function names that are easy to spell, so that if you misspelled it, it's easy to spot. Avoid words like receive as it is easy to write receive.
Indenting or otherwise formatting the code makes it easier to understand and therefore easier to locate errors. At the same time, because the code style is consistent, it will be easier for others to maintain your code.
If you're using an IDE that doesn't automatically indent your code, consider using a code beautifier like Uncrustify , which formats according to the rules you configure.
A good coding practice is to implement functions that do one and only one thing. This makes functions shorter and therefore easier to read and maintain. Long functions have many possible paths, which makes them difficult to test.
A good rule of thumb is that a function should take up no more than one screen of space. Another point is that if it has more than 10 if statements or loops, it is too complicated and should be rewritten.
IDEs and other tools that provide code completion are very effective for increasing efficiency. They suggest variable names or other things based on scope and your input. There's a danger with this type of tool though - you'll choose an option because it looks like what you want, without making sure it's actually what you want. In fact, the tool just does the thinking for you, but you have to make sure that this thing is correct.
You may hardcode a secure account and password so that you can log into the system later. You also know you shouldn't - yes, it's convenient, but it's also convenient for someone with access to the source code.
The real problem is that hardcoded passwords end up being accessed by more people than you might expect. This is a huge security risk, not to mention how cumbersome to fix.
Sensitive data needs to be encrypted during transmission over the network so that it cannot be easily intercepted. It's not a good idea, it's a regulatory requirement, even if it's not a rule of thumb.
This means that you absolutely cannot send data directly. Also, don't encrypt or obfuscate it yourself. Writing your own secure encryption system is very difficult - just look at what's going on with WEP , so it's best to use an industry-proven standard encryption library and use it properly.
Legendary programmer Donald Knuth once said, "Programmers waste a lot of time thinking about or worrying about the efficiency of non-critical parts of their programs, and these efforts have a great negative effect on the efficiency of subsequent debugging and maintenance."
Putting a lot of effort into the code only makes it run slightly faster, but makes it harder to debug and maintain. A better strategy is to write your code cleanly, and then only improve its performance if there is something that really needs to be optimized.
What does your project do, how large does it need to scale, how many users will use it, and how fast does it need to run? There may be no answers to these questions - but if you don't predict ahead, how can you choose a suitable application development framework that will allow your program to meet these requirements?
If you underestimate what's wrong with future demand, Twitter is a good example of this. Twitter ditched Ruby On Rails and rewrote much of its code in Scala and other technologies, because the Ruby code used in the original architecture couldn't scale to keep up with Twitter's rapidly growing user base.
Many software projects fall behind schedule. It sounds like a good idea to add more people to the project to get things back on track, but it's wrong. In fact, adding new people to a project often delays the entire development schedule.
It is also important not to imagine that you can catch up with the original schedule without adding people to the project. If you are already behind schedule, it is because your estimated time is wrong. It also means that you have to re-evaluate the entire project cycle, rather than blindly sticking to an evaluation time that has been proven to be wrong.
Please indicate the source of original article reprint: http://it.deepinmind.com
English original link