Architect cultivation II-Expression of thinking and control methodology

Before the opening, I want to talk about the development of that year: about 10 years ago, when I was a programmer, I often encountered such a project development process:

• Solution: a pile of documents (many of which are copied on the Internet) for the customer's purposes and bidding purposes are written in words.
• After the bidding is completed and the customer pays the deposit, the project team is established. It is usually a project team model of (0 to 1) Project Manager or project owner + (1 to n) programmer.
• DESIGN: The design should be written by the project's headers or experienced members. In bad luck, we will get a software-engineeringDesign Ideas in Chinese format (Sorry, I can only describe it like this.),What's more, I got a rose document that I couldn't fully understand. (in that age, UML was a brilliant time, and I was totally blind to UML)
• Development: Only my participation is available here. The previous content is usually not transparent as a low-level person in the project team. After obtaining the "design", we can only rely on our own "conjecture" to achieve it. Finally, we can use the interface to show the manager whether it meets his "design requirements ".
• Test? This project does not exist, as long as the program can run through the direct delivery.

 

The results of the project are self-evident. The most common communication is quarrel and reprimand, or complaints from customers. This is a ridiculous example, but it is even more ridiculous that many of my friends have told me about this kind of experience. They are not without design, communication, or management, but are expressed in their own ways, without a common language or communication. So will a project manager with strong communication skills change this situation? Possible, but the most common problem is improvement. It is only because B's role is changed to a project manager, because there is not much change in nature.

 

I am very grateful to me for having such an uncomfortable development experience. It was so sad that I had to find a way to learn and finally try to change it. The following part will be a summary of my experiences over the past 10 years, because I learned many things and didn't have the knowledge at that time. I had to go forward in project practice, I am greatly influenced by MSF and agile development, and I am an anti-UML person, but I have not completely adopted a standardized development method and development process, over the years, I have applied my understanding of these methodologies to my projects, but I don't want to talk too much about the development methodology and project management, instead, we will extract the content related to the architecture and design and discuss it.

Express the responsibilities of the thinking architect

The two most difficult tasks in the world are to put the money in others' pockets into their own pockets and put their thoughts into others' minds. In everyone's impression, the project manager is the most communicating role in the project. In fact, the architect's communication volume is no less than that of the Project Manager. In China, architects and project managers are the same people. As the chief designer of the system/project, I simply want to come up with a technical solution for the customer and then make a design to the project team, the design intent and concept should be introduced or explained to each member or role of the project at different levels.

 

Effective communication

The main content of this article is simply some of the methods and methods for architects to sell their own designs. In addition to development and design capabilities, "effective communication" is also an important skill for architects. The architect and the Project Manager have different working hours and content, but if they do not communicate properly, the architect's design time will be greatly consumed due to repeated communication, what's more, a design that is hard to understand is that, even if the amount of gold is high, it can only be in an awkward situation without finding bole. Another reason why I think of communication as a practice is that these contents are invisible to books and can only be accumulated from practical practices, different experiences may have different opinions and experiences. The following is a summary of my accumulated experiences over the years:

If the development process is a large iteration, the design also needs to be iterated and perfected. the ideas and suggestions of every participant in the project are the reference sources for the accumulated iteration of the architect's correction design, so communication isBidirectional agitation.

According to the role with the highest frequency of communication with the architect in the project, as well as their skills and information needs, I decided to look at how to achieve the most effective communication with them:

 

Sales

• Communication requirements: Find selling points and characteristics from the design, enrich sales plans and customize pre-sale plans.
• Knowledge and skills: the development or in-depth technical content may only exist in the conceptual understanding, master the first-hand information of the market and the most familiar understanding of the customer's needs.
• Recommended tools: Full Feature list, field: Special Feature + description (Summary)

Taking Product Development (it is easy to do projects without this step) as an example, I will discuss with sales the 10 most distinctive project functions of the entire product (in fact, three items are enough, practice tells me that only the first three items are the most memorable ones. These 10 features are also called "purchase reasons", and then the full features of the entire system ), I often have a fierce collision with sales because of a specific feature, but in the end, they play the most important role in the design sales, and sometimes even directly affect the feasibility of the project.

Practice:

• Discard all technical implementation details and write/express the three most important features of the Product
• Abandon all technical implementation details and listen attentively to "non-professional" Opinions

This practice seems very simple. It is more important than practice. It is not easy for professional technicians to do. Details determine success or failure. The simplest and least noticed person or thing may be a key point.

Project Manager 

• Communication requirements: Time Estimation, project resource preparation, and Work Breakdown based on the design.
• Knowledge and skills: mostly familiar with the knowledge of System Architecture (understanding is biased towards technology or management), keen on communication and tracking
• Communication tool: Excel
• Graphic tools: Architecture diagram and schematic diagram

 

The project manager is the most important partner of the architect in the project, because he is responsible for tracking and ensuring that the whole process of your design is implemented by the project resource provider and progress controller, he needs to understand each checkpoint and milestone, which is also the most important connection point between the project manager and the architect ). What I have discussed most with the project manager is the principle of system implementation and the possible existence of each part of the implementation.DifficultyAnd possibleRisks,

 

Practice: Use the simplest Visual Design

 

The following two figures can be used as examples in a few public projects. The design tool I use is Excel:

 

Example 1: Technical Architecture

 

Example 2: Application Architecture

Note: These two legends are the architecture diagram of my many years open-source project dotnetage CMS. If you are interested, visit GitHub or the dotnetage official website to learn more.

 

Development 

Need: Prepare the technology, develop the environment, compile the demo and final code according to the design requirements, and care aboutTechnical details and implementation methods.

Knowledge and skills: Master or master specific development tools and development skills

Communication tool: Sample Code

Graphic tools: sequence diagram, state diagram, class diagram

 

Communication with developers is the most difficult and radical step. Developers are like children who are brave enough to try new things, it is not easy to keep them completely "disciplined" without institutional and administrative pressure. I don't think that architects or project managers should lead other members in terms of status and administration. In fact, this "natural level" is not conducive to communication, and it will make the project team a "simple saying ". The best way to communicate effectively with developers is to "speak with code", which is why I proposed in the first article that the architect also needs to be a code control.

What we deliver to developers is empty public interfaces or public classes. Developers cannot arbitrarily change the names of any interfaces, classes, and methods. This is the most basic convention, otherwise, it will be messy. In addition, the Code for the core, multi-user use, and complex principles must containSample Code. The code example is a dedicated area for discussion and activation with developers. It is also the best way to get started for future project participants, this greatly reduces the likelihood of invisible, difficult to implement, and high-risk code.

 

Practice: Design and write sample code to make sample code part of the design

 

Test 

• Requirement: divide the test granularity according to the design, prepare the test environment, and customize the test plan.
• Knowledge and skills: Master test skills and methods
• Communication tools: Class usage reference
• Graphical tools: Architecture diagram, sequence diagram, state diagram, class diagram

I think testers often have the same architecture capabilities as any architect. They can only find problems from regular tests (unit tests and interface tests) as the most elementary testers, tests that can discover problems in system performance, processes, or architecture depend on experience, experience is even a kind of intuition or ability to "sniff" the problem (in the next article, I will explain in detail the source of this ability ). Communication with testers is similar to development. However, when there is no advanced tester configuration, the architect can only assume this role, as a software designer, they are the best able to understand the possible problems in their systems. During communication, these "problems" are the focus of communication. When necessary, they need to observe the results of the test report repeatedly, to find out the hidden danger. The so-called practices here are basically the same as those above.

 

Only common roles are classified here. Different development methods may lead to more roles, such as RM (release manager) and TM (technical manager) and so on.

 

Control Methodology

The previous article discussed how to express some methods and opinions of design and ideas to people with different roles. The ability of architects is also important. Understanding, understanding, and practice of methodology have become the true "cost" of architects. The popular language is the so-called "core value )".

I am a very dull person. I have read a lot of this knowledge for more than 10 years, but I can really understand and use it with only two or three. It is really due to the environment and experience limitations, many theories have no specific environment and can only be viewed as novels. I learned the methodology with my only experience:

"The learning curve of methodology is iterative.That is to say, the same theory will have a deeper understanding and new understanding after re-learning after different experiences ."

I have never stopped iterative learning and practice in design patterns alone, and I have gained a new understanding and experience in every practice.

In the next article, I will describe the methodology that I think has the greatest value for iterative learning.

 

Framework Theory

The term "Framework" has been used in recent years along with the successful promotion of. NET Framework, and it may be due to the market effect. I came into contact with this term or this theory before. Net was born. Before I began to explore the framework, I found a piece of appropriate definition in the software framework on whatis:

Original article:

In general, a framework is a real or conceptual structure intended to serve as a support or guide for the building of something that expands the structure into something useful.

In computer systems, a framework is often a layered structure indicating what kind of programs can or shoshould be built and how they wowould interrelate. some computer system frameworks also include actual programs, specify programming interfaces, or offer programming tools for using the frameworks. A framework may be for a set of functions within a system and how they interrelate; the layers of an operating system; the layers of an application subsystem; how communication shoshould be standardized at some level of a network; and so forth. A framework is generally more comprehensive than a protocol and more prescriptive than a structure.

From whatis.techtarget.com

 

A framework is usually used to explain how to build a useful thing and its implementation or concept. In computer systems, a framework is usually used to describe the hierarchy that a program should build. Some system architectures may even contain actual programs, interfaces, or development tool sets. A framework may be a set of related functions, a certain level in the operating system, a certain level in a subsystem, or a standard communication mode under a certain level in the network. A framework is generally more comprehensive than a Protocol definition, and more standardized than a structure definition..

For design purposes, my understanding of the Framework is:A framework is a design guide used to define and lock the scope of understanding and implementation of a concept. It can be embodied in its implementation and can be iterated under the established boundary.. The architect has a general design blueprint. This is a methodology I like to use. Microsoft's function spec in MSF is a bit similar. It is the first refined output of user requirements in the form of technical architecture. I like this methodology because it is "simple", "highly flexible", and does not need to be standardized (standardized things do not need to be designed, but only need to be applied, that is the pattern ), you only need to master the two principles.

 

Build a whole picture)

When reading the framework document, even if all the content is forgotten, the whole design drawing can be printed in the reader's mind to achieve the goal. This is a guide and the starting point of thinking. A common picture will naturally lead to a common discussion point, locking the boundaries between design and the topic. It is also an important basis for system evolution.

 

Define a boundary (compressive definitions)

The so-called boundary is actually for the module to be drawnFunctionThere is a clear and clear text expression that allows readers to gain an in-depth understanding of the specific meaning of each part after creating a panoramic blueprint, so as to gain a deeper understanding of the system.

 

How to Learn

The simplest way to start is to start with the system you are familiar with or understand, and re-describe its framework. Then, set the definition of each part you know into it, and you will find that you have a new understanding of the existing system. For tools, you can use the most primitive paper and pen, and use Excel after skill (to be more beautiful, you can use Photoshop ), the most important thing is not to let the tools distract you from the concentration of your thoughts, so it is easy.

 

At this point, if you start to try this method, you may understand why the beginning of my series takes so long to say that to become an architect, you must first become the necessity of code control, starting from the blueprint, we need to go beyond the language restrictions and have a deep understanding of the language.

 

UML

To become an architect, UML is a required course. The relevant materials and learning resources are extremely rich, and the relevant learning methods are also very personalized. I will not go into detail here. I just want to share some of my experiences in learning and using UML for design. First, you must be familiar with all the basic concepts of object-oriented systems before starting with UML. Otherwise, it will be a waste of time. Then there is selective learning. After all, UML is a very old methodology. Even if we use the UML theory as the core development guide in version 2.0, it will be a great weapon! Look at the best X design tool of the year: Although Rational Rose is powerful, I think it is more like a toy. His so-called documents can only be viewed by designers. the use case is basically a combination of ugly and non-human thoughts, basically, I don't have to because he is very inconvenient in communicating with people and organizing his own ideas. It's better to simply write two sentences in text to illustrate the problem (it's just a personal remark ).

UML is the common sense of design, but it should not be taken as a blueprint. It is important to discover and sort out the relationship between classes, classes, or classes and classes, and to interact with each other. My method is to learn only the graphics without learning the process. What people can understand is the design, and do not need to install any special UML tools, excellent ide generally comes with some UML graphical tools, such as Visual Studio. In short: "active"

 

Design Mode

The design pattern is a double-edged sword for architects to solve complex problems. When used, problems may be greatly simplified or even cleverly solved, however, poor use may also lead to uncontrollable expansion of the system architecture and turn it into a bad design. In the face of the Design Pattern concept, we need to face it with a clear attitude. When we understand or master a pattern, there will certainly be an impulse to try and not apply this kind of hot-headed behavior to the design, if you are impulsive, you can use a practical example. In theory, there is a gap between understanding and understanding, putting this kind of shallow understanding directly into the design, once improperly used, it will be unable to control the scale of the class, resulting in design errors. The above words do not mean that you do not need to use the design model, but need to use them with caution and flexibility. In order to master them, I cannot take a long time to learn about them. Here I will summarize some practical experience, for reference:

Clear motivation

Do not use mode. The pattern itself is a highly abstract object model proposed to solve a problem domain. Each pattern will have a clear description of its motivation to use it, this motivation matches our actual needs. This is a measure of applicability.

Build a local architecture

We recommend that you create a project independently before using the project. Test the mode in TDD mode. Although there are many "Examples" implemented in the online mode, many of them are confused and can be used only a few enterprise libraries are recommended, it is based on the pattern and has also been added to the MS practice. Although there are a lot of code reading, it will not be very difficult to learn using the methods I mentioned in the first article. Model testing is the most important thing for developers to do before using the published interfaces and classes of this project. The most effective document that uses the design mode architecture isSample CodeAs soon as the designer writes the sample code, it can immediately verify the accuracy and correctness of the design. writing sample code in the test case is also the most efficient way, because we can deliver actual design results to both roles (development and testing) at the same time.

Understanding the effect of a combination

The standard 23 models are not just independent. The interuse between models often produces 1 + 1> 2 results. But at the same time, you must remember that increasing the use effect will also increase the complexity of the system.

The design pattern is the partner of the architect. She was born to solve the problem and simplify the problem. Looking at 23 patterns, they are all centered around different scenarios.Coupling Degree,Encapsulation,Ease of useTherefore, the simple criteria for testing the effectiveness of the application model are as follows:

• Has the coupling degree been reduced?
• Has the Implementation Details been hidden (encapsulated) by the interface )?
• Is external interface implementation simple?

The design model embodies the ideas and experience of the predecessors of the design masters. It is not an intuitive design manual. We need patterns because we have not yet summarized our best design practices and accumulated long-term experience. With a design pattern, we can design and create patterns on the shoulders of masters. It is the architect's own design field and space to learn, understand, learn, and use the design pattern repeatedly until we forget the pattern. Test-driven (TDD)

Everyone knows the importance of testing, but it is rare to apply it to practice and implement the entire development process. It may be that the selectivity of "test" and the idea of "quickly and dirty" keep the test from being absolutely important. To be honest, I have completely experienced the convenience and importance of TDD in the last two or three years. When it is a project with a large design scale, it is impossible for the architect to take into account all-round details, and it is implemented by code. The appearance of the Moq tool Library also helps me simulate the effect after the class is implemented, the potential implicit or explicit problems in the model can be directly tested. In the process of team-developed cooperation, the test function runs throughout the whole world. For a good test process of the project manager, you can understand the completion status of each checkpoint without communication, architects can simulate the implementation of test models and write usage paradigms, and developers can have a minimal entry to code execution. As mentioned above, an advanced test of its design capabilities can work side by side with architects who can discover potential hidden problems in the architecture from the representation. Can it be said that an architect should also have the corresponding capability of advanced testing? Obviously, the answer is yes. At least, architects need to have knowledge about test-driven systems. At least they need to know how to write unit tests, perform sequential tests, and use Moq to simulate interface implementation.

 

Summary

I didn't give some specific methods in this article as I did in the previous article, because this article is more about the summary of my only experience, more comes from thinking. I tried my best to express this kind of consciousness and thinking with limited text capabilities, but I still felt that there was a lot of content that could not be said, or you can try to test my theory above through practice. In the next article, I will discuss in depth the high-level content I think in the design: "change ", I have always wanted to cite some more instances, but I don't want to write them as boring as the "dry goods" that can be seen everywhere. Finally, let's look forward to it.