Do not call the code the word "Product". About architecture
This article is for heads of development departments, former developers. I often hear two opposing opinions. They sound like this:
This is an eternal dispute between the "govnokod" and "development speed", managers and developers. Both sides are wrong. These are the two ends of one stick. On this stick, I would write in red letters the "mistakes of the head of the development." To whom this interesting topic - welcome under cat. And under the cut there are a lot of letters about software architecture, microservices and common sense.
In general, this article began with a discussion of Agile Manifesto on facebook ... The topic of discussion was about the following - “the finished product is more important than the people and their interaction”. In general, I understand the pain of the author and the pain of all those who participated in the comments. I also understand that the word "Product" is often referred to as something that is not a product. And this creates consequences and problems in real software solutions.
')
A product (in our case, a software product) is a brand and marketing, sales, after-sales support, advertising and pre-sales work, and of course our code. The process, called the word "business" - ensures the merging of these parts together, and this merging brings money.
The code (our software, software) is part of the product. Like other parts, it should easily interbreed with the other parts and adapt to them. The term "easy" - I mean the following set: "quickly", "not titanic work", "without sudden consequences."
Many people make mistakes and say that the quality of the code here is a crucial moment. Usually, it all comes down to the fact that “you can quickly write and run shit code,” and “good code has no sudden consequences.” Not. The decisive moment is the ability to change this software. After all, the process of crossing software with the rest of the business is its change.
When marketers ask to save utm-tags of a registered user, when you need to send emails of a certain typesetting, when you need to add the feature “and buy more with it” to your online store, this is the process of software integration with the rest of the business. This process should occur quickly, simply, without sudden bugs. And you do not need to reinvent the wheel - everything is already invented before us.
If you are not an adherent of SOA / microservices and write a monolith - make it modular. Why do you need it? Here is a set of key points:
How does this help to quickly and reliably make features? Well, firstly, writing a small module from scratch is really quick. Secondly - having the ability to build - in half a year or a year most of the time you don’t have to write at all - just build and add a little bit (a new small module). There is only one condition about the lack of titanic work - describe the module's architecture and their interaction (layout) in the documentation and strictly follow it, do not complicate it immediately and do not change later. Take the framework known to all. If you adhere to this and do not go beyond the scope of a well-thought-out arihektura, you will not need titanic work. You do not rebuild grep every time you do something in the console.
About bugs and predictability - the module is living within itself and having a simple unchanging interface is very easy to test. I'm not talking about writing unit tests right away. At first, this may be manual testing. You should resort to automation only when there is a need to start it every time - i.e. the module is actively changing inside.
This is the same modularity and the rules are the same, only more flexible. The difference is that the modules are now called services and interact not by calling public methods but over a data network. The rules are the same, but with the addition of a new one - it makes business life even easier. Here is the complete list:
Developing and developing an SOA architecture, choosing protocols and formats is more difficult than developing a modular monolith, but the big plus of SOA is that all bikes are invented before us - you just need to choose.
In fact, one thing only - a simple and flexible architecture helps to build a product and makes IT a reliable part of the business, rather than the “weak link of the company”.
Having the ability to quickly release changes with predictable behavior, without constant cost increases is a basic requirement for the development team. Of course there are other requirements, they are their own in every business, but they relate more to the details of the work, and not to the point.
The answer is as simple as the question - do not confuse the concept of architecture and “beautiful code”. Developers need a beautiful code so that it can be easily edited, it can be measured with colleagues. Simple and flexible architecture - to the customer so that his development requirements are met.
Architecture is like a set of matchboxes. In them you can put a match, you can grass. Can knee code can be beautiful. It does not commit to anything. If you make such a matchbox, that nothing but a match can be put into it, then of course this box is complete garbage.
How we “transfer data to templates from controllers” —in the form of arrays or collection objects — in most cases has nothing to do with the software architecture.
It is also not necessary to attribute to the architecture the choice of language in which you write - in any full-fledged programming language, you can create a good architecture, but you can create a bad one.
The work of thinking through the interaction and layout of the modules / services is mostly based on choice. To choose - you need to know the stack of technologies with which you work. Choose the most simple.
Knowing the technology stack doesn't mean “I know kung fu, karate, and other cool words.” You need to know the stack from the beginning, not from the end - many things were born 30 years ago and work perfectly, performing their functions so far. Of course you always want to take something new and try, learn - but “trying and learning” is for the Junior / Middle developer, not for the architect.
You need to know the technology stack in detail and from the inside. Always ask yourself the question - “why did I choose this?”. If you answered this question “I am more familiar with this”, then you do not have enough experience to make a sober decision, you need to study technologies.
If you answered “other than this solution, there are no alternatives” - there are two options:
What to do if you got a finished project with a fifteen year old legacy? It has no modularity, no services, and those that are - far from micro. Follow the monolith break strategy. From the big old monolith it is convenient to go to microservices. Bring atomic parts to the outside. Start by making technically difficult things - this immediately minimizes bugs and gives you time for positive development.
Microservice is like functional programming. Only not a function, but a service. It is simple, atomic. When there is only one function in microservice — for example, to provide OAuth — it should do just that, the database should be outside of it. Or service for resize images - only resize them. No need to store them in it.
The result is probably that holivar is a “beautiful code” / “quick solution” as a whole about anything. It is usually based on non-expandable architecture.
Architecture is not the most important thing in software. It does not need to be developed and developed - this is work for 3-5 days. Sit down, think, describe. And for another half a year or a year for a manager, teach everyone to stick with it.
Architecture is not a silver bullet. It does not make any features, but it can make bugs. Literate architecture - allows you to make features quickly on the knee next to the rest of the beautiful code and not spoil the overall picture. Compile, reuse. Illiterate - leads to sudden problems and long development. Her absence is usually also illiterate.
What is the article about? Essentially nothing. It is for those who continue to argue - "beautiful code" vs "quick solution".
- “The finished product is important to us - don't care about a bad code”
- “Supported product is important to us - let it be long”
This is an eternal dispute between the "govnokod" and "development speed", managers and developers. Both sides are wrong. These are the two ends of one stick. On this stick, I would write in red letters the "mistakes of the head of the development." To whom this interesting topic - welcome under cat. And under the cut there are a lot of letters about software architecture, microservices and common sense.
In general, this article began with a discussion of Agile Manifesto on facebook ... The topic of discussion was about the following - “the finished product is more important than the people and their interaction”. In general, I understand the pain of the author and the pain of all those who participated in the comments. I also understand that the word "Product" is often referred to as something that is not a product. And this creates consequences and problems in real software solutions.
')
A product (in our case, a software product) is a brand and marketing, sales, after-sales support, advertising and pre-sales work, and of course our code. The process, called the word "business" - ensures the merging of these parts together, and this merging brings money.
The code (our software, software) is part of the product. Like other parts, it should easily interbreed with the other parts and adapt to them. The term "easy" - I mean the following set: "quickly", "not titanic work", "without sudden consequences."
Many people make mistakes and say that the quality of the code here is a crucial moment. Usually, it all comes down to the fact that “you can quickly write and run shit code,” and “good code has no sudden consequences.” Not. The decisive moment is the ability to change this software. After all, the process of crossing software with the rest of the business is its change.
When marketers ask to save utm-tags of a registered user, when you need to send emails of a certain typesetting, when you need to add the feature “and buy more with it” to your online store, this is the process of software integration with the rest of the business. This process should occur quickly, simply, without sudden bugs. And you do not need to reinvent the wheel - everything is already invented before us.
Modularity
If you are not an adherent of SOA / microservices and write a monolith - make it modular. Why do you need it? Here is a set of key points:
- 1 feature - 1 module. You can easily and quickly write from scratch "from the dirt and branches" - what is required for business now. When the need arises to support it - you can easily change the module code for greater readability, while maintaining the interface.
- Layout A good module is not a thing in itself. It can be reused and linked. Remember bash and pipe ;-) “cat / etc / passwd | grep root | tr ':' '' | awk '{print $ 2}' ”is an example of modularity and layout. Unix-way is called.
- Easy to throw out / turn off. If marketing is wrong (and on average 70% of marketing actions are trials, mistakes, trials again), you can easily throw out an extra piece.
How does this help to quickly and reliably make features? Well, firstly, writing a small module from scratch is really quick. Secondly - having the ability to build - in half a year or a year most of the time you don’t have to write at all - just build and add a little bit (a new small module). There is only one condition about the lack of titanic work - describe the module's architecture and their interaction (layout) in the documentation and strictly follow it, do not complicate it immediately and do not change later. Take the framework known to all. If you adhere to this and do not go beyond the scope of a well-thought-out arihektura, you will not need titanic work. You do not rebuild grep every time you do something in the console.
About bugs and predictability - the module is living within itself and having a simple unchanging interface is very easy to test. I'm not talking about writing unit tests right away. At first, this may be manual testing. You should resort to automation only when there is a need to start it every time - i.e. the module is actively changing inside.
SOA / microservices
This is the same modularity and the rules are the same, only more flexible. The difference is that the modules are now called services and interact not by calling public methods but over a data network. The rules are the same, but with the addition of a new one - it makes business life even easier. Here is the complete list:
- 1 feature - 1 service.
- Layout
- Easy to throw out / turn off.
- Standard communication protocols. This is a huge plus of SOA - because under the standard protocol you can easily add third-party software to your solution. Figuratively - using Radius, OAuth2 - allows you to easily authorize your users in a third-party product. The use of standard data formats (json, xml) to integrate with various implementations of solutions, for example, with some kind of ready-made online store engine. So that it is not hard work - read above (1 service - 1 feature, layout, follow a single scheme)
Developing and developing an SOA architecture, choosing protocols and formats is more difficult than developing a modular monolith, but the big plus of SOA is that all bikes are invented before us - you just need to choose.
What does this have to do with the word "Product"?
In fact, one thing only - a simple and flexible architecture helps to build a product and makes IT a reliable part of the business, rather than the “weak link of the company”.
Having the ability to quickly release changes with predictable behavior, without constant cost increases is a basic requirement for the development team. Of course there are other requirements, they are their own in every business, but they relate more to the details of the work, and not to the point.
"Who needs architecture?"
The answer is as simple as the question - do not confuse the concept of architecture and “beautiful code”. Developers need a beautiful code so that it can be easily edited, it can be measured with colleagues. Simple and flexible architecture - to the customer so that his development requirements are met.
Architecture is like a set of matchboxes. In them you can put a match, you can grass. Can knee code can be beautiful. It does not commit to anything. If you make such a matchbox, that nothing but a match can be put into it, then of course this box is complete garbage.
How we “transfer data to templates from controllers” —in the form of arrays or collection objects — in most cases has nothing to do with the software architecture.
It is also not necessary to attribute to the architecture the choice of language in which you write - in any full-fledged programming language, you can create a good architecture, but you can create a bad one.
How to create a good architecture?
The work of thinking through the interaction and layout of the modules / services is mostly based on choice. To choose - you need to know the stack of technologies with which you work. Choose the most simple.
Knowing the technology stack doesn't mean “I know kung fu, karate, and other cool words.” You need to know the stack from the beginning, not from the end - many things were born 30 years ago and work perfectly, performing their functions so far. Of course you always want to take something new and try, learn - but “trying and learning” is for the Junior / Middle developer, not for the architect.
You need to know the technology stack in detail and from the inside. Always ask yourself the question - “why did I choose this?”. If you answered this question “I am more familiar with this”, then you do not have enough experience to make a sober decision, you need to study technologies.
If you answered “other than this solution, there are no alternatives” - there are two options:
- You do not know about the existence of alternatives - look for them! Well, for 40 years IT solutions have invented a huge mass for a variety of cases.
- You do something weird. If nobody has done this to you, there must have been reasons not to do that. Do not think that you have a unique project and so on - if you do not build Tokamak - then it is not unique in a general sense. Just something wrong with him.
What to do if you got a finished project with a fifteen year old legacy? It has no modularity, no services, and those that are - far from micro. Follow the monolith break strategy. From the big old monolith it is convenient to go to microservices. Bring atomic parts to the outside. Start by making technically difficult things - this immediately minimizes bugs and gives you time for positive development.
Microservice is like functional programming. Only not a function, but a service. It is simple, atomic. When there is only one function in microservice — for example, to provide OAuth — it should do just that, the database should be outside of it. Or service for resize images - only resize them. No need to store them in it.
Total
The result is probably that holivar is a “beautiful code” / “quick solution” as a whole about anything. It is usually based on non-expandable architecture.
Architecture is not the most important thing in software. It does not need to be developed and developed - this is work for 3-5 days. Sit down, think, describe. And for another half a year or a year for a manager, teach everyone to stick with it.
Architecture is not a silver bullet. It does not make any features, but it can make bugs. Literate architecture - allows you to make features quickly on the knee next to the rest of the beautiful code and not spoil the overall picture. Compile, reuse. Illiterate - leads to sudden problems and long development. Her absence is usually also illiterate.
What is the article about? Essentially nothing. It is for those who continue to argue - "beautiful code" vs "quick solution".
Source: https://habr.com/ru/post/299292/
All Articles