The Pragmatic Programmer: from work to specialists 2

   Now the book has been read half of the book is relatively basic learned a lot, not the kind of large-scale programming, high concurrency design, etc., mainly for some of the basic qualities of programmers and some basic design to do some sort of conventional programming and specification for recruits to programmers, to develop these good qualities are very necessary; for many years has been the entry of programmers, look at the book, and then with their own situation and see if the book can reach some basic literacy is also necessary.
   The book is a principle to implement DRY (Do not Repeat Yourself) principle, which is every good developer must follow the specification, the encoding process anywhere Do not repeat, repeat temporary because the time saved will give future maintenance and use huge trouble if there are duplicate code is found in violation of the principle of orthogonality or other places to look for opportunities to reconstruct immediately. So that it can have a faster, better, stronger, more elegant code.
    Some theorems rule book makes me Heng interest, such as Demeter law - to reduce the coupling: In order to avoid a third object methods to access and enter an object. In some cases, the speed can be increased in exchange coupling. As long as those modules are coupled together, this is well known and can be acceptable.
The details extracted, writing system dynamically configurable.
Coupling time: Adjust sequence of events, increase concurrency.
Do not let existing code govern future code, if not practical, all of the code can be replaced.
How to reconstruct more advantages than disadvantages:
(1) Do not try to add functionality while remodeling;
(2) before the start of the reconstruction, to ensure a good test;
(3) take short, deliberate steps.
Regulations demand: the underlying semantics of the same items as the demand capture, and the specific work practices or the current policy as recorded in the document.
Demand is not architecture, demand is not designed, nor is the user interface, the demand is required.
Gently exceed user expectations.
My source let the cat to eat 2
Honest with our ignorance and wrong
in doing something except as best you can, but must analyze whether risks outweigh your control. For the impossible or too risky, you have the right not to be held accountable.
But once the commitment to complete something, I accept responsibility for it must assume its responsibilities as a result.
When their own mistakes, honest and admit it and try to provide a variety of options. Do not blame someone or something, or put together an excuse.
Before tell people that can not defend their own say please give the cat to listen, to see whether it is reasonable or stupid. Listen to your boss and how?
Entropy Software 2 3
"can not tolerate broken windows"
"broken windows": poor design, bad decisions or bad code
no countermeasures repair time: with wooden planks and nailed it up - add comments to join TODO with dummy data to be alternative .
3 stone frog soup and cook 5
to know something is right, but involve other people, in order to combat indifference and procrastination, we need to cheat, his colleagues to start on the road, then we are not far away from success.
Boiled frog: avoid delays and deviate from the design, which can lead to such a frog being cooked.
4 8 software good enough
to meet the needs of users when software is good enough, it is necessary to allow users to participate in a trade-off
to know when to stop: Do not be too excessive modification and refinement of the program intact damaged, lost them.