1 the three laws of
The Rule of Three is a rule of thumb for code refactoring that determines when a copied piece of code should be replaced with a new code/program/method.
It allows you to copy and paste code once, but when the same code is copied three times, it should be extracted into a new program. The main idea is to make the code/program/method common throughout the project so that it can be used repeatedly in many places.
2 Stability is king
Be consistent in structure and coding. This will help you improve the readability and maintainability of your code.
Try and come up with consistent coding standards that help maintain consistency, preferably down to the naming conventions of your variables. Another important thing is the structure of the code program, which should be obvious to the developer to make some changes or add something new.
3 Reduce nesting
The ifs in ifs can clutter the code structure and become very difficult to read quickly. Sometimes you may not be able to get around this problem, but do look at the structure of your code. The same is true for else ifs. Avoid if nesting as much as possible, because this can sometimes make the code more difficult to read.
Guard statements (also known as early return/early exit) are an effective way to help solve this problem! A guard statement is used only to check for prerequisites, which can be a return statement or an exception.
Example of not using a health statement:
if (account ! = null) { if (order ! = null) { if (order.term == Term.Annually) { // term annually } else if (order.term == Term.Monthly) { // term monthly } else { throw new InvalidEnumArgumentException(nameof(term)); } } else { throw new ArgumentNullException(nameof(subscription)); }}Example of using a health statement:
if (account == null)
{
throw new ArgumentNullException(nameof(account));
}
if (order == null)
{
throw new ArgumentNullException(nameof(order));
}
if (order.term == Term.Annually)
{
// term annually (return here)
}
if (order.term == Term.Monthly)
{
// term monthly (return here)
}
throw new InvalidEnumArgumentException(nameof(order.term));
4. Think big
It’s important to have a sense of the project as a whole, which makes it easier to follow up on small details. Once you understand the overall structure of the project, the small details don’t need to be studied too much.
5. Take a moment to think about naming
Naming a variable, method, or object in code is one of the things that bothers us. This could be naming a class, method, or even a variable. A good developer will take the time to think about the relevant variable names because they know it helps readability!
6 Technical debt is bad
Requiring higher heights can help solve this problem. Try to write your code logic once, or you’ll have to refactor it again and again.
Technical debt is a concept in software development that reflects the cost of additional rework due to choosing a simple (limited) solution now, rather than using a better approach that would take longer.
7. Overrated
Depending on your department, you may not like this. But good developers tend to overestimate the task, because they know how long things will take, and then add another buffer to that expectation, which can help you get things done.
This can really help you solve the problem of “technical debt is bad”. If you underestimate or predict an ideal time, you may actually miss it and may even leave behind some technical debt. Because your expectation is just to get it done as quickly as possible and get it up and running, not to make the code clean and maintainable.
Documentation and comments
Documentation and comments help make it easier for yourself and others to understand and use. You’ll hear experienced people say, can we document this process, or the code review failed because the interface is not commented.
Dare to remove bad or useless code
You’ll often see a lot of code commented out and left there by less confident developers. Version control has a purpose! Good developers don’t shy away from removing unnecessary code in their applications.
Take the time to review the code you’ve written
Good developers will spend more time on code reviews and understand the importance of code reviews. Find bugs early;
Develop the skills of developers and get the rest of the team into the habit;
Knowledge sharing; Consistent design and implementation.
The best code review process I’ve seen is:
A small, low-risk task should be reviewed by one developer; Medium/large or risky changes should be reviewed by three developers, one of whom is a senior developer on their office team; For a highly risky change or new feature that is under development, hold a meeting where at least one of the three developers is the lead developer, and go through each line together and make recommendations.
11. Write test cases
You’ll notice that more experienced, more competent developers spend more time writing good test cases. Good test cases can help you extend or modify program code with more confidence, and help reduce the number of bugs.
Take the time to design
Before delving into code or writing code, think about it carefully and break it down into smaller pieces. This will help you figure out how to put everything together and prepare you more for creating cleaner code.
13. Focus on technical implementation principles rather than syntax
That’s a big problem! They prefer to learn the basics rather than pay attention to grammar. This helps them identify problems more effectively, and helps them understand Google’s problems better.
14. Make Google your best friend
They are Googling’s experts, better able to find solutions to problems. As mentioned above, they are more focused on the basics than the grammar, so they know which Google terms to search for, which is hard to do if you are obsessed with learning grammar!
15. Implement the function first, then optimize
Some junior developers seem to spend a lot of time making the code look pretty at the beginning, only to be embarrassed if it turns out not to work. Good developers implement only features early on, so they can identify problems early on before they get the details right, which helps keep the project running more smoothly.
16. Risk Management and Problem Solving Senior developers can manage risk, refine complex problems through the application of design patterns, and solve different problems independently, based on past experience.
More than 17 q
Good developers want to know more. They don’t mind asking questions, even if it sounds easy. These may be technical or business related issues. Understanding the business requirements helps them write better code! They are so confident in their abilities that they are not afraid to ask questions.
Separate logic from the database as much as possible
This depends on the type of application you are building, but only if it does not affect performance.
They know to keep database queries in simple CRUD operations.
Create, read (aka retrieve), update, and delete
The business logic layer should then pull these things together. This helps developers know where to look for business logic. If you have logic in your database queries and code, this can quickly become confusing.
Keep your code simple
They know that keeping the code simple is the best way. Even if it means writing more code sometimes. You’ll see many junior developers writing code like this: return dir.keys.Any(k => k >= limit)? dir.First(x => x.Key >= limit).Value : dir[dir.Keys.Max()];
This is usually possible, but it’s very difficult to read!
Bottom line: This is what I see good developers doing every day. You’ll find that many of these have nothing to do with the actual coding and everything to do with processes and how they handle tasks……
. END... To learn more about the development daily, please scan the QR code below and update it daily