“Programmer training: from small work to experts” after reading six thousand words summary
Read this book, actually spend not much time, because I have some basic cognition. Here I mainly recorded my thinking and summary at that time, only my personal thinking and experience.
This book has a lot in common with Geek Time’s 10X How to Work as a Programmer: it’s easier to eat, digest faster, and gain weight.
So what is the book about?
This book is not about esoteric techniques, or pontifical ideas, or programming languages. Rather, it lists small checklists to get readers thinking and to encourage them to become practitioners.
If you like, use it as a reference book before, during, and after you write code. Check and reflect in your spare time. Gradually the book was no longer needed.
The key word in this book is also The theme of The original title, The Pragmatic Programmer: Pragmatic. How do I understand this word?
A very important point is the evolution of thought cognition.
There may be a lot of new programmers who think work is just code, finish the task, and “just run”.
But it can’t stop there. Code is just a problem solving tool to make the business work more efficiently; What makes us more productive is that we use tools more efficiently. It’s not about typing faster and more forcefully or writing more code, it’s about not just doing it, but doing it better. I think at least the following aspects should be done:
- Thought transformation
- Improve yourself
- Choose the right, less costly implementation
- Use more convenient tools
- Write better code, maybe more code, maybe less code; But there will certainly be less in the future.
- Pay attention to communication and collaboration, and pay attention to more “vision” in the project. Systems are not built by one person, they are built by collaboration.
To be honest, most of the time, a raise isn’t something you need to do more of. It’s something you deserve to do more of at your job.
How do you get stronger, get a raise, get rich
In the preface to this book, a few sentences may be pointed out.
Can let the right principle guide the right action itself, in fact, is a significant mark to distinguish the expert.
However, I’m sure we all understand the principle, but what is the right principle? How do you always direct your actions?
Remember what I said above, this book is really just checklists, short sentences. Much of the book is devoted to interpreting these phrases, using examples to make them easier to understand.
Ok, the thing is there, then do it:
We need to abstract out some simple words and rules, and internalize these little sounds on a small scale by memorizing them and constantly reminding them, so that these simple sounds can always jump from the brain to the ear to remind us.
You can flip it over. To see it, to practice it, and in the end you don’t need it, because it just happens.
You should not be limited to any particular technology, but should have a broad enough background and experience base to allow you to choose the right solution for a given situation. Your background comes from an understanding of the fundamentals of computer science, while your experience comes from a wide range of practical projects. The combination of theory and practice makes you strong.
After I refine some helpful content (only belong to my personal opinion), for reference only. If conditions permit, you can take a look at the original book, the content is not much, worth reading and pondering.
Personal articles
Think actively, be curious, and improve your abilities
Stay curious, think about your work, and keep learning and improving your craft.
This, AS I’m sure you all understand, has evolved into “inroll” and has to be rolled up.
Study also pays attention to plan, method.
It is suggested that the learning plan should have goals, which can be broken down into small goals in stages to maintain continuous learning.
Simple learning is certainly not finished by watching, reading, recording, summarizing, output is a process, the first day to read, review the second day, weekend sorting back to strengthen memory.
Keep reading thoughtfully, that is, with critical thinking.
How to ask questions
There are two extremes when you encounter a problem. One is to ask for help directly, and the other is to spend a lot of time on it.
In fact, neither is advisable. First, it is difficult to be impressed and accumulate experience. The latter wastes a lot of time, thereby delaying the work of others or others.
The reasonable way is to think about how to do first, and then to find the answer; If it takes a while for you to find the answer, but you have some ideas or plans. Go looking for someone to solve again, let colleague help solve, can save time of both sides.
You may end up with a different answer than you originally thought, but you know what went right and what went wrong in your plan or thinking, and you can go straight to the right path next time.
Pay attention to how to ask and communicate. Face-to-face communication is a priority, followed by emails or documents (I tend to go for rituals, because I’m sure I’ll read them once I’ve written them), and IM. But either way, there should be structured communication, and I recommend The Principles of the Pyramid.
Write the right code, write the right maintenance code, and most importantly, follow the specification
The law of entropy, software code, architecture is always moving in the direction of disorder. This requires that in general we always follow the rules when designing and writing code, with zero tolerance for “broken Windows”. A broken window is a small piece of bad design or bad code in software.
Once this tiny “bug” appears, it will always develop over time and cause software to appear difficult to maintain, expand, design, and even the real bug. This is a bit like “boiling a frog in warm water”, thinking that a little problem is ok, but once there is such a slack, it will not repeat. To make matters worse, the CV method is good, and such code can be copied indefinitely. Even without CV, more colleagues will choose to slack off together under the repetitive work brought by strict norms (real people and real things).
So, it feels like in general, the expectation is 5, and it’s better to go to 6. Do not know everybody company is also this appearance.
When such a problem arises, it will take even more effort to solve it.
Norms, codes, principles, this kind of thing is really hard to do. The nature of the programmer is “lazy,” and the extra work that comes with strict specifications is the most annoying.
The advice is to keep pushing yourself, take small steps, and internalize them. Remember that code quality, software quality can also be a requirement that you need to address
Some people may say that the demand is too much, too busy to come over, which have to add their own demand. This is a tricky one, and both this book and the 10X Programmer’s Way of Doing Things suggest breaking down requirements into smaller tasks and weeding out those that aren’t important or urgent. But the granularity is a matter of opinion.
Be a catalyst for change
I like this spot very much. When you think something is unreasonable and you can have a better plan, you want to promote it and replace the original way.
But it takes time and cost to try a solution; Even if there is a solution and other people think, well, it’s a lot of trouble to change the code, it’s not clear what the benefits are or what the risks are; In some large companies, some technical solutions need to be reviewed and approved by the technical committee.
Design something you can reasonably demand and develop it. Once it’s done, show it to everyone and surprise them. And say, “What if we increase… It might be better.” Pretend it doesn’t matter. Sit back in your chair and wait for them to start asking you to add features you already want. People find it easier to participate in the success that is happening. Give them a glimpse of the future, and you can rally them around you.
This could be a template with a picture on it. But oh, it takes people who are driving change to have a bigger vision, to see not just their own code, but everyone else’s pain points.
My personal practice is to think more about product design from the perspective of users and pay attention to the cooperation between the whole project and the team. Small talk, look at other people’s code, mention MR.
Program and architecture design
Reject repetition in favor of reuse
We all know the “dry-don’t Repeat Yourself” principle.
Duplication of code and design leads to code bloat, which makes it more difficult and risky to change code (requiring multiple changes).
Try to avoid repetition, the following are some general situations:
- Snippets function similarly: you can extract utility classes
- Code modules function similarly: sink into the underlying module
- Different languages realize the same function: extract common services and provide services in one language; Provide access by plug-in or proxy.
- Different developers implement the same similar feature: ditto.
Flexible Architecture
During project iterations, functional changes, data structure changes, and even underlying resource changes are likely to occur.
Flexibility of code, architecture, and even integration and deployment may need to be considered from the beginning of design.
In software design, there are many ways to achieve such flexibility, such as decoupling, abstraction, corrosion layers, configuration, etc.
Orthogonality, decoupling
The core of high cohesion and low coupling is: layered, modular and abstract.
Modules centralize core functions and provide external capabilities through unified interfaces.
Modules decouple external dependencies by relying on abstractions rather than implementations; And rely on the logic implementation interface to provide support for the core logic.
The logic inside a module is unknowable to the module that depends on it, and even if the internal logic changes, the upper module does not need to make any changes.
This in the object oriented principle, can generalize the class equal to Demeter’s law or the least knowledge principle.
The MVP and prototype
The MVP was not the MVP you imagined. He was referring to a Minimum Viable Product — the simplest Viable Product.
The core view is that in order to quickly respond to the market, the most simplified products with only core functions should be launched quickly, and then iteration should be carried out after receiving users’ use and feedback.
One is to avoid missing the changing hot market; Second, to ensure the minimum trial and error cost; The third is to avoid unnecessary waste, because a new market is often based on people’s imagination, prone to deviation. Therefore, only by entering the market quickly and adjusting according to user feedback can we cater to users and the market.
From a research and development point of view, functional development is more rational, continuous integration environment is more complete, test verification has real data. Of course, with user feedback, the goal is much clearer. But more is often required of the r&d team:
- Need a responsive, committed team. This is usually not very large, otherwise it is not conducive to transfer.
- There are accumulated resources and schemes available for use or reference. Design materials, development tools, scaffolding, architectural solutions or tools to solve complex problems.
- Complete infrastructure and automation environment. Continuous integration, continuous deployment automation environment, automated testing, gray testing, data analysis, can adapt to the new market traffic surge service deployment and expansion.
The prototypes previously advocated were more for demonstration purposes, not deliverable to users, and were often throw-away items. Because it tends to ignore several features that a real product needs:
- Is correct. We can use hypothetical data, just validate the process.
- Integrity. It’s much simpler than MVP, and we only need the right process for core functions, not the abnormal process.
- Robustness. It’s okay to crash if you’re wrong.
- Style.
Prototyping for learning is recommended.
Metadata design
“Get the details out!”
What exactly is metadata? Strictly speaking, metadata is data about data. The most common examples are probably database schemas or data dictionaries.
Broadly speaking, metadata is any data that describes an application — how it should operate, what resources it should use, and so on.
The core design idea is to put abstractions into code and details into metadata, which has the advantage of
- It forces you to decouple your design, leading to more flexible and adaptable programs.
- It forces you to create more robust, abstract designs by postponing the details — out of the program altogether.
- Easy to expand, adaptable to customization, can be more easily responsive to change.
Task decomposition and estimation
Task breakdown and estimation complement each other. Task breakdown is more conducive to the control of your understanding of requirements, the control of the schedule of requirements, and the control of time management. Even the task is so small that even if you are interrupted, you can either shelve the interruption and respond to it after developing the task. You can also suspend a task, which costs very little to suspend because it’s not complex. You can record progress, respond to interruptions, and then come back.
The accuracy of decomposition is based on your understanding of the business, your understanding of the requirements, your accumulation of previous experience and your clear understanding of yourself. You can even summarize a set of models for analyzing requirements and disassembling tasks.
Program code
Design by Contract (DBC)
It focuses on documenting (and agreeing) the rights and responsibilities of software modules to ensure program correctness. What is the correct procedure? No more, no less, a program that does what it claims to do. Documenting such declarations and verifying them is at the heart of design by contract (DBC).
The way to describe such a declaration and validation is:
- Preconditions. It is the responsibility of the caller that the prerequisites for calling a program or function must be met.
- Post conditions. The event or state of being at the end of a program or function that is guaranteed to end.
- Class invariant. Internally maintains the integrity check of a state or set of states, which can be used to ensure the correctness of any intermediate state during program operation; It also allows the intermediate state to violate the check, but at the end the check must pass.
This is done by considering the range of input fields, boundary conditions, format and range of output data, and input and output at design time.
This can be done through assertions, preprocessing, early return of errors, and crashes.
Continuous refactoring, small refactoring
You can refactor whenever you want, even as early as possible.
Refactoring is an option when you find duplication, coupling, outdated logic, performance issues, inappropriate specifications.
You can do it little by little, rather than refactoring it all at once, which is painful, trust me. It takes a long period, it can’t be interrupted at the beginning, either it’s all done, or it’s all back; Maybe refactoring is just a CV method for extracting classes and methods. A little bit of this is nice, but a lot of it is boring. Small refactorings, even if they go wrong, can simply step back and redesign.
So be careful: small refactorings and good testing ensure that the refactorings pass the tests.
While it is advisable not to add new features during refactoring, if it is down to small changes, I would rather test with the requirements and make them routine. The key is to get into the habit of writing better code and constantly optimizing.
Testability and test cases
I’m sure many people like me hate writing unit tests. Given that unit tests typically cover core or complex logic, why are they so daunting?
Largely because the core logic is not written well and may rely on external “heavy” implementations; Maybe it got mixed up with something else, causing the complexity to get higher.
I personally write testable code, and the key is that a core logical approach is to have a limited, appropriate number of inputs and outputs. This way, I can enumerate all possible inputs and outputs to write test cases.
Program concurrency and workflow
An often overlooked aspect of software architecture is the role of time as a design element of software itself:
- Concurrency: Multiple events occur at the same time
- Sequence: The relative position of events in time
Especially in the development and design of the Internet, concurrency is a factor that cannot be ignored and must be taken into account at the beginning of design. How do I prevent concurrent conflicts? How to ensure high concurrency?
One possible principle to prevent concurrency conflicts and improve concurrency is to analyze workflows, which can be analyzed using UML activity diagrams.
In addition, the concurrent aspect of programming, to consider multi-process, multi-thread, multi-coroutine; Server architecture design should also consider high concurrency, how to scale and other issues.
System performance and complexity estimation
System performance is sometimes difficult to measure, such as CPU load, processing time, memory load, disk read and write, etc. This is usually aided by prior knowledge and experience.
In addition, through the estimation of the algorithm to obtain a fuzzy cognition, namely complexity analysis, big O representation.
Project report
Reasonable demand
That’s a matter of opinion. Also met the need to write each process is very clear, there are direct throw a sentence to which which add a status display, the style is the same as another place. It really is, man. It’s not the same thing. It can’t be the same.
Therefore, you need to understand the requirements, look beyond the phenomenon to the essence, and look at the problem from the user’s point of view. Because r & D received demand is the product after receiving business problems and processing out of the solution. Product thinking is sometimes at odds with r&d thinking. Product thinking is about design, interaction, etc. R&d thinking is about change risk, effort.
But the goal is the same, solve the problem. Understand what the problem is, we can think about whether it is temporary, can be done simply; Or whether non-technical means can be used; There may be readily available means to conveniently address the core appeal.
Second, it is possible to know if you are trying to solve a class of problems or a specific problem, such as the following requirement expression:
Access to files is restricted to designated personnel
- Such requirements come over, developers will design a set of rights management system, convenient subsequent expansion
Only the management and personnel department can access the files.
- When such a requirement comes, the developer may just do a simple configuration and perform pre-static detection
- As the requirements change, they may not be met and may even require code changes
The expression of the former demand will prompt us to consider the expansion and compatibility when designing. Thus choosing abstraction over detail.
I think it’s very important to be clear about the vocabulary when you’re talking to products.
Because the product said A, but there may be research and development will consider the English expression in the design, but there is no perfect matching vocabulary, so B is used. The translation of B is different from that of A, which leads to the situation that the product says A and the research and development says B.
Have a very specific vocabulary for the scenario, and try to use vocabulary specific to the business domain.
More preparation
If you hear the requirements and still can’t design, try to figure it out. If you design the solution and still can’t write the code, think again about the problems and shortcomings.
Because once there is no clear thinking, it is likely to lead to rework, or useless work, afraid is to toss about a month or two later found that the front have done wrong!
specification
Writing a program specification is the process of reducing requirements to a level that programmers can take over, and eventually forming conventions that everyone can accept.
This is actually very important, especially for multi-person projects.
Infrastructure, automation
Metadata design may require configuration hubs; Unit tests may have scaffolding that is packaged and easy to use; Automate CI/CD build, compile, test, code quality check, build images or JARS, deploy; Even automated testing, gray deployment testing and so on.
I’m sure it’s both, or both.
Complete testing, automated testing
Automated testing, early testing, frequent testing, testing is a large part of the code; The project needs unit testing, integration testing; Core systems may also need performance testing, stress testing; There needs to be some coverage.
Documentation and comments
Keep your documents well maintained. Don’t leave holes. Seriously, if you take over a system, or if you go into a company, and you don’t have documentation, you have to look at the code. Heh heh, and then you find that there is no comment, I wonder if you will just walk away.
Remember when I was in college, the teacher should have taught me relevant documents before writing programs; If you don’t, you can’t get away with it, because you have to have it when you write your paper.
If documentation or comments are out of date, keep them up to date.
It makes sense, but nobody wants to write about it. How about you start with a blog and work your way up to documentation?
Let’s output together, push each other, upgrade!! Level 2 for small targets.
conclusion
It has been a month since I finished reading this book.
The structure of this summary is not necessarily the same as the structure of the book. It is the result of my personal classification and my personal understanding.
If you have any different ideas or opinions, welcome to discuss. ‘!