sequence

Review the old and learn the new, learning is so, a year to see a few books, recall but can not remember a lot. Memory is short, even if the knowledge of high school then remember how clear, now is forgotten. Leave some words, notes are also the best traces of that years. What has been left after a year’s work? This article is to commemorate the first anniversary of my work in Cloud School.

Finally, I thank my wife, who has taken on a lot of trifles for me, so that I have this leisure to write these few pens in the holiday.

preface

Learning is painful, work is also, sometimes often not only pain, there are grievances, there are also anxious. The process was long, intense and intense. Looking back on this year, SOMETIMES I had discussions with my colleagues without sleeping or eating until late afternoon, sometimes I discussed playback process with colleagues, and sometimes I discussed data structure with colleagues. Sometimes I work all night with my colleagues. Of course, there are colleagues to tangle with the implementation of a detail. And of course products and other colleagues. Looking back, it must have been a full year, a happy year, a stressful year. There are always some naive and dry writing, writing the atmosphere of fighting side by side, the feeling of the heat. Thank you for going through all the ups and downs together this year. It’s not so dramatic but it’s real.

In this year, some people can not forget, some things can not forget, start from scratch to build the project, on the right track, fast forward, the building will be tilted, put out of order, load forward. Every stage, everything is so profound, because things are complicated, technology is complicated, and just because of this can have a different product experience.

Words are always a little pale. Now I hope to write down profound and interesting memories of this year, pay tribute to youth and summarize my work.

Technology sharing is boring, and learning is also boring. I will take the real development experience and project management practice in this year’s live broadcast project as an example, hoping that everyone including myself can learn something from it. Words of a family, difficult to elegant hall, with that original mind, to write my heart in the annual technical summary report.

directory

  • Chapter I Live Broadcasting Tools

    • What kind of livestreaming tool did we make
    • What core problem is solved
  • Chapter 2 Agile Development

    • What is Agile development
    • What is agile in my mind
  • Chapter 3 Architect

    • Introduction to architects

      expressive

      Collaborative force

    • Architect responsibilities

      The functional requirements

      Quality attributes

      Technical debt

    • The architect executes the process

      design

      The development of

      refactoring

  • Chapter 4 best practices for Agile development and architects

  • Thank you

Chapter I Live Broadcasting Tools

What kind of livestreaming tool did we make

In the enterprise live training scene, we use electron, the audio and video capability of web based on sound network, the signaling capability of cloud fusion, and the PPT analysis and display capability of micro demonstration. In addition, we add exercise, check-in, brush and OMO (online and offline) teaching mode to the business-based scene. In addition, we also apply lian-mac. Guest lectures and more in-depth teacher-student interaction scenarios, with these capabilities and scenarios to achieve the purpose of corporate training, as well as online training scenarios support.

What core problem is solved

I remember I asked my colleagues early on, what are the advantages of our live streaming tool compared with Dingding? The size, experience and technical level of Dingding are definitely higher than ours. Evergreen’s answer was that Dingding was not as good as us in concurrency, customer service, and scene cohesion.

After this year, I came up with some ideas of my own, which have been changing all the time. In fact, we are far behind in the originality and stability of technology, which is my most acute perception as a technical person. To put it bluntly, all of our core capabilities are implemented by third parties. We are a stickler for requirements from a technical point of view. Of course, after knowing the background of the team members, I was impressed at first. Indeed, the core team had built such a system from scratch before, which I thought was awesome. This was the first change.

The second change comes from the complexity of the business and the complexity of the technology entering a mature period. Many designs, schemes and implementations are problematic in the overall judgment. We obviously feel that we have been confused by the technical reconfiguration we are forced to do in the second half of the year, as well as the multiple interrupted reconfiguration and some deep-water problems. Demand pressure and technical bottlenecks are obvious breakout periods.

The third change comes from business and customers. I also did the ToB scene before. Is technology not so important when sales are strong? Should we put the overall focus on stability and functional diversity, which is the essence of value?

It is true that companies are moving from offline to online, regardless of whether the epidemic has accelerated this trend. The development of society is inevitably the embodiment of efficiency. Before a ride of the world concubine smile, no one knows is litchi, now when can eat litchi. Transportation efficiency, agricultural efficiency is the embodiment of social progress. The improvement of enterprise efficiency must be in the improvement of communication efficiency and execution efficiency. Enterprises that do not embrace change are bound to die out. Why evergrande, Huawei and Xiaomi are making cars? Although their behavior seems childish and low, at least they are embracing change. The inherent way, the inherent channels, the inherent products, are to be abandoned by this era. The only constant is change itself.

Chapter 2 Agile Development

What is Agile development

I was confused when I first joined the team. It was work anyway. Just do it, that was my first feeling. Setting up a sprint, breaking down stroy, ordering Ower, daily morning meeting, delivering test, iteration launch, iteration review, running through the process is what I thought of as agile development. With the expansion of the team and the complexity of the project business, we lost control of the quality project cycle, and we continued to need to work overtime to repay the business pressure. Our solutions add more processes, add more managers, and cut more requirements. It looks like this. Is this agile? What is all Agile?

Is overtime agile development? It isn’t. Is process clarity agile? It isn’t. Is cutting requirements agile? It isn’t.

Agile development is an idea that requires an agile process to accomplish the most important customer needs in the shortest possible time.

What is agile in my mind

When things flow to words and norms, it will become a metaphysics. Is it true that if we learn PMP, we will be able to manage projects? Of course learning is useful. Do we have to pay attention to the various start-up and delivery processes, the various time and cost management? The answer is no. Read thousands of books line thousands of miles, the paper come Zhongjue shallow, must know this to practice. Technical code requires practice, as does management.

Everyone likes to be passive and ask very few questions! The core of Agile is that time is limited and the user’s scenario comes first.

First of all, when the task is arranged, we want to put the directory on the left, put the directory on the right, do it, animation, popover do it! There is no problem from the perspective of work arrangement, but there is a big problem with behavioral cognition. What is the value of the UI changes? What do we focus on on a limited time and personnel basis? What do we make the button look like, what do we make the popover look like? Is it important? With such tight resources?

Second dynamic scheduling, schedule changes, postponements, we tend to think about processes, notifications, postponements, nobody asks why? Why the delay? Why today? No one asks why is the biggest question?

Third, technical liability management is out of control.

To sum up, there is no value judgment, no curiosity, no problem management.

What does agility look like in my mind? I agree that agile is an idea, a fast iterative approach that focuses on the core values, requires inherent processes to ensure our agile management, and requires agile ideas and corresponding workflows.

The first step is to formulate the first principle, whether it is the time node or the important demand. We must arrange the time according to the big demand. We must arrange so much work and so many resources on the line, and what to do and what not to do. Do the re-rating.

Step 2 Embrace change Release and platform requirements are clearly impacting the current iteration, so embrace that change instead of putting it off.

Third, trust the team, identify with the team, identify with agile, development and test products can be implemented with minimum consensus.

Fourth, manage technical liabilities.

Fifth, happy work, happy life, agile final state must be within 8 hours, the most efficient decision and the most efficient way of development.

Chapter 3 Architect

Introduction to architects

I’m sure few people read this carefully. Why? Writing is boring, learning is painful. How can work be done like that? If reading summaries of everyone’s work becomes a task that everyone has to do, it’s not going to be very productive.

I might have said, it’s nothing to do with me, I’ve written all my documents, and if people don’t read them, it must be someone else’s fault. It was wrong, it was my fault, I wasn’t interesting enough, or my words weren’t productive enough for others, which is obviously a case of failure.

If I were the architect of this reading project, what would I do? What are the core competencies of an architect? What does an architect look like?

The architect is responsible for functional requirements, quality attributes, and technical liabilities. The architect should think about the problem, understand the requirements, design the architecture, evaluate the results, write documentation, core code, and algorithm implementation. As far as I am concerned, the most critical skills of an architect are the ability to express and coordinate, while the rest are the specific tasks of an architect.

expressive

Expression power can be reflected in the expression of accuracy and expression of these two aspects.

Expression accuracy

For example, everyone is in the New Year’s Eve, New Year’s Eve around the customs are different, some places the New Year’s Eve dinner is at noon, some places the New Year’s Eve dinner is at night, but on the New Year’s Eve dinner this word has the expression accuracy problem, clearly is the New Year’s Eve dinner why the dinner at night is at noon, is not very strange. A lot of people say is this a big deal? It’s a big problem when it comes to teamwork.

Tools of expression: Words are always weak, as I use them in such a way that I get sleepy myself. The right expression tool is not only to promote interest and explain the situation, but also the most indispensable part of the design level. For example, in OMO, a PPT screen projection scheme I developed before, pale words were used in the selection of technology, which made it difficult for participants to see at a glance. And if I put it in the form of a table and compare it.

Express tool

For example,

Capture scheme

It is feasible to use the method of screenshots and the timer to capture the pictures inside the video container and transfer them to another window for rendering through IPC (ICP encapsulation is not included in this sharing).

The problem is that the number of transfers is too frequent, causing the client to freeze. The transmission data is very large, and the data volume is very large after the picture is transferred to Base64, so the data is not suitable for local communication. Poor scalability, the current is a video can be completed transmission, if the scene is multiple videos, there is no doubt that the performance is a great problem.

Remote streaming services

Whether you build your own streaming media service or use a third-party streaming media service, you can implement local video streaming or multiple video streaming uploads, and then subscribe to these video streams in another window. Performance is absolutely no problem and implementation is very simple.

The problem is: the experience is not good, there will be delay, obviously is a local video, if you have to upload, then download, due to the impact of bandwidth will appear delay. Economic costs: Both self-built servers and third-party services incur economic costs.

Webrtc video transfer

High performance, low latency, no cost, that’s what we really want.

There is nothing wrong with the above text, but how do the people involved in the technical review make choices based on it? The right presentation tool is one of the basic skills of an architect. What if I did it differently?

Common charting tools
The chart

Select which OMO screen casting scheme

Scheme/Features screenshots Third Party Services (Audio Network) webrtc
performance low In the high
delay low high low
cost There is no There are There is no

After looking at this table I believe that the product, test, back end and project manager are all clear. The architect is not only writing out the table (technical rehearsal and judgment), but also using the table as a form for all participants to understand.

Sequence diagram

Involve multiple calls to the scene, can be used in a sequence diagram shows that relations with the process, the following is a playback data flow design, can see the call was clear, the relationship is clear, but there is a obvious problem is that there is no use ICONS, explanatory is not strong, if the light to see the figure is part of a mentally force, had better add ICONS, So collaborative students can see the picture.

SequenceDiagram Client ->> Client: Asynchronous request queue control client ->> Server: Send operation data server -->> Client: Respond successfully server -->> MQ: Send data to MQ (asynchronous, decoupled-concurrent) MQ-->> Server: Subscribe message server -) Ali Cloud: operation data apend to write oss
The class diagram

Class diagram is a strong representation of object-oriented power, object methods, attributes, and inheritance between objects. Is one of the most common expressions for defining code scenarios that can be used in front-end object-oriented design.

The diagram

For example, in our current department system, there are roles such as product, test, front end, back end, APP, UI, project manager and platform personnel. What is the relationship between these roles? Why is there confusion sometimes?

Other chart

There are many others such as collaboration cards, concept diagrams, flowcharts, module diagrams, etc. Why not mention them? This is one of the directions of my study. This is also the question my colleague asked me the other day. I should sum it up well myself. For example, how should live micro lessons be represented by diagrams? Is anyone really thinking about it?

Does a proper chart matter?

Is it important to choose a diagram to better illustrate your point, your design, your philosophy? If everyone works in their own way, it will not be the most efficient. If there is not an efficient scene, the staff is meaningless, the department is meaningless, and the product is meaningless. If you do not advance, you will fall back. If you cannot learn new skills and abilities, you will eventually be eliminated. Ha ha joke exaggerated, but do anything or should keep improving, to their own requirements, there is growth.

Sometimes it makes sense to think about a problem and sort out a chart. Why do people often talk about products without thinking clearly? This is the real problem, the main process is to start live, end live, what about the sub-process? There are start check in, end check in, start push flow, end push flow, if there is a complete and detailed design, I believe that every time you see this picture, you will think of my sub-process in the face of the main process, the main process change will also have what impact on the sub-process. At the beginning of each iteration, relationships should be designed and combed. Why not? Because there’s no thinking, there’s no transmission, there’s no drive. Maybe the main image is in your mind, but it should be on the first page of the document.

Cognitive basis

Like the last stable version, right? Within the tool product’s internal cognition, it is the code of the last release, namely the Master branch. However, in the branch management of the APP team, the code was merged into the Mater branch waiting to be released after the completion of the test, rather than the code merged into the Master branch on the day of our release. There’s a problem with people doing privatized releases based on this mater. Because the package of this APP has brought in new features, but the code on the tool product side is still the old version, how does this match? This is a failure of the architect, why can the company’s basic understanding be inconsistent?

Generic term

Do not create new terms, in fact, in our business there are many sequential tasks to perform, such as orderly signaling, orderly chat order, render order. And when you use it with other devices like Android and IOS, if you use a uniform noun like queue, it’s a uniform noun. However, the term queue is a bit of a misnomer when speaking to non-developers.

Don’t diffuse concepts

It is painful when what you think you think is not what you think. For example, grayscale release, in my cognitive scope, is the separation of traffic, improve online experience, and do some product AB tests. But the addition of such terms as tunnel and beta alpha can be mentally taxing for newcomers or those who have just come into contact with them.

Validity of expression

In fact, there are many ways to express, such as meetings, documents, training and so on. The best way to do this in a system, I think, is two ways, one is to know everything, and the other is to not know the details.

Convey the degree of

Grayscale implementation is inevitable, many partners did not participate in the discussion of grayscale, some new nouns, some new scenes, we can not well understand, in fact, many theoretical concepts have not been implemented to the front line, this expression is actually invalid. Cluster scenario, such a high degree of coupling scheme I think is also a failure. Honestly, does the front end care? Need front-end care? What does it matter where traffic is allocated to the front end? That is, there was not enough discussion, no curiosity, no upward channel of opinion. How to express it, but it is incomprehensible!

Unified specification

Deploying the tag scheme is also strange, publishers need to care about the tag,tag version? The expression is not standard. The hotfix understanding of the front and back ends is inconsistent, and the rhythm of the APP end is inconsistent with the current team. Expression is not unified, their own politics.

How much is it going to cost a company to know all these details? In fact, the optimal model is one in which development does not need to pay attention to any operational details and the two parts should be decoupled (except for learning operational knowledge). Why is it now that everyone needs to pay attention to the environment, to the cluster, to the tag, to the project in Jekins?

Choose good expressions

There is a problem with the way of expression. Either the lowest way is to have a complete new training to understand this knowledge, or to participate in the discussion of all members, or to use tools to smooth.

In fact, the best way to express should be no expression, knowing smile is the highest realm, but in real life and work face to face can talk bad, better should be the company from top to bottom, from left to right all departments to express in place, unified, standardized.

Collaborative force

A good architecture is designed, followed by the above case, the grayscale scheme within the company. How to implement the solution and supervise the solution, an architect has well designed the flow chart, call logic, interface definition, how to drive the collaboration to complete exactly the same.

Never relax until the last minute. Discussion documents, design summary and detail, development period planning, acceptance standards, the whole link, all end should be clear, until the online success.

It’s hard to drive others, such as IM hardening I was involved in. First of all, the concept of the team propaganda and identification, we agree why reinforcement? Why order? To the program, and then to the specific implementation of verification. Even if one person is highly skilled and skilled, everything has to be done by the team. How can you ensure that every code practice is your design solution? Verification of results is really only one aspect of verification, all processes are permeated, and you have to work with everyone to achieve what you want.

Architect responsibilities

Define the problem, define the scene, solve the problem, adapt the scene, in the process of solving the new problem, new scene, and continue the cycle. This is a process of benign upward movement, not optimal at every time, but it is also a process from BB to mobile phone to keyboard smart phone to touch screen smart phone. Spiral is the trend of the overall development of a product, a country and a society. If it is not inevitable to face elimination and disintegration, new products, new social system.

The functional requirements

The saying that everyone is a product manager is also well known. One of the responsibilities of the product manager is to export requirements. Is it the product manager who outputs the requirements? Everyone has pain points and itch points, not because of a point to create a need.

Assessed value

How does a point become a requirement that needs to be evaluated? Consider customer value, time segment, and data support. A cool animation effect must be pleasant to the senses. As a tool product, it is not important for function in the early stage and stability in the middle stage. In summary, it has a little value, but completion is not important.

A need can come from sales, customer success, a need has value in itself, it can be a need point or an itch point. , but we should rely on data usage, usage scenario, the customer is god, I agree with this is part of the big scene B better guide the customer actually is also very important, unless as a last resort, there is no data to support, no value identity, but a customer income, but I think this is the last to trigger terms, rather than the rights of way is used.

A good architect should evaluate value. Does it matter if a UI is placed here or there? There is no point in this period of time when stability has not been achieved. As stability changes, product requirements will change. Why spend time on UI? If the product is stable and there are no online problems, then the standard UI will improve the interaction. I think that’s a good time. However, product live broadcasting needs to be guaranteed and problems need to be solved. Why indulge in details because of details? Revel in rebuttals because of rebuttals. This is the role of a good design review, but at the end of the day everyone must be on the same page. Everyone has different values, and it’s the team values that should be developed in the beginning, not the rash development.

The scene matters

As the iPhone uses the screen instead of the keyboard, the use of sliding unlock to prevent misoperation, resulting in screen opening for some wrong input and so on. This is a scheme for a very important scenario.

Accept imperfection

Although sliding to unlock solves many misoperations, there is still a probability of carelessness. I found my phone was in my pocket, and it was misoperated, or THE password was output for many times, so I could not use it normally. Perfection is everyone’s goal, but imperfection does exist for a long time. It seems to be a trend that electric cars replace oil cars, but the problems of fast charging and low temperature environment of electric cars are not perfect, and even not perfect enough to make us feel painful. But that didn’t stop the trams from going on sale. I believe that trolley products will not say, what if there is no charging pile, what if the charging is slow, what if the use of low temperature is not good? Not online, right? Isn’t that bullshit? You never know what the bigger problem is if you don’t go online, if you don’t go online because of a minor flaw? The era of development is also changing, we evaluate bugs, to the normal view of bugs, not to say that there are bugs can not be implemented, but the value of the requirement itself is cool. That’s what we care about. We care about bugs, we tolerate bugs, we make decisions together, it’s a good ecology. Of course, bugs are not left unaddressed, which is explained in the important sections below.

Quality attributes

Whether a project can be running and sustainable development actually comes from its quality attributes. An obvious example is that our problem feedback group has been giving feedback about problems, and it is obvious that our quality is not good. Quality attributes are subdivided into availability, performance, scalability, security, and so on.

High availability

High availability is definitely our most common term, and it’s not just the front end, the back end, the operations that we’re trying to achieve and push forward. Sometimes we can see that the group said that the live broadcast can not be used, the teacher does not cut PPT, the teacher can not hear the speech, the check-in students are not finished, the playback can not see. These are obviously some of the problems we have with code, services, third parties, middleware.

Code issues: for example, some students cannot receive the current end check-in. This is an unavailable scenario, and common signaling schemes guarantee it by using push and pull to ensure the arrival of messages. Regularly push the latest status to the broadcast room, students regularly pull the latest status in the broadcast room.

Concurrency issues: Often server-side and front-end polling schemes put a lot of strain on the server. The server standard fuse limit ensures the stability of the server, but on this basis there may be user instability, some user requests are not processed properly. The way we deal with concurrency, the way we deal with it now is to transfer the pressure to Ali Cloud, write the data to Ali cloud, so that the pressure of concurrency is not on our server itself. In fact, there are multi-threaded solutions in various languages to handle various high-concurrency scenarios. Data flow and communication are different. Nodejs uses message transmission, while Golang uses channle. Some languages use fewer resources concurrently and can greatly reduce server costs. There are also middleware approaches, such as this common MQ one of the biggest features is peak clipping. To sum up: there are several concurrent processing methods: polling can be used to add random number model, which may reduce the concurrency pressure in a certain probability; Transfer capacity to other service providers such as Ali Cloud itself such professional service providers; Change languages; Change implementation using middleware.

Third party problem: the biggest feeling of this year is the dependence on the third party. First of all, the third party has mature technology, perfect SDK and professional team, which has to be admitted. However, the third party has also caused us a lot of troubles, such as unstable cloud and signaling loss, so we need to strengthen its basic services. Uncertain sound network, transmission of audio and video problems, rendering problems are very headache; PPT analysis problems, incorrect analysis, incorrect use and so on. For these third party problems, the biggest solutions are either to restrict the use of complex fonts, such as warning instructions and powerpoint; An alarm is generated indicating that certain function is abnormal. Suggestions for problems that may occur in this scenario, such as closing other programs when the CPU is too high, reducing the sharing screen, and using regular fonts for PPT. The problem that cannot be solved cannot be solved, but sincere advice and guidance should be given. Even to load something as secret as spaceflight, not to solve a physiological problem with a diaper, not to spend a lot of time and energy involved in a very complicated project to build a toilet, at least in that scenario, manned spaceflight is a breakthrough, not to let a diaper block the way forward.

extensible

It is not possible to design and support a 100,000-person concurrent online system at the beginning of the project in anticipation of limited time scale, but it should be considered. Technology foresight and product foresight was one of the biggest mistakes and judgments we made this year. The problem of multi-channel live broadcasting really brings great difficulties. The previous schemes are all based on client-side centralization. Getting things done quickly created a lot of technical debt. The familiarity of many SDKS, upgrade plans, implementation plans, really step by step exploration, which if a startup team, can understand part of it, if it is an experience team I believe this is not a good performance. If later to look at the issue of Angle, web live or and app interaction early again under the premise of many uncertainties, I will choose pure live web and embedded h5, experience may be falling point customer perception and long-term project iteration planning optimization of the road, I believe that the effect of pure web is the best technical solution.

This is also the core idea of my expression of scalability. Scalability is based on rapid trial and error and upgrading, and doing it without thinking clearly brings about huge scalability risks. Now, due to the existence of desktop clients and apps, the upgrade mechanism now, the implementation of scalability is basically difficult, can not embrace the change when the change comes, this is one of our biggest problems. API want to upgrade, function want to upgrade, app suddenly released, very painful.

performance

In fact, sometimes there are relationships that are actually multiple relationships, mutually affecting. For example, I made a plan to replay data. On the premise of a small amount of data, tracking results according to the state is the fastest performance, which reduces the pressure of calculation and reduces the experience of lag. In the context of big data, such a solution would be disastrous. The resources are large, the requests slow, and the processing complex, I admit. However, if I use a good way in compression performance and compression scheme from the beginning, then although my data scheme is problematic, it may be difficult to trigger the risk of my data volume being too large under the protection of compression performance. Not every point is optimal, but the mutual improvement that each brings is actually a good result. This is what I need to pay attention to later in the development design, multiple points of improvement rather than focusing on one point.

security

Security is actually very important in the scenario, as my database was attacked before and then blackballed me to give 0.002 bitcoin, I also realized the importance of security. This is a scene from my personal project. In addition, data encryption is also a common requirement in enterprise scenarios. In addition to the requirements of customer data security, there is also the risk of crawling data interfaces of competitors. Encryption level, anti-crawl strategy, are mutual, see which side invested more, is a long-term struggle process. Whatever security implementation of specific solutions, I believe that no invasive solution is the best practice, no matter adopt what kind of encryption algorithm, for the project itself should not focus on these, can not influence the development, online upstart, cooperate with the custom tools for debugging and positioning problem, this is my personal opinions and comprehension. Database security is also to pay attention to the user password can not be too simple. Backup and recovery of database data itself. In a full project is to pay attention to, before too much attention, open source projects also need to pay attention to data security.

Technical debt

Technical liabilities are technical defects left over during rapid iteration. For example, there are a lot of brush data during the live broadcast, and it needs to be restored after the PPT is switched and the client restarts. The previous scheme was to store brush data locally, which was obviously problematic. If you switch devices or want to support multi-scene switching live, you will face the problem of data migration and recovery. In addition, the bugs that still cannot be solved by the deadline point in the iteration process, or some bugs that are difficult to reproduce, have certain risks for going online. Technical liabilities need to be managed and dealt with.

Package type

If it is design problem this is the most headache problem, the basis of a project plan determines the late maintainability, scalability, as I before the design is based on the client centric design principle, all of the data and signaling logic are maintained in the client itself, but the client crashes itself, as well as multiterminal commonality above has a great design flaws. Failure to pay attention to this is extremely problematic, and this type of problem should be dealt with immediately, otherwise the links will become more and more long, which is fatal to the project itself.

BUG type

Under the premise of agile development, I think it is normal to go online with bugs. If there are some bugs in the core values and project iteration speed, I also think it is OK. After all, being good and fast should be an unattainable state, and we will always be the process of convergence. Personally, I still agree that bugs should be classified, and the higher-priority ones should be incorporated into the next iteration requirements or hotfixes. Agile is always 8 hours of Agile, and there is no point in being agile if you don’t agree with that. We need to be aware of the scarcity of resources, and we need to make decisions every day and iterate according to our priorities, which is a virtuous cycle. I believe in that, and I believe in what I believe in, that’s what teams are, that’s what agile is, that all decisions should be based on trust, judgment, long-termism.

The third party

Third party bugs and ability issues are our biggest bottlenecks this year. Acceptance of imperfection is still our theme, and this is my universal value. However, this year, there have been several bug problems or ability problems under certain scenes of the third party, which resulted in our requirements not being online. In fact, I think there is value imbalance. If H5 has audio and video problems in some scenes, I personally think it is acceptable, or there are problems with other abilities like concurrent-recording. There’s a risk of problems going online, but I don’t think that’s a reason not to go online. All the judgments are based on no customer value, no data support, and no centralized discussion. I think they are still going in the wrong direction. Value comes from customer feedback and data support. In the absence of anything, judgment is meaningless, which is the wrong direction of many of our software. Both product decisions and leadership decisions are groundless. I always feel that we have subconscious not on the line there is no problem of fluke psychology. Why can’t the value to the customer be the first consideration?

The architect executes the process

design

For the development of anything, or to do it well, I think full discussion and detailed design are indispensable. The ratio of design time to development time is very important, and shortening design time does not necessarily reduce the entire iteration cycle, but sometimes elongates the entire project cycle.

Design is never about creating something that has never been created. Most design should be adapted and optimized based on existing technologies or solutions. Just as we should borrow vscode for client design, we should borrow well-known UI libraries for our own library design. All design should not start from nothing, but a process from something to excellence. The reason for the weak design in many businesses is my personal feeling that there are some deficiencies in data structure and algorithm. If these areas are strengthened, I believe that the business can do better design.

Design principles

There are six common design principles. I will briefly describe some common usage and application scenarios.

Single responsibility

A single responsibility is the name of the game. Each module, each function should be a single responsibility, a method only do one thing, so that the code is readable and maintainable is very high, the biggest fear is a method to do N things. If there are multiple branches within a method that execute different judgments, you can use policy patterns to further split. The front-end separation scenario can also be thought of as a single responsibility scenario.

The open closed principle

The open and close principle, for extensions, closed for fixes, is the most important principle to be aware of during the evolution of a project. Do not move the mountain unless you want to refactor the entire module, or you should open a new road around the mountain. This is the most important principle in poorly maintained projects.

Least knowledge principle

This has been one of my biggest pains this year, the need for companies to support dual clustering. What is the relationship between the front end of the company to support gray scale? What does it matter if the company wants to tag the front end? Everyone involved is fully aware of the cause and effect, this is a painful thing, there are huge problems in the design of this scheme. If I design the double cluster scheme, the front end must not be affected, why should I care about Tencent cluster, Ali cluster, the lowest approach can be in Ali or Tencent ng inside a layer of proxy or other ten thousand schemes, what is the relationship between the front end project? Company grayscale release to play tag, to have a tag specification, why? Why should front-end development care? As long as the front-end manager makes sure the code is tested and approved into the Master branch, where does it go? What does it matter how you publish the front end? If the previous 2.0 scheme is problematic and can only be done in this way, I think it is also unreasonable. This is the most basic technology construction of the company, why should it be done in such a poor way? There is nothing more dangerous than building a company on a poor foundation and then building on it.

Design patterns

The singleton pattern

This is actually easier to use in a project and an integral part of code robustness. Suppose I want to use a global data collection system in my project. In fact, from a robustness point of view, there should be one and only one data collection and no repeated instantiation. This is my usual attention, in fact, in the global declaration of functionality and capabilities should be paid attention to and use such a singleton pattern to ensure that there will not be repeated call instantiation.

Decorator mode

The decorator pattern is indeed a common one. It is the most common use in Angular, primarily for behavior extension. If you can simply define a scene, like a dog’s class, and a bark, you want it not just to bark, but to bite when it barks. Such a scenario might be a realistic representation of a decorator. But a more realistic scenario could be the generic capabilities of components where additional functionality can be used in the form of decorators. Or slice-oriented ideas, such as behavior logging, can also use decorators.

The Observer pattern versus subscription publishing

This is a scenario in which both are decoupled within the same system. When a dependency changes, it triggers behavior. If patterns are distinguished by structure, publish-subscribe has one more middleware subscriber than observer, so publish-subscribe is different from observer. If the intent to distinguish patterns, they are all achieved a one-to-many dependency between objects, when an object’s state is changed, all depends on the object will be notified, and automatically updates, so they are the same pattern, publish-subscribe pattern is on the basis of the observer pattern optimization. It is used in many places in the current project as a means of data communication in various modules.

Design review Committee

How to run a good review meeting? The following points need to be noted:

The meeting

First, make full preparations before the meeting. Don’t hold a meeting unprepared. This is the pain of many scenarios.

stakeholders

Second, a variety of identities are required. Every stakeholder needs to participate in the meeting. The identity of the host is very important in the meeting, and the pace needs to be controlled to ensure the conclusion and implementation of the meeting.

Actively mobilize

The third meeting can be refuted, there are supporters, there must be participation and discussion, when other personnel mind or state is not right, the host to arouse everyone’s interest in participation and positive degree.

Controls the rhythm

Fourth, limited discussion, in the program presentation must ensure that the presenter’s complete statement, the host must control, each stage of the program publicity, free discussion, follow-up supplement, implementation plan, and finally improve the efficiency of the meeting.

The development of

Development is the execution of design

Make sure that the development is consistent with the design, because if it’s not, it’s a big problem, and your preparation could fall apart.

Refactoring peers

The process of development is also a process of refactoring. The development process can be refactoring, and refactoring is part of development.

refactoring

The principle of

The principle of refactoring is to make code more maintainable and extensible without changing the appearance of the software. As we are now doing server-side centralized refactoring, in fact, the data structure and meaning should be changed very little, and the playback data and signaling should be the same as before. Refactoring and performance optimization are basically the same as improving the maintainability, understanding, and modifiability of your code without changing its appearance. One is to increase speed. Refactoring is not, in principle, sensible to users and other programmers. (We don’t do that well.)

Bitter memories

Regardless of where I was at my last company, there will be versions 1.0 and 2.0. The two versions are completely different, the front-end is different, the back-end library table is all different, the business has also changed, I still have doubts? Is it the right thing to do? No matter how bad the previous architecture was, didn’t the front and back end install modules to cut into microservices and then upgrade by module? Different customers in the business really no opinion? How to smooth out the difference between 1.0 and 2.0? I was surprised to make this decision, you know? How about Angular Refactoring a multi-year project from zero? Isn’t that a little strange?

Chapter 4 best practices for Agile development and architects

Agile development should focus on value, allowing for technical liabilities and online bugs. The architect should be a role leading the team forward, discussing value itself over development in the Agile process, and each partner should grow on their own based on trust, passion, discussion, and acceptance of others’ opinions. Every day should be a better self, better project value.

Thank you

First of all, I would like to thank my wife for her support and help me finish these boring text reading and verification in such a busy day as the Spring Festival. Furthermore, I would like to thank all my colleagues for their efforts and experience this year. I am just lucky to have time to write down such a summary and sentiment. Finally, I would like to thank two books, one on the practice of architects and one on refactoring. Finally, I wish you all a happy New Year and a happy Year of the Tiger.