"Programmer's professionalism" Reading Notes

Book address: http://book.douban.com/subject/11614538/

One-sentence comment on the book: Summary of Uncle Bob's career experience, the appearance of the statement, trustworthy and respectable!

(1) Professionalism

(1) "professionalism" means taking responsibility;

(2) Professionals are responsible for the mistakes they make, even if they are inevitable;

(3) Each line of code you write must be tested. If you want your software to be flexible and variable, you should always modify it!

(4) matters that every professional must be proficient in;

1) Design Model: it is necessary to describe all 24 models in the GOF book, as well as practical experience in most models in the POSA book;

2) design principle: the SOLID principle must be understood, and the component design principle must be deeply understood;

3) Methods: XP, Scrum, lean, kanban, waterfall, structured analysis and structural design must be understood;

4) Practice: Test-driven development, object-oriented design, structured programming, continuous integration, and Pair programming must be mastered;

5) artifacts: you must understand how to use the UML diagram, DFD diagram, structure diagram, Petri grid diagram, State Migration diagram, flowchart, and decision table;

(5) keep learning.

Architects who do not write code will inevitably suffer. They will soon find themselves unable to keep up with the times. programmers who do not learn new languages will also suffer. They can only watch the software industry go forward and leave themselves behind; developers who do not learn new principles and technologies will surely fall into this category, and the people around them will benefit from excellence;

(6) diligence.

One of my frequently-used skills is to repeat some simple exercises: You may wish to spend 10 minutes in the morning and evening! The second best way to learn is to work with others.

(7) Every professional software engineer is obligated to understand the business areas corresponding to the solutions they have developed;

(8) The employer's problem is your problem. Every time you develop a system, you should consider it from the employer's perspective to ensure that the developed functions can truly meet the needs of the employer;

(2) Say "No"

(1) Professionals dare to explain the truth and do not give up on power. Professionals have the courage to say "no" to their managers "!

(2) "No" is the critical moments of high risks. The more critical the moment, the more valuable the word "no.

(3) The promise of "trying" means that you acknowledge that you have not done your best to admit that you have yet to commit. If you promise to try, you promise to change your original solution. You acknowledge the shortcomings in the original solution.

(3) Say "yes"

(1) The commitment consists of three steps:

1) Verbally say that you will do it;

2) Take the commitments seriously;

3) truly put into action;

(2) identify signs of "lack of commitment" and search for the following words: "need/Should", "Hope/hope", and "let us"

(3) the true promise is that you make clear fact statements about yourself in the future and clearly indicate the deadline for completion;

(4) If you cannot fulfill your promise, the most important thing is to send an early warning to your promise object. The sooner the better, the sooner the better;

(5) professionals do not need to answer "yes" to all requests ". However, they should try their best to find innovative ways to be responsive. When professionals make a positive response, they will use the term of commitment to ensure that each party can understand the content of the commitment without error;

(4) Encoding

(1) coding principles

1) First, the Code must work properly;

2) The code must help you solve the problems raised by the customer;

3) The code must be seamlessly integrated with the existing system;

4) other programmers must be able to read your code;

(2) do not encode the Code if you are tired or upset. It is strong and can only be reworked later. On the contrary, we need to find a way to eliminate interference and calm down our mood;

(3) pairing is a good way to deal with interruptions, and TDD is another helpful method;

(4) Extensive Reading, including software, politics, biology, aerospace, physics, chemistry, and mathematics, can stimulate creativity: "creative output" depends on "creative input ", creativity will stimulate creativity;

(5) software development is a marathon rather than a sprint. You cannot keep sprinting at the fastest speed to win the game. You only need to save your strength and maintain a stable pace to win the game;

(6) The key to managing latency is early detection and transparency;

(5) Test-driven development

(1) Three Principles of TDD

1) do not write any product code before preparing failed unit tests;

2) as long as one unit test fails, do not write the test code, including failing to compile the code;

3) The product code can make the failed unit test pass successfully. Do not write more;

(2) TDD is the choice of professionals. It is a principle that improves code certainty, encourages programmers, reduces code defect rates, and optimizes documents and designs.

(6) exercises

(1) Professionals must use specialized training to improve their skills;

(2) One Way to stay out of date is to contribute code to open-source projects;

(3) My understanding: exercises are like homework in the student age. They are completed on a daily basis. The exercises include: classic algorithms, common data structures, and design patterns;

(7) Acceptance Test

(1) Business-related and program-writing personnel are prone to fall into a trap, that is, early refinement;

(2) the acceptance test is defined as a test prepared by the business side in cooperation with the Development Party. The purpose is to determine that the requirement has been completed;

(3) the business analyst tests the "correct path" to prove the Business Value of the function. QA tests the "wrong path", boundary conditions, exceptions, and exceptions;

(4) code for implementing a function should begin after the corresponding acceptance test is completed;

(5) Acceptance testing is not a unit test. Unit Testing is written by programmers to programmers. It is a formal design document describing the underlying structure and code behavior. Acceptance testing is written by the business side to the business side, they are formal requirements documents that describe how the business team thinks the system should run;

(6) The entire continuous integration system should be triggered by the source code management system. Once code is submitted, the continuous integration system starts building and runs all tests. The test results are emailed to all team members;

(8) Test Strategy

(1) the development team should make "QA" should not find any errors "as the goal of its efforts;

(2) QA plays a role in the Requirement Specification definition and feature description;

(3) Professional Developers follow the requirements of test-driven development to create unit tests. Professional development teams use acceptance tests to define system requirements, and use continuous integration to ensure a steady improvement in quality;

(4) test pyramid. The order from bottom to bottom is: unit test --> component test --> integration test --> system test --> manual Exploratory Test. unit test is the cornerstone.

(9) Time Management

(1) Core of the Standing Meeting:

1) What did I do yesterday?

2) What are I going to do today?

3) What problems have I encountered?

(2) The iteration plan meeting is used to select the development tasks implemented in the next iteration;

(3) Any dispute that cannot be resolved within five minutes cannot be resolved through debate. Such arguments are based not on facts, but on beliefs. The only way out is to talk with data.

(4) use the tomato working method to manage the time. (Well, I didn't expect Uncle Bob to use this too)

(5) The importance of sleep cannot be emphasized too much to ensure 7 hours of sleep!

(6) behaviors to be avoided: disordered priorities, dead ends, and Quagmire. If you fall into the trap, do not continue digging!

(10) Estimate

(1) Professional Developers do not promise anything unless they know exactly that it can be done;

(2) professional developers can clearly differentiate estimates and commitments. Only when they know exactly what can be done can they make a commitment. In addition, they will be careful not to give a suggestive commitment. They should explain the estimated probability distribution as clearly as possible so that the supervisor can make appropriate plans;

(3) The three-element analysis method of estimation practice is classified as optimistic prediction o, nominal prediction N, and pessimistic prediction P. The result u = (O + 4n + p)/6;

(4) Delphi method of estimation practice: a group of people gather to discuss a task, predict the completion time, and then repeat the process of "discussion-estimation" until the opinions are unified;

(5) estimation is very error-prone. One of the ways to control errors is the law of big numbers: divide large tasks into many small tasks, separate estimation, and add total.

(11) Pressure

(1) professional developers can be calm and decisive even when there is pressure. Despite the increasing pressure, he will still stick to his training and discipline. He knows that these are the best ways for him to overcome the pressure brought by the deadline and commitment;

(2) The best way to stay calm under pressure is to avoid situations that will lead to stress;

(3) ways to avoid stress

1) do not make unrealistic commitments;

2) Make the system, code, and design as clean as possible;

3) remain disciplined in crisis situations;

(4) deal with pressure

1) Avoid desperate ideas. Reckless rush will only bring you into a deeper abyss. On the contrary, you should relax and think carefully about the problem.

2) Communicate with teams and supervisors;

3) believe in and rely on your disciplinary principles;

4) pairing for help;

(12) Collaboration

(1) The worst symptom of an abnormal team is that every programmer builds a high wall around his/her code and rejects other programmers from accessing the code;

(2) Professional Developers will not prevent others from modifying the Code; the entire team is expected to have the code, not the individual;

(3) pairing professionals is the most effective way to solve inter-procedural cooperation and the best way to share knowledge;

(4) the most efficient and effective code review method is to write code in collaboration;

(13) teams and projects

(1) It takes time to form a team. Team members must first establish relationships. They need to learn how to collaborate with each other. They need to understand each other's preferences, strengths, and weaknesses. In the end, they can be integrated into teams.Otherwise, it is a group, not a team!

(2) The ideal team is 12 members, 7 programmers, 2 testers, 2 analysts and 1 Project Manager;

(3) create a cohesive team and assign new projects to them constantly instead of building teams around the project;

(4) The team is more difficult to build the project. Therefore, it is better to build a stable team and move the team together in one project or another;

(14) coaching, apprenticeship and skills

(1) so-called masters

Programmers who have led many important software projects. Generally, they have more than 10 years of experience and have worked on multiple different types of systems, languages, and operating systems. They know how to lead and coordinate multiple teams. They are skilled designers and architects who can program with ease.

(2) The values and technical acumen of professionalism need to be constantly taught, nurtured, nurtured, and simpressed until they are deeply embedded into the culture;

[Development tools used by Uncle Bob]

Use git to control source code, use tracker to manage bugs, use Jenkins for continuous building, use intellij as an integrated development environment, use xunit for unit testing, and use fitnesse for component Testing

[Appendix: Uncle Bob's incomplete Resume]

 
(1) 1968 self-taught computer programming, 15 years old, learning PDP-8 assembler, Fortran, COBOL, PL/1;

(2) In 1970, I did not go to college. I was hired as a programmer by ASC, 17 years old;

(3) 1973, 20 years old with his wife Ann
Marie is always connected, and his wife was just 18 years old for the past three days. Uncle Bob said with deep affection:"For 38 years, she has always been my unwavering companion, my rudder and my sail, and my love and life. I look forward to working with her for another 40 years.!" It seems that a superior programmer must be a person who loves his wife and family! This is in line with me!

(4) So far, Bob has compiled a program for 42 years and has two female and one child with his wife!