"Writing quality code: Java programs to improve the 151 recommendations," study notes

This book can serve as a reference code usually write, read this book in my personal experience it seems, it is best to read through the usual code-driven way, this fast absorbing, fast read.

This book is mainly about what, I used a mind map overview:

According to this mapping shows that the main talking point is the five Java syntax, JDK API, application performance, open source tools and frameworks, programming style and programming ideas and so on.

I read about this major open-source open-source world and the thought of these two chapters, these chapters equivalent of open source tools and frameworks, programming style and programming ideas mentioned in the maps. So today talking about is these two aspects.

First, open source tools and frameworks

Mapping follows:

Author's view is: the bold use of open source projects. And put forward five proposals on this. But in my opinion, then in addition to select frameworks and tools need to follow six principles, the other four o'clock from the mapping point of view does not seem to be of much use. So I do not intend to detail, but these four points me to understand these ideas and suggestions.

Ideas and recommendations are as follows:

Related tools used to unify, such as apache common for String relevant class has its special treatment, not to quote other as much as possible with this feature, because the easily confused, and when the lead pack, there are times when safety ctrl + alt display too many, if you're not in the case of the corresponding API is very familiar, it is easy to get confused, and I want to clarify is, the benefits of unified tools to avoid dazzling guide package, while also avoiding the need to implement a function corresponding when the tools, you refer to this, and I quote that.

Currently open source project, I think it is quite good tools integration projects, is Hutool, it is not only relatively complete documentation, and many open source projects and companies are corresponding with.

Hutool official address is: http: //www.hutool.cn/

But in the choice of open source frameworks and tools, it is best to follow six principles:

(1) universal;

Select the tool or framework must take into account the overall technical level of the project team, can not have too much span and jumping, to ensure that most of the members of the project are more familiar with the tool, such as in the choice about persistence layer, Hibernate better choice than MyBatis, the reason is because the quick, low-cost learning, replaced another example MyBatis MyBatis-Plus, span and jumping is not large, because of the nature or MyBatis MyBatis-Plus, the cost of such a team to learn very little remodeling project low cost, while developing efficiency will increase.

(2) uniqueness;

The same tool can only select one or more, do not let more of the same or similar function tool coexist. For example, hutools related functions can be used instead of apache common, as far as possible choose one, so that when project members in the development, sometimes ctrl + shift + O when conducting package without regard to guide the right.

(3) cool air trees;

Find the well-known open source project, Spring such as the current widely used in Java + MyBatis + SpringMVC and so on. Or is now Jeesite4.0 one open source project. Because a lot of people use, we do not have to worry about the encounter a lot of Bug, although there are, but because of the wide range of user groups, we can avoid a lot of tread pit.

(4) Finishing and specialized;

(5) high heat;

Select the open source project to select those updates frequently as possible. Often means that someone is responsible for the maintenance, it was in charge of solving a problem. Updated frequently better than a year or two years or even update has not updated items to be okay. So we re-use of open source projects should have this view when, bold, carefully screened. Of course, there is the last if we find an open source project is selected, suddenly author for some reason is not maintained, in which case, do not complain about each other, and do not denigrate other people, after all, we enjoy is hard others contribution results.

Second, the programming style and programming ideas

About programming style and programming ideas, the authors put forward an eight-point proposal, I feel quite stick. So I will use it as a mind map summarized as follows:

1. promote good coding style

 

 Wrap typesetting gotta take, or look a mess is not good, this is currently most people can do it. But the style uniform, then it is a bit difficult, the saying goes, the eyes of a hundred people a hundred Hamlet. A little difficult not no way to solve the code, such as the now popular Java Specification Guide "Ali Baba Java Development Manual", you can learn reference. Convenience (universal tools, such as sonar This code quality analysis or sonar lite this Eclipse plugin code analysis is also beneficial to create a good coding style.

 2. Do not rely solely on unit tests to find problems

 Unit testing does not cover all scenarios, because for a limited time, can do test scenarios and their corresponding data, we also three kinds of developers:

(1) Normal;

(2) the boundary;

(3) abnormal;

The other we do not have the time to consider so much, even if there is a special test, test scenario is still limited. Not to mention a small company like no test yet.

 

3. Let the comment is correct, clear, concise

 

 I think above this mind map has sufficient detail, so I will not go into details about the comment.

4. Single Interface functions

 

5. Alternatively enhancement of class

 

6. rely on abstract and not realize

 

 

4,5,6 relates to a corresponding design patterns, but these design patterns, our actual development, has been complied with, and also has been destroyed. It was difficult to fully comply with a set of design patterns.

7. abandoned seven bad coding habits

 

(1) free format code, arbitrary thinking about how to write on how to write, and finally waiting for you to cry.

(2) not using abstract code, such as Java, in general, the project will write:

entity、dao、service、serviceImpl、controller

entity corresponding to data entities

corresponds to the data access layer dao

Its implementation class corresponding to service logic layer

NATURAL controller is the interface control layer or view

Some people the easy way, in accordance with their own ideas to the service and serviceImpl merged into one, we said before the single responsibility principle. If service and serviceImpl merged into one, does not meet the author said, single responsibility and dependencies upside down or oriented interface. Because both the duty single or, or a dependency inversion worth mentioning oriented interfaces, the core is compliant, "high cohesion and low coupling." He did, naturally it is "low cohesion, high coupling."

(3) as individuality, for example, since that will write the code so that others do not understand, I think he is very fast hardware.

(4) like dead code, such as certain function code has been temporarily abandoned, but may later use, you use annotations to comment it out, waiting for later re-use, the reality is that the future will not be used again, in which the influence readability.

(5) as redundant code, such as a string of tools and can be done non-empty judgment, you still write a if-else if-else like.

(6) as the code refused to change, like people refuse to grow so that one day it will suffer.

(7) as the self-righteous code, they will soon finished preliminary testing of several scenarios, or do not think to test the blind self-confidence to write their own no problem, a little bug will not be, in the end, the general situation will problematic. It really touched me.

8. technical people to self-regulation rather than workers

 

(1) on familiar tools, such as Eclipse, if you are very familiar with it, regardless of when the project is large and growing, or when debugging, you will always familiarity than those relative to the number of people lower than you in the wrong investigation or find a class in a package, much faster on efficiency.

(2) on IDE, each programming language has its own unique IDE, IDE if not, imagine the code you use Notepad or notepad to write, then the command-line compiler, it is a painful thing ah, there's IDE with wide application programmers it is to improve development efficiency, reduce unnecessary manual labor.

(3) adhere to coding, here to mention that, as long as the technology is still in the mix inside the circle, code or write, otherwise where's the inspiration for it.

(4) before encoding think I have said here before, not thinking directly open dry before encoding, the end result is inefficient, useless.

(5) adhere to reconstruction, reconstruction is not necessarily a large scale, it can be a step by step, such as your previous controller is generally used as the control layer, usually receives the request, processes the data and returns data, like the Andrews docking, generally JSON data, you can be the previously cited JSONObject extracted as a class reuse, save each controller must lead pack.

(6) to write the document, also said before, not only to write documents and sort out the business logic to solve problems, or to improve their thinking skills.

(7) keep it simple version of the program, a project not too much later, or often simple things will become complicated.

(8) to do unit testing, about the importance of unit testing, I have said in this article, article link: https: //www.cnblogs.com/youcong/p/9291184.html so I will not say any more.

(9) make a backup, afraid of ten thousand afraid of the event, it will always leave a way of escape.

(10) Do not repeat create the wheel, there are ready-made tools, you do not own a lot of hard work to write, direct use of ready-made, of course, if you think you can transform this wheel, so that the wheel becomes better, Well, I think we might try, might be able to get rid of.

(11) do not copy, you can understand in order to have a lot of the code segments need to refer to a certain function, since it is the need to refer to a certain function the same, why not write a block of code easy to call it yet.

Reflect (12) Code is full of spirituality, at least you see this code know what that means, reflected in its intention glance. Instead of looking like hieroglyphics.

(13) test automation, regardless of performance testing, unit testing, functional testing or finding ways to automate it, do not manually configure the trigger conditions before testing.

(14) do stress tests, this would not have to say, now have a lot of stress testing tools, loadrunner or jmeter, on the whole, are pretty good.

(15) "plagiarism" is not shameful to learn how other people write code, learn from good, bad warning, one of the effective ways of encoding quality is also a self-improve.

(16) adhere to the agile learning, improve the efficiency of the software development process.

(17) in the heavier weight face, the first face good grasp of the user.

(18) share, to share their skills, share their own way to solve problems, share their own is how to write code.

(19) inquisitive, for all problems or things to be heart Why, especially the development of a heavy task when the business does not ask, can easily lead to do useful work.

(20) scale, is another major point to multi-faceted, equivalent to some business when you contact database, contact Andrews, contact IOS or operation and maintenance, etc., whereby you can expand their knowledge, this is the one way for the development of a full stack engineers.

summary:

Said above, some from the book, but also from my own thoughts. I hope we can help.

Published 295 original articles · won praise 37 · views 30000 +

Guess you like

Origin blog.csdn.net/tianshan2010/article/details/104707559