Highlighting the Key Points What Aspects Do You Need to Focus on Regarding Task Breakdown

Key Points Regarding “Task Decomposition” #

Hello, I am Zheng Ye. Congratulations on completing another module of your studies.

In this module, I mainly explain the work principle of “task decomposition,” which is a difficult concept to put into practice despite its apparent simplicity. The difference between an ordinary person and an expert largely depends on the granularity of task decomposition. However, truly understanding and effectively applying the principles of task decomposition is not easy. I hope you can practice diligently and internalize this knowledge to become your own skill.

Key Review #

In this module, we have learned some best practices:

  • Testing Pyramid - The best practice of test combinations in the industry. Writing multiple unit tests is key.
  • Test-Driven Development (TDD) - The rhythm of TDD is: red-green-refactor, where refactoring is the key that distinguishes TDD from test-first. Some people understand TDD as test-driven design, bringing a mindset change to the industry to write testable code.
  • Eisenhower Matrix - Divide tasks by importance and urgency. Do important and urgent tasks immediately. Important but not urgent tasks should be our priority. Urgent but not important tasks can be delegated. Avoid doing tasks that are neither important nor urgent.
  • Minimum Viable Product (MVP) - A product that meets customer needs just right. In practice, we need to find a feasible path at the minimum cost.

Additionally, I mentioned some practices and criteria that can be directly applied in work:

  • Avoid writing static methods as much as possible.
  • The main branch development model is a better branch model for development.
  • Good user stories should follow the INVEST principle.
  • Estimation is a process of deepening understanding of requirements, and good estimation is based on task decomposition.
  • Good tests should follow the A-TRIP criteria.

I also introduced some important ideas to help improve your development work:

  • Divide and conquer is the basic means for humans to solve problems.
  • Software change cost increases gradually over time and development stages.
  • Test frameworks introduce automated tests as a best practice into the development process, enabling test actions to be standardized and fixed.
  • Extreme Programming is called “extreme” because it pushes good practices to the extreme.
  • The secret of master-level programmers is task decomposition, breaking down tasks into manageable micro-operations.
  • Arrange development tasks in the order of fully implementing a requirement.

Practical guide #

In the “Task Decomposition” section, I also condensed each content into a “one-sentence” practical guide. Let’s review them together.

Additional Gains #

At the end of this section, I have also provided answers to popular questions that you may have during the learning process. I hope you understand:

  • For tasks that you are not familiar with, you need to first understand the technology before breaking down the task.
  • Learn new technologies through a Spike.
  • Discard the prototype code developed during the Spike process.
  • Differentiate between the goal and the current situation, use the goal as a direction to guide the change in the current situation.
  • Consider using Feature Toggle for parallel development of multiple features.
  • Consider using Branch by Abstraction for making changes to legacy systems.

——“Answering Questions | How to Break Down a Technology Task You Are Not Familiar With?” (Link: http://time.geekbang.org/column/article/81515)

Selected Comments #

In the “Task Decomposition” module, many students have shared their learning experiences and work experiences. Here, I have selected some comments from students to study together with you.

When discussing the working secrets of master-level programmers, Xixi Fu and Kafka mentioned:

Recently, I’ve been doing strategic decompositions, which follows the same principle. Strategy is floating in the air and seems unattainable. To make it happen, it needs to be decomposed. For example, what are the aspects we can focus on to achieve our goals, and what actions should we take in each aspect. This is the path. Among these paths, which ones have the highest priority and require allocation of organizational resources. After having a clear understanding, we can make a plan and set a timetable.

In addition, Xixi Fu and Kafka also gave a vivid explanation for “Spike” to Spike:

“Technical Spike” can be translated as “technique flirting”, just like flirting with someone you like. You try to see if there is a chance, and if there is, you continue; if it doesn’t work, you move on or give it some time.

Regarding the issue of granularity in decomposition, Dabin also shared his insights:

I am good at task decomposition, which is not only executable but also has a very fine granularity. For example, if I need to fix a bug in an RPC interface, I will list each code modification, the tests to be modified, the tests to be added, the branch to be merged, the modification of the RPC document, and the points that need to be modified in the document. Every step is very easy to execute and may not seem necessary, but it is very useful in my current work environment: (1) Pre-thinking can prevent omissions; (2) During the implementation of the task, I am often interrupted, such as having discussions with testers, supervisors asking for discussions, or urgent meetings. These “hard interruptions” completely disrupt the rhythm, but the task list allows me to know how much progress I have made and where to continue from.

Regarding unit testing, Shugen mentioned:

My idea is to start writing unit tests for complex and critical core modules first. Especially for shared and low-level modules, as it is difficult to cover them with functional testing. The difficulty of promoting unit testing is mainly due to the lack of a quality pain point. Usually, quality is guaranteed by test engineers. We have encountered a quality collapse in the past, which forced us to do unit testing to ensure quality.

Shugen also shared his experience in task decomposition:

I recently changed my programming habits. I first write down the ideas, knowledge points, APIs, etc. that I need to use in Notion, and then write down the tasks and corresponding key code snippets. Finally, it only took me about 10 minutes to actually code. I came across this article when I started to read Geek Time again, and I strongly agree with it. I particularly admire the code written by foreign engineers, the code blocks are very small, and very clear and readable. I still remember attending the InfoQ conference before, listening to the sharing of the author of SocketIO, and seeing him coding on-site. The ideas and code structure were very smooth and clear.

Regarding the specific application of TDD, Xiao mentioned the problems encountered:

When I first encountered TDD not long ago, I was amazed by its ideology. It seems that it can greatly improve coding efficiency, and it can also ensure code quality during refactoring. Later, I also tried to use its ideology when writing code, but to be honest, understanding is one thing, but using it is another. Many things are not very proficient, and it takes more time in the early stages. Due to a lack of experience and familiarity, I don’t know how to write some tests. Now that I have written more, I feel that the code quality has improved. There are fewer bugs, and making changes under requirement changes no longer hurts the code structure. However, there are still many areas where I feel I can do better. After reading this article, I have supplemented my understanding of TDD and feel that TDD will have better results when combined with task decomposition. Looking forward to more articles on this topic!

Regarding the execution of “Task Decomposition”, Xuming mentioned his insights:

I have a deep understanding of task decomposition. When I first joined the company, I was not good at task estimation. Looking back now, there are mainly two reasons: (1) unclear requirement analysis. We started writing code before clearly understanding the requirements, leading to rework and “unexpected” situations. (2) Poor task decomposition. The tasks were not broken down into clear and executable units, which sometimes made it difficult to start, and the time estimation was inaccurate.

When discussing why many people’s tests are not good enough, Yi mentioned:

In this section, I have the following insights: (1) From the developer’s perspective, coding and testing are inseparable and can form a virtuous cycle through refactoring, similar to the feedback model and red-green refactor model mentioned in previous courses. (2) A-TRIP is a good summary and action guide, which should be followed consistently in future work to ensure solid and effective work. (3) In terms of the issue of database dependency mentioned in the article, I would also like to share my thoughts. I think in test code, we should try to avoid interactions with the database. Testing focuses more on domains and business logic, and more often, it’s resources and services that fail, as changes in models often involve changes in table structures. Rather than trying to cover both ends, it’s better to focus on the models. However, I often use test cases combined with several small files (with data corresponding to the model), which ensure that all steps before the database operation are correct and also facilitate adaptation to changes. Once there is an exception, it is also relatively easy to determine whether it is caused by a database operation. (This point is based on my observation in work. Most project programmers are eager to define the table structure. It seems that without doing this, writing code is not solid enough.)

Regarding the management of requirements, WL mentioned a key point:

Programmers should also be more proactive and preferably be able to drive things forward. When you take the initiative to push things forward, you have the control in your hands.

Thank you for the wonderful comments from the students. In the next module, I will share the specific application of the principle of “Communication and Feedback”.

Thank you for reading. If you find this article helpful, feel free to share it with your friends.