order matters

August 25 17:43~18:21

截圖 2022-08-25 下午6.19.14

foreword

Over the past two years, I have been mobbing with the ezKanban team. The back-end has applied Domain-Driven Design (DDD), Clean Architecture, Event Sourcing, CQRS, TDD, Design By Contract (DBC), and Living Documentation. Almost all of the back-end architecture started at the beginning All designed by Teddy. This is normal, because ezKanban is a software research project developed by Teddy and his students.

Sometimes Teddy needs to attend class and cannot participate in mobbing. After returning from the course, he found that the team quickly completed some functions when Teddy was away, but the design method was not very good, so Teddy would discuss the design with the team and see how to repurchase.

***

order

Scrum has three roles, Product Owner (PO), Developer, and Scrum Master (SM). In one sentence, their responsibilities are:

  • PO: Do the right thing
  • Developer: Do the thing right
  • SM: Do it faster (continuous improvement)

The order in which these three things happen makes sense. First of all, to ensure Do the right thing, to understand what problems users and customers encounter in the problem domain? Second, design good software to solve these problems. Finally, continue to improve the entire development process.

Many developers are very concerned about whether the computer is up-to-date and whether the IDE’s hotkeys are well used. Both of these things are important, and both can shorten development time. But one thing more important than them is that you need to make sure you’re doing the right thing first. Your requirements, architecture, and design are all right, otherwise you’re just doing the wrong things faster.

***

iterate

The above three things, the process of their occurrence and practice, is not a linear process, but an iterative process. That is to say, first understand the requirements a little bit, then do some design, write some programs, and then improve; then repeat the process. In the process of mobbing between Teddy and the team, the first emphasis must be on demand. Why do you want to do this function? Identify a requirement before discussing how the domain model and architecture will meet that requirement. As for the improvement of the development process, the tool class only accounts for a part, it is a very important part but not the most important part. Teddy will only require you to be familiar with the basic functions and shortcut keys of the IDE, and to automate and virtualize the development environment, test environment, and subordinate environment as much as possible. During Mobbing’s time, the process improvement that Teddy cares about is whether it can improve the design ability of the team, let everyone use their brains, and be able to express one thing clearly. As for the improvement of IDE familiarity, if you want to reach the level where you don’t need to use a mouse at all, those who are interested can practice it in private.

Although these three things happen in an iterative way, you still need to pay attention to the order, don’t just pay attention to do it faster at the beginning, and don’t care what the things are typed into the IDE, then put the cart before the horse.

***

Youzo’s inner monologue: Garbage in, garbage out.

This article is reprinted from https://teddy-chen-tw.blogspot.com/2022/08/blog-post_25.html
This site is for inclusion only, and the copyright belongs to the original author.

Leave a Comment