General documentation: Article directory Github: github.com/black-ant
Preamble: Date: April 2021, record some current thoughts for future self-review.
Record the first external documents about 4 years ago, at that time was in CSDN, in order to avoid the point is equal to I read, collection is equal to I learned, so I have to learn to integrate things released, to fill the self confusion in the heart of the dilemma.
But hair hair, fell into the confusion for the first time, as a junior programmer, or a position is a full stack of junior programmers, hair things and a hodgepodge, everything, but nothing fine.
Look now, still mark original, really ashamed to panic ~~~~
After more than a year of writing, I stopped writing. I still remember that I had several thoughts at that time:
- It’s not deep. It’s all about writing
- Too basic, the Internet to check a large, write better than their own
- It’s not much use except for me to find it later
There are other also did not write down, if you write down, should be able to help the confusion at this time.
Since I started working, I have the habit of taking notes. My principle of note-taking has always been: no matter how long it takes, I can implement this function in a short period of time by taking notes to understand this point. Even though the early article was bad, it also achieved this effect, and I can still pick up something from it. So, this principle should be maintained.
After the release, I stopped because AT that time, I wanted to go deep into the technology, I could not float on the usage, I started to take notes on localization, I started to cram things into Git, I tried my best to cram everything I learned. At the same time, I started some open source projects because of some inspirations, although no one looked at them. I didn’t think IT was finished, but it was a good way to precipitate technology, so I spent the most confused period.
About a month ago, I decided to continue publishing the document. The main reason was that there was too much documentation and it was too messy. Typora was really good for Markdown, but it was awkward. So systematizing and documenting knowledge, I think, can solve this problem
What features should the document have?
- Serve yourself and improve yourself
- Summarize knowledge, share knowledge, record knowledge
- It can be studied twice to reduce the learning cost
Blog or document or, its biggest service provider is their own. Release, in addition to sharing knowledge, its purpose is to be able to recall and organize ideas when writing, after the release, others can point out the mistakes for you, a complex point to simple document, is a good document.
For the past two years, I have been thinking about how to use documented-driven development.
I do not expect that a common operation or the construction of a framework will consume the second time, so I will record the construction of a business completely in my notes, and record the problems encountered, so that THE next time I use it, I can build the environment in the shortest time. In my opinion, Take the environment most annoying….
However, it also leads me to a new confusion…
This period of time the document is very productive, the main source of consumption is the accumulation of 2 years, write write I found, these accumulation only solved how I should use, source code or steps or, I can only solve how to use it through the document, it may help me solve how I should pass the parameters, where I am not wrong….
However, I think there’s a lot more room for document driven development. What do I expect my documents to do in development?
- Find the problem quickly
- Fast implementation of functions
Or…
- How can I customize my functionality?
The 2021-04-04 record
How can I customize my functionality?
When I wrote the Security series, I was thinking, I’ve written down the flow of the source code, can I write down the points that can be customized? Now that you’ve written that down, isn’t that gonna be great? Do what you want, play what you want, okay?
But faced with a problem, can not write out, because it will consume too much time and energy, and not necessarily return, may be 100 business points inside, also will encounter once, the cost is too high
So how can I achieve efficient analysis?
- Based on official development documentation -> Supplement source documentation -> extend custom documentation
- The analysis of the source code should go with the development documentation, from the commonly used functionality, to the analysis of commonly used extension customization
- Replace real code with pseudo code to reduce code length and facilitate secondary learning
- However, is it appropriate to record the document in such a way as to omit details?
- Which set of tags to use locally, along with the source code?
- Mark way to express the process, the source code to show the details
- (You can try)
What else is in the document?
- Flow chart: Plug-in Seqence Diagrams
- UML Diagrams: IDEA -> Diagrams -> show
Conclusion:
Basically the idea is clear, then try these patterns and see if you can improve your documentation again.
Leave this document for future comments, endless learning, do not forget the original purpose.
Create your own markup language records
I implement interface E implement abstract class C SC internal static class PC general internal class PVC private internal class PUC public internal class IC internal interface F property SF static property MC constructor SM static method M method P parameter S Static code block B- logicbooleanJudge (B->) FOR- Else-elselogic// ELSE-
// E-- Normal logic -1Ordered run logic -> Internal run logic (inside method)? The = assignment operation (param) uses an operation/ / case:
C- DefaultResourceLoader
MC- DefaultResourceLoader
- ClassUtils.getDefaultClassLoader();
MC- DefaultResourceLoader(@NullableClassLoader classLoader) M- addProtocolResolver(ProtocolResolver) : M- getResource(String location) - first, load Resource(String location), return Resource(String location) - second, start with /, Call the #getResourceByPath() method to return a resource of type ClassPathContextResource - again, with classpath: First, return a resource of type ClassPathResource - get the current ClassLoader by #getClassLoader() - and then, depending on whether it is a file URL or not, return a resource of type FileUrlResource. Otherwise, return a resource of type UrlResource - and finally, a resource of type ClassPathContextResource// If only someone could give me more inspiration
Copy the code