I have been involved in the development of web applications for a long time. These are not high-loaded applications (like Facebook or Gmail) - there, of course, has its own specifics. My applications were small (it was possible to fit on one physical server), but functionally rich - financial, e-commerce. I did not work in large teams, but I felt the whole range of technologies, ranging from assembling equipment in a rack to editing CSS.

At some point, I found myself thinking that my activity in the development of web applications had somehow begun to remind me of the hunt of my distant ancestors for a mammoth (if by a mammoth we mean a task that needs to be solved). Only ancestors relied on their physical strength, and we instead use the power of our intellect. But as before, large prey cannot be piled up alone - the joint efforts of all the hunters are needed.

Under the cat, I tried to collect my vision regarding the most important aspects from my point of view in the development of web applications.

Adaptability

The most important aspect, IMHO. Modern web applications must evolve throughout their lives, all the while adjusting to the ever-changing environment. And not only the world external to the web application changes all the time, but sometimes web applications themselves change the world around them. In a web development, the waterfall model gave way to a spiral model, not because the waterfall model is bad - it just did not keep up with the changes. “Waterfall” is still good for developing applications in some other, not so dynamic environments - for example, software for Martian probes . In web development, it is much more important to make an application that is easy to change than an application that works according to customer requirements. Why is that?

Uncertainty

Here is the answer to the previous question. The customer himself often cannot correctly formulate his requirements for the application. It happens that the development is carried out in the absence of a clear understanding of what the final result should be - there is a general vision of the direction of movement, and sometimes decisions are not made "based on previous experience", but for producing it. After that, the ideas of the customer about the beautiful can change dramatically, and your achievements can drastically lose relevance.

Practice makes perfect

The correctness of the requirements for the application can be confirmed only after some running-in of the implementation of these requirements in the next version of the application. The less time from the formulation of the requirement to the use of its implementation, the earlier it is possible to assess the success of the decision.

In other words, the strategy of “tyap-lyap - and in production ” can be quite justified if, as a result of its use, a certain set of useful functionality grows, and the set of useless, and even frankly harmful functionality, on the contrary - disappears. Of course, the “hip strategy” works only for the spiral model of development and only for highly adaptive applications. Therefore, the web application should fall into alpha beta gamma ... operation as early as possible, and the change cycle should be as short as possible.

There on unknown paths ...

What are popular products good for? At a minimum, the fact that the main functionality contains no errors in them, and if suddenly any regressions get out, then this becomes quickly known, and they are immediately corrected. Here it only applies to the main functionality and only to popular products. Millions of users are walking along the same “functional paths”, trampling them down to the state of asphalt. But it is necessary to turn off such trails a little to one side and you can get bogged down in the quagmire even in the most popular product.

How to trample the tracks in the product, in which there are no millions of users? Himself to become such users. This is only a good dragdiler should not use what he sells. Good developers are simply “ obliged to use ” their product. And not only the developers themselves - members of their families, friends, acquaintances, friends of friends and friends of acquaintances. In general, everyone who can reach and who has the Internet, everyone should take part in the use of the created web application from the earliest stage possible.

If developers do not have extensive social connections, then they have to rely on Selenium and similar products . Automatic testing scenarios may well replace a small crowd of users, but at the same time they sufficiently reduce the adaptability of the application itself - it is necessary to change not only the application functionality, but also the test scripts for this functionality.

Error processing

Once upon a time, one of the hallmarks of good software was the presence of “ anti-fool ”. It was believed that any sequence of keystrokes on the keyboard or the simultaneous pressing of any combination of them should not lead to the emergency termination of the program. By virtue of what the developer had to think not only about how to process the expected data, but also about what the processing of unexpected data will lead to.

Now web-applications have become so multi-layered that you can no longer take care of this aspect. I do not mean that it is possible to score on SQL injection or on CSRF attacks , I just mean that if, when saving a new user in the database, for some reason the information about the client’s mandatory email was not received, there is no need to form a user-friendly error message - just the exception that the runtime environment (such as “ Integrity constraint violation ”) throws at.

If the application works in the expected environment with the expected data, then there are no such errors. Errors occur when unexpected data is used or an unexpected environment is created. In such a situation, it is much more important to respond to unexpected data or an unexpected environment as early as possible, and either add input validation (validation is business logic, not error handling), or enter processing of an unexpected state, putting it at the expected level.

Information transmitted by the program to the people in the error message should primarily be intended for human developers, and not for human users.

The maximum human-user task is to create an issue about “ some kind of garbage that occurred when saving data ” with a screenshot attached and an error message. And even better not to trust him - the web application itself can report on an unexpected situation and create issues for human developers. The human user will even be grateful if he sees a message like “ some kind of garbage happened, the developers were told, they are already working, they’re correcting - they hit on the email, we apologize for the inconvenience ”.

It is much more important for him to receive a message about the correction of an error interfering with him after a reasonable time (minutes, hours, days) than a detailed description of what exactly happened in the application, and a friendly explanation of why his request could not be processed at that particular moment. Of course, issues should not stand in a queue for weeks or months - if for some reason the developers did not manage to approach the problem for, say, six months, then we can safely throw out such a problem - or it is irrelevant or repeated (already repeated) by creating a new issue on the same topic (and not one).

Developer Orientation

As I have already noted, web applications must be adaptive. Who did not have time to change - flew out of the cage. Therefore, web applications should not be oriented to the end user, not to the business owner, web applications should be primarily oriented to the developer (who is not sure about this - just press Ctrl + Shift + I).

The application adapts to the end user, not at the request of the business owner, but because the developer has changed it. The sooner the developer understands where what is and what he needs to change, the sooner the end user gets what he or she wants to have in the business owner’s opinion. Therefore, the priority in web development should be clear code, not minified code, beautiful code or fast-working code.

Understanding the code should be not only at the time of writing, reading, but also during debugging, and during testing. This is not only for the minification / obfuscation / transfusion I am talking about now, but also for the multitude of return points in the method, and for the fluid interface , and for the lack of IDs for significant DOM elements. All these things are very enlivening the already entertaining process of debugging and testing code.

I share the notions of “programmer” and “developer” - a good programmer should not be involved in setting up the environment for an application, a good programmer should not read the application logs and understand " why they say exactly what is written in them and where it could come from, if this should not come from anywhere ", and a good programmer is not obliged to dig a debugger in the wilds of code written by him. This is all the work of the developer. The web application should be oriented to it. Moreover, it should be focused on

Real developer

The code is usually written by a genius - a creative person who is fully aware of the scale of the problem being solved and who draws the smallest nuances of his mind with the X-ray vision of his mind. And it changes - by a person who not only doesn’t grasp the nuances, but does not even always understand why this code was originally written. And in fact, often, it is one and the same person. Anyone who has tried to change his code in a project that he has not touched for more than six months, understands what I mean.

A Web application should allow you to modify yourself, not only to developers who have fallen out of context, but also to those who do not see the general context of the task at all. Therefore, everything should help the mediocre developer - describing business functions in code comments, “saying” names for variables / functions / classes, structuring project files and structuring code in a separate file, using IDE capabilities (inline documentation, autocomplete, hierarchy browsing) , cross-references to context-related files (including for @deprecated annotations).

It is for such small “straws” that the developer “drowning” in the modified code grabs when it is necessary to restore the context for which the code was created in a short time, compare it with the new context and understand what changes need to be made in order for the modified code to start working in A new context and did not destroy those areas of the old context that did not overlap with the considered area of ​​the new.

And, of course, tests - if a genius took care of writing tests to check his functionality, then even the most mediocre developer can run them and make sure that his edits did not affect the work of a genius.

Modularity

Splitting an application into modules is a principle as old as the world. Decomposition allows you to limit the context of the use of a separate module (group of modules), making life easier for the mediocre developer, and allowing geniuses to build more complex software systems. Each web application that claims to be a complex application in one way or another consists of modules. A module is a separate function or closure (JS scope), and a separate class, and a separate file, and a group of files with a specific structure, and the same group of files rolled up into an archive, and a group of archives.

Any modern application (not just the web) depends on many different external dependencies for working with which many tools are invented - rpm , dpkg , ant , maven , PEAR , composer , npm , requirejs , browserify . Perhaps sometime there will be repositories for web modules, components for building web applications ( plug-ins / extensions , and not what java or requirejs means ). In the meantime, the creation of the next web application often begins with the design of its own data structure for user authentication.

However, whether we use third-party modules in our web application or write our own, but our application is entirely composed of modules. And the better the structure of the modules is thought out, the more complex applications can be built on their basis. Often, to create very complex compositions, very simple, even primitive, rules are needed - understandable not only to mediocre developers, but to everyone who in one way or another can take part in the creation of this composition. For example, a binary system.

Anthill

It is the rules that allow ants to coexist as a single community and build structures that exceed their height by hundreds and thousands of times. It is the rules that allow people to create software packages thousands of times more complicated than those that could be built by the forces of one person.

These rules can be issued in the form of standards ( ISO , RFC ) or formalized less formally , or even quite informally . Nevertheless, it is these rules that allow developers to interact with each other, build their projects on the basis of other projects ( libraries , frameworks ), and associate some projects with other projects. A general understanding of the rules makes it possible for some (administrators) to support applications created by others (developers). Even the use of applications requires a general understanding of the basic rules (who tried to open a file with Ctrl + O in the IBM Visual Age , eh?).

A modern web application is a composition of the efforts of many “ants”, most of which do not catch the eye (starting with the binary system and right up to the browser). We, users, notice only the final efforts of specific developers, implementers of our desires . We, the users, often want “something like that,” without thinking at all about the entire technology stack on which the application is based, about what of the above is done in two clicks, and what happens with shaking up data structures. We want what others do not have, even if not right now, but as soon as possible.

And as users, we are absolutely right in our unwillingness to dive into implementation details, but as developers we need to understand not only the whole stack of technologies used, but also ensure that it adapts to the constant changes in the desires of end users (or the customer’s web application’s desires) . That is, developers at the top of the “anthill” hierarchy (near the end user) should not only use the fruits of their colleagues' work at lower levels, but should also be able to convey user feedback (feedback) and make adjustments to lower levels .

Specialization, unification, socialization - these are the whales who, I hope, someday will create an authentication module for web applications, similar to the grep utility in nix-operating systems, and creating web applications will become more like the layout of linux distributions.

backward compatibility

And this chapter has been added specifically for future developers of Magento 3, if those suddenly appear. The requirement of backward compatibility often must satisfy all decisions taken on a project. If this is not the Holy Grail, then even the “royal” demand is quite enough. But ... backward compatibility is the enemy of adaptability. Therefore, in short .

Summary

Modern web application:

• changes as much as it exists;
• is the sum of the efforts of many people, even if the end developer is one person;
• assembled from a variety of modules, a large part of which is used in other web applications;
• interacts with other web-applications according to certain rules;
• should be very friendly not only to the end user, but also to its developers;
• does not have to be compatible with its previous versions (dependency managers to help, as they say);

Thanks to those who read it. The current opinion of the author may not coincide with the above.

PS Why "With a magnifying glass on an elephant"? When you immerse yourself in the jungle of code, you look at the “freakish bends of the next“ elephant ”realization“ under a magnifying glass ”, so you won’t immediately understand where you are - at the base of the trunk or at the base of the tail.