I recently read Uncle Bob's "Professional Qualities of Programmers". The article discusses the word "professional" and how programmers make others feel professional.
sequence
The article mentioned that interview questions are often asked in such interviews, what difficulties did you encounter at work and how did you solve them? In fact, many interviewers don't care about how difficult your difficulties are at all in this question, and they pay more attention to your problem-solving process and the depth of your excavation of the problem. Through these, you can interpret the depth of your thinking about the problem and whether you are curious enough about your work.
profession
Responsibility, untested features are never delivered
Product quality, take zero bugs as the eternal pursuit, the unit test rate reaches 90%, and the code is constantly refactored
Work ethic, work efficiently for employers, work 20 hours per week for yourself
Areas of expertise, design patterns, design principles, methodologies, practices and diagrams
Business area
say no
Professionals dare to tell the truth without succumbing to power, and professionals have the courage to say NO to their managers!
If the schedule is tight, you can determine which features can be delivered on time.
Sometimes giving too much detail just invites more micromanagement.
By promising to try, you're actually making sure you'll succeed, and if you don't live up to your expectations, you've failed.
Fast is slow, break these disciplines and principles, if you don't design the code well, it will get slower and slower later, until the project fails
Said to be
Identify signs of lack of commitment, need, should, hope, hope
A real commitment has a specific date, xxx days to complete, weekdays to complete
Reasons why promises cannot be completed, relying on other modules, too many tasks are really impossible to complete (you can only try your best to achieve your own goals), uncontrolled risks
(The sooner you throw the better, you can replace the current promise with another promise)
coding
The first point is to implement the problem you need to solve
The relationship between the second point and the existing system, without destroying the function of the existing system
The third point is to let other programmers understand your program
Software development is a marathon, not a sprint, you need to conserve energy and a steady rhythm to win
TDD Test Driven Development
First point, don't write any production code until you've written a failing unit test
The second point is that as long as a unit test fails, no more unit test code is written, and failure to compile is also a failure condition
The third point is that the production code is just enough to make the failed unit test pass successfully, don't write too much
TDD advantages, functional, easy to refactor, design decoupling
practise
Acceptance Test
test strategy
time management
refuse unnecessary meetings
Choose the right time to leave the meaningless meeting
Keep up with the agenda and goals of the meeting
Standing meeting, what did you do yesterday, what are you going to do today, and what problems did you encounter?
Time splitting and the Pomodoro Technique
Avoid priority confusion
estimate
Professionals can distinguish between estimates and commitments, and they only commit when they know for sure that it can be done.
Project evaluations that are overly optimistic, they end up taking 3 to 5 times longer than estimated.
Professional developers should be careful to set reasonable estimates, no matter how stressful it is to try to work overtime.
The large task is divided into small tasks for estimation, and the estimation error rate of the small tasks can be ignored.
pressure
Avoid stressful but unsure commitments, keep code clean, follow development discipline
Coping with stress, staying calm and relaxing, finding team help, maintaining development discipline, pair programming