January 1, 2014 at 16:02On the merits of spaghetti methodology
During the lecture, we learned that there is a design methodology that works in most simple and medium-complex projects, and only for large and growing ones it is recommended to change it, starting to rewrite the functions again at some stage.
The leadership was inspired by the results of the presentation, since the advantages of the approach at the stage of introducing new functions into the project were clearly shown:
1) the minimum entry threshold for new developers;
2) excellent integration with Scrum and Agile methodologies;
3) project sustainability in relation to external refactoring;
4) simple integration of new programming languages and modern technologies into the project;
5) reduced cost of developing a project element;
6) the highest speed of creating presentations, patches and additions to a working project.
So far, our team has tried to adhere to more traditional structured, OOP and MVC approaches. But under the influence of the market, one has to try out new methods. After all, we didn’t have much time to develop and refactor architecture before, and what we managed to do was repeatedly criticized by managers for the complexity and increase of the entry threshold for beginners, and also for the fact that our frameworks were easily broken by the managers themselves when they decided to deploy the project, but they forgot about the rules of the methodology, which we did not describe, because (see above) no time was allocated for it.
Then, during that presentation, it became possible to eliminate a number of annoying shortcomings. Of course, you will have to fire several key developers who will not agree with the new approach, but after all it will become possible to write simple code, without classes and lambda functions, which is understandable to the bulk of developers with experience of 1 year or more who have recently come to the company.
And in fact, in fact, our managers have a number of starting projects. Why waste energy on architectural elements that are unnecessary at this stage, and even more so, classes or modules? The approach proposed by the speaker showed that, if necessary, any architecture can easily be implemented in the future in a spaghetti project. If a developer-architect cannot do this, he simply does not match his rank. Spaghetti remains flexible, and much more thanAgile , which the speaker demonstrated by introducing the alert () command into his new project in 2 minutes; and shutdown. It is no longer necessary to spend a week on iteration to change the project - in some cases a couple of hours is enough.
Let's take a closer look at the basics of spaghetti methodology
The idea of spaghetti lies at the origins of machine code and the fundamental principle of transferring control to the thread of program execution. We know that there are other approaches, unlike the Von Neumann architecture, but not one dominates the computer market, let alone software systems.
What new have given half a century of departure from spaghetti?
I must admit that many experiments tried to get rid of it. For example, a structured approach to programming is highlighted by the fact that program management most often needs to not only be transferred, but also taken back. They got rid of GoTo as a destructive operator, but why in recent years have we heard again that jQuery also creates spaghetti code? In a language in which all operations are structured? It turned out that spaghetti can be written structurally.
Why does a novice programmer almost always try out the spaghetti approach, only a layering of methodologies biases his views? Why are there crutch programmers who can easily digest such code written by themselves, can fix any system without source, find the source of almost any bug?
An interesting option, mixed with structured programming: a new function, class or block can be written anywhere in the project using nested calls and data structures, but the project, despite the structural calls, will have a spaghetti format. The nature of spaghetti lies deep in the nature of things and human activities. Therefore, the approach and its features must be given due attention, especially at the stages of formation and development of the project.
It’s not necessary to make it difficult, which is initially done simply - any advanced startuper, the same crutch programmer and businessman who knows how to count money and sees the real state of things when implementing projects knows this. You should not immediately attract specialists to create complex systems, if your system is simple. This is confirmed by the numerous facts of how spaghetti systems work, and migrations from them to more complex ones, when they are needed in the future.
There are special techniques for linking the code so that the project from a structural one turns into an unconditional spaghetti project in order to complicate the unraveling of structural loops. After all, if we leave structural challenges unbound, followers during refactoring can easily distort the design of the architecture and unravel the tangle of spaghetti. This is unacceptable on some projects, so binding techniques have been created and developed:
- add mixin functions (even better - methods) called from the block in which this code section was placed. It makes sense if the rest of the calls come mainly from other blocks;
- rename similar functions, methods, and make enough differences in the arguments and content so that the reverse recovery task would seem inappropriate. Novice developers often use the more primitive copy-paste technology instead of this approach, which is easier to refactor, depriving the project authors of a strategic advantage;
- use analogues of existing methods in the project, which is more time-consuming, but guarantees better project coherence.
Spaghetti methodology is not an invention in programming, as it is customary to think.
This approach has long been successfully used in aviation:
(integration with the modular approach is visible),
in urban planning and logistics:
in agriculture:
In system administration:
That is, in fairly responsible and important areas of activity. Therefore, criticism of complex spaghetti-software systems that combine both resistance to changes and susceptibility to personnel of various qualifications is not always justified.
Spaghetti methodology in programming adopted the best of what exists in nature, human activity and complex systems in order to quickly and fully participate in solving national economic problems. State computer centers often create suitable conditions for its implementation, because they combine a number of contributing factors:
- High level of hierarchical organization for decision making.
- Flexibility in setting and modifying goals.
- Extreme financing conditions.
- Adequate staffing level due to low staff turnover.
- Long-term planning in conjunction with clause 2
Private business does not lag behind the state. Recall that the first computers and systems were built precisely on this approach, and only the development of technology and computer science found new forms of employment for programmers and managers. Now it is proposed to return to the origins and draw on all the best that humanity has gained since the 50s of the 20th century.
Methods of working with spaghetti code The
speaker showed some methods for solving complex problems that arise as a result of the flexibility of the methodology.
For example, a graphical representation of relationships gives good results, where it is easier to trace control threads to a specialist and is often more effective for presentations than XML and JSON files, even if they are also represented by structures.
With a large number of ties, thread color markers help. See how simple and understandable the idea underlying them is:
And how much easier it becomes to understand the initially complex scheme:
It allows you to see the relationship in even loosely coupled phenomena, as an example.
If classification of nodes is required, it is similar:
Usually at this stage, the speaker said, managers and the bulk of developers already welcome the approach, and only a small part thinks about their experience and tries not to look at the diagrams.
It has been argued that such schemes are usually not used in software environments, but rather relate to data and presentations. But there is no doubt that if the methodology allows you to imagine everything, then the rest is up to the developer and his abilities to be able to use it.
Existing IDEsfor any programming language, like multilingual ones, they are focused on the use of spaghetti code. For the simple reason that otherwise they could not work with the most complex cases of coding, and also help the developer look for occurrences of names in the project, code sections, highlight keywords and redirect the viewing focus from use to definitions of functions, methods and classes. In fact, all the dozens of tricks in the IDE are working with just spaghetti code, and only a few of them are working with other methodologies (OOP, TDD, repositories, scrum, ....).
Therefore, it is easy for experienced developers to work with spaghetti code, precisely because they know a lot of working techniques, many tricks in various IDEs and have their own developments such as macros in editors or even in support and code building systems. Therefore, the question of the simplicity and complexity of representing the source code in a particular methodology is a completely non-obvious question. If your developers, the lecturer says, avoid working with unstructured code, this may indicate that they are not qualified enough to master the spaghetti methodology.
Next lecture slightly deviated from the main theme, the customer showed managers yet Mind maps :
,and then he carried them to a closed room, where they spent 2 hours drawing and were very happy with the results, one on one, like on tracing paper from last year when they left to try planning poker , and then introduced Scrum . It seems that this time too, the issue of introducing pasta methodology in our organization is a settled issue.
We list the pros and cons of the spaghetti approach in design.
- + writing any function anywhere in the project;
- - adaptation of the new code - with a review of all uses of it throughout the project (however, as in any project, but if the code is organized, it is easier to read).
- + low entry threshold to start writing spaghetti code;
- - a high threshold for understanding someone else's spaghetti code (but there are a lot of techniques in the IDE);
- + incredible flexibility and “pantheism” of the spaghetti approach;
- - the difficulty in building large systems based on this methodology.
Conclusions *)
If your organization has not yet gained a lot of inherited code or you are constantly starting new projects, you do not have extra money to follow the global trends of large companies, the ideologists of spaghetti programming will always be ready to help you optimize the process in order to write a function in 2 days , and in 10 minutes, debug the extension not in a week, but in a few hours. Agile programmers as flexible as spaghetti are looking for opportunities, traditional programmers are looking for the foundation. Flexible programmers write code, traditional ones rewrite it. Flexible - listen to the manager and immediately execute his words, traditional - look for reasons to engage in the platform.
* The opinion of the lecturer does not always coincide with the point of view of the editor .
