[Reading notes] The path of programmer's cultivation

First, the Pragmatic philosophy

1. Responsible. Be prepared to tell someone what to do before you go through it, and others may say, "Have you tried this?" Provide choices and solutions,

Instead of excuses, need to refactor, build prototypes, test, other resources? Make a request and ask for help

2. Entropy of the software. Eliminate broken windows, a broken window will allow the excellent system to accelerate decay.

3. The story of Stone Soup, the design of a reasonable demand target system vision, unity of all forces, we all feel that participation is happening more easily success.

"We're going to add a little ... Probably better "and pretend it doesn't matter.

Prevent the frog from boiling with warm water and keep an eye on the surrounding changes.

4. The tradeoff between quality and demand. Give users early feedback and improve the software.

5. Invest in yourself and increase your value. Learn a new language every year, read a technical book quarterly, and a non-technical book to ask what others are doing,

Try different development environments and keep up with the trends.

6. Communication. Without effective communication, a good idea is just an orphan that no one cares about. Understand user needs, design documents, proposals and memos to apply for resources,

Report status. Most of the time needs to be spent on communication.

Know what you're going to say? Plan, write an outline, refine until you know it, and ask yourself, "is that clear what I want to say?" ”

Understand the needs of the audience, interest, ability, to avoid boring annoying empty talk. For the different people, to make the audience feel excited.

Choose your time. Style documents are beautiful. Let the audience participate, do the listener, timely reply.

Ii. ways to focus on effectiveness

1. Avoid duplication. Duplication between developers, arranging project data managers, facilitating communication, storing practical routines and scripts.

2. orthogonality. The components are high in cohesion and low in coupling.

Can increase productivity: easy to test and reuse. can reduce risk.

The project team has a clear division of labor and reduces overlap. Take a look at the number of people involved in each requirement change to determine orthogonality.

Design, modularity, components, layered design. "If there is a significant change in the requirements behind a particular feature, how many modules are affected?" "There should be 1 in the orthogonal system.

Code, the law of Demeter, if you want to change the state of the object, let the object do it for you.

3. Drag the Light code , first build a simple can work to demonstrate the system, and then complete the function of each component, complete the connection, and gradually achieve the goal.

4. Prototyping and notes, making architectural prototypes

Are the responsibilities of the main components well defined?

is the collaboration between components well defined?

Is the coupling minimized?

Can you identify potential sources of duplication?

Are the interface definitions and constraints acceptable?

Can each module access the required data during the execution? Is it possible to access it when needed?

Third, tools

Plain text, Shell, with a good editor, source control, debugging is to solve problems, text manipulation language

1. Code generator

The passive code generator, which runs only once, produces results that are used all the time. Create a source file with annotations and generate a lookup table.

Active code generator that runs every time a result is needed.

Not too complicated, essentially a printf statement.

Iv. Results-based paranoia

[Reading notes] The path of programmer's cultivation