Highlighting the Recap of Key Content on the Theme of Automation

Key Points Summary on the “Automation” Theme #

Hello, I’m Zheng Ye.

The “Automation” module has finally been fully updated. So far, I have introduced all four working principles to you. Comparatively speaking, this module’s content is relatively “hard,” and I have tried my best to connect more knowledge for you. Therefore, the amount of information is quite substantial. I hope you can find the direction for your future efforts and continue to enhance your “hard skills”.

Key Review #

In this module, we learned some best practices.

  • Continuous Delivery

    • Incorporating production deployment into development considerations.
    • The infrastructure of continuous delivery typically includes continuous integration environment, test environment, pre-production environment, and production environment.
    • The build pipeline ensures that downstream deliverables are validated by upstream.
    • With the emergence of Docker, delivery has shifted from release packages to Docker images.

  • DevOps

    • Integrating development and operations.
    • Advancements in infrastructure configuration tools have made infrastructure as code industry consensus.

  • Acceptance Testing

    • Acceptance testing should be written from a business perspective.
    • BDD is a way to write acceptance tests.
    • Given…When…Then… provides a unified way to describe business logic.
    • Building a test model is necessary for writing good acceptance tests.

  • SOLID Principles

    • The principles behind design patterns.
    • Single Responsibility Principle (SRP).
    • Open–Closed Principle (OCP).
    • Liskov Substitution Principle (LSP).
    • Interface Segregation Principle (ISP).
    • Dependency Inversion Principle (DIP).
    • Single Responsibility Principle can only be applied effectively when the problem is viewed at a smaller granularity.

  • DDD

    • It brings the focus of thinking on the business.
    • DDD consists of strategic design and tactical design.

  • Microservices

    • Good microservices start with well-defined bounded contexts.
    • The first step in microservices is not to divide them.

In this module, we also learned some important strategies to improve our work.

  • The three virtues of programmers: laziness, impatience, and hubris.
  • Beware of the Not Invented Here Syndrome (NIH Syndrome).
  • Write good build scripts and automate the project.
  • Refer to the Java knowledge system and learn about operations.
  • The most basic principle of software design is “high cohesion, low coupling”.
  • Layered architecture is a design breakdown.
  • Systems of different business volumes are fundamentally different systems.
  • Solve problems with simple techniques until they become complex.

Practical Guide #

Additional Harvest #

At the end of this module, I have answered some of the questions you may have during the learning process and provided you with a train of thought to better understand the content you have learned:

  • Extension of Continuous Integration:
    • Continuous Integration completes system integration.
    • Continuous Delivery completes deployment and release.
    • “Continuous Validation” completes the validation of product ideas.
  • AB Testing is used to validate ideas with multiple versions of software.
  • Selenium is used for browser automation.
  • Proficiency in using keyboard shortcuts.

——“Q&A | Continuous Integration, Continuous Delivery, and then?”

Select Messages #

When talking about “laziness” being the pride of all programmers, jxin mentioned:

Valuable things are not limited to the things themselves. Automation is important, and writing code is important. However, it is also important to judge whether automation and coding are necessary based on the current situation. Targeted tasks decomposition. Balancing and design are artistic and fascinating.

In addition, jxin also shared his understanding of continuous delivery:

Divide and conquer is a powerful tool for solving complex problems. Continuous interaction, like taking small steps quickly during refactoring (running test code after each adjustment to validate), ensures the steady progress of large projects. And because the units are small, they are also flexible. Continuous interaction can be combined with the concept of minimal product, testing at a small cost, gathering data, and adjusting product development direction in real time.

Regarding software design, Yi shared his insights:

We often say that when we get a task, we should not rush to do it, but start from the design and spend more time in the front. In work, we found that everyone thinks before taking action. So why does the deviation become larger as we go further?

The common reasons are twofold: first, there is not enough global view, which means limited context and delayed feedback (not raising the problem until it cannot be avoided by the code);

The second reason is the lack of domain concepts and conscious practice (talking on paper), especially for process-oriented tasks. People like to define the table structure first and then generate entities, so from the perspective of the domain, these entities are not suitable. The result is that we write procedural code with object-oriented tools. Since it is procedural, the principles of object-oriented design are rarely applicable. These two points are my understanding of the two necessary conditions for good software design.

When talking about layered architecture, Desmond mentioned:

After learning REST and DDD, I feel that the two have similarities: both focus on data (one is resource, the other is domain object) and establish a set of standard data operations (HTTP Verb in one case, and mainly use JPA in the other project); and the core is business modeling.

Regarding the understanding of microservices, Fengao mentioned:

The company says that our development method is agile, but in reality, we only use some of the agile development methods. Only by following the values and principles of agile development can it be considered agile development. The same applies to microservices. It is not called microservices simply by splitting them into multiple services for deployment. It is not microservices just because commonly used microservice frameworks are used.

On the question of what a good project automation should look like, Xixi and Kafka mentioned:

Imagine this scenario (not implemented yet, planning to give it a try): we hire a skilled programmer, from the moment they join, they can develop sample code, submit it to SCM, then CI/CD, and finally release to users online, the whole process can be completed before lunch on the first day of work.

This not only requires automated building and integration, but even requires every link from joining to be prepared in advance, including machines, development environments, online environments, etc., and even the demonstration requirements must be promptly passed on to the programmer. In an ideal situation, the programmer only needs to develop good programs, ensure quality, and submit to SCM, and everything else should be done by machines.

You know, programmers are expensive, the earlier you deliver value to users, the better.

For automated acceptance testing, Shniu shared his learning insights:

Automated acceptance testing is indeed a good thing. For example, in regression testing, it saves a lot of repetitive work. But I understand that the original intention of BDD is to drive discussions and communication of requirements among products, business, development, testing, etc., to instantiate stories before writing code, and to define acceptance test cases together, so that everyone has a thorough understanding of the requirements, and especially to describe it from a unified business perspective. Therefore, doing good BDD requires constant exploration and summarization.

On the topic of “building Taobao with 50,000 RMB,” Enjoylearning mentioned:

To build a system similar to Taobao, the customer refers to a business similarity. However, factors such as user volume, required concurrency, and search performance need to be determined through communication with the customer before deciding on the technology stack. In reality, some of our systems already meet business requirements, so there is no need to split them for the sake of pursuing technological complexity. Only by selecting technology based on specific problems can there be effective results.

Regarding operation and maintenance knowledge, Hua168 provided additional content:

DevOps is popular in the field of operation and maintenance nowadays, and the more advanced one is AI. One article, “Detailed Analysis of DevOps,” is good, link: https://infoq.cn/article/detail-analysis-of-devops

“Building DevOps Knowledge System and Standardization” is also good, download link: https://yq.aliyun.com/download/778

Operation and maintenance knowledge system: https://www.unixhot.com/page/ops

Web cache knowledge system: https://www.unixhot.com/page/cache

Thank you for the wonderful comments from the students. In the next module, I will analyze the “thinking framework” and the “four principles” we have discussed so far in the context of specific application scenarios.

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