Illustrated synopsis of Kent Beck's lecture “Four Strategies for Responsive Design” (with comments)

"" - " ".

I offer my attention with illustrations on the essence of the “responsive” developed design. I was interested in the abstract of the lecture on “responsive design”, because our current development goes in exactly this way - the functionality is added little by little, in the process of refining and rethinking tasks, without revolution, with good disregard for academic ideality and completeness, which in the development process simply does not have right to be. In its own way, it is wonderful to ignore the rules of validity (they are for the future), cross-browser compatibility (the functionality is there, but is displayed in IE with a concession share) and conceptuality until the system's functionality is defined. It has only those pieces of "meat" that work, the spent pieces are gradually removed. This is exactly what Kent Beck describes in his lecture, which is why associations with his classification about four strategies are so alive and rich.

---

For reference, Kent Beck is the author of the book.
“Extreme Programming. Development through testing "
and others from the field of ES . Described lecture
wrapped in crazysage.diary.ru/p66324356.htm
and in crazysage.habrahabr.ru/blog/95906 , and read about a year ago .
( Beck's words (from the lecture notes) are further highlighted in quotations, and his notes in quotations are highlighted in a different color .)

The original design of the project.

It is a far from ideal design, which, nevertheless, performs the function required by the customer and is in demand, for lack of more advanced at the moment.

( ), ( , ) ( , .. " ").

Oh, well, leave the words, look at the examples. Suppose they did on their knees, as best they could, a device that turned up to a paying customer. As, for example, it is the primitive device for transportation of weights on distances (in abbreviated form - "cart" ).


')
The design is so-so, but keep in mind that so far no one has seen anything like this, it's a stone age! Everyone understands that the final design will be different. It should just work right now, knowledge, technology and materials were enough, the device passed all critical tests - descending from the mountain, falling into the river, carrying a statue of a deity with shaman dances with a tambourine. (Recall that an important component of extreme programming is Test driven development.)

- ( , ) ( , ) .

Now you need to refine it on the go. There are several refinement strategies - from small changes in the work engine to the complete production of the 2nd instance, based on new principles of work. It all depends on the needs of the customer and the ability to pay for the development. But the extreme degenerate case, when the customer has so much money that he is able to pay for the second development and realize space technologies in it, will not be considered - this is a task from another century. Although, we guess that it should look something like this (well, in the development process we will clarify, the main thing is to give money first), and we can justify the TK to the customer, and hire a design department. But no one will pay so much when it’s not that NASA - there are no court astrologers.



Nevertheless, the degenerate case, when instead of one project, another one arises - this is a working strategy, one of the four, called " Support Stone " and it makes sense to support, accelerating the overall work through building for it some kind of "support".

:
* , ( );
* , , ( - ).
:
* , ( ).

( ): , ( , );
( ): ( , );
( ): ( - ? ).

Examples of supporting subprojects: nail forging, wheel invention .

Background

: ( ) ( ).


Everywhere the same operations are done. The chemistry of the organism is built on the synthesis of proteins, a computer is built on logical circuits. So do not be embarrassed when the same rope will have to be applied at different levels of responsibility. Remember about fractality.

— .

There are no comments here: if our strategy leads to the collapse of the project, then before starting from scratch, the customer will think and hire outsourcers from neighboring countries.

, -, , . — .

The undoubted advantage of such a model is that the customer sees what his money is going to piece by piece, even if not as efficiently as if a helicopter were being built, and it would be unclear until the end why the propeller was put, and not the wings, like birds. And so - today added another log. The server load, though increased, will have to fork out for hosting tomorrow.

, , .

In other words, it was easier to do architecture wisely — to disassemble and assemble the system, to understand it.

, . :

* , - ( , );
* , ( , , );
* , , ( , " " , " " ).

, :

* ( );
* ( );
* ( (, ) );
* ( ).

Strategies

Bounce

The bottom line is to combine the design stages into one if the path is obvious. The method is good in the construction of proven objects ( trap pits, caves ), but is risky in development.

:
* , ;
* , .
:
* .

( ): ;
( ): .

The risk is more in that requirements may change or in planning errors (see “We Know How to Do”). But then, in one iteration, something like this can happen.



Parallelism

Careful strategy. The difference between the following item: "Support Stone" - here and there - a parallel development, but here we duplicate the functionality and transfer it in parts, and then something like "Big Jump" is built, and the functionality is restarted.

:
* ;
* , .
:
* , .

( ): ;
( ): .

For example, inventing a new wheel design, we will not rush to introduce it, not being confident in the reliability of the replacement.



Now, when we make sure that the square wheels work no worse than triangular (this is far from a fact), carefully remove the triangular wheels, leave them as obsolete-functions in the project, then use the square ones.

Support stone

( Considered the example above - a helicopter. It should be added that the essence of the strategy is in the production of the “support stone” - a tool (library), formwork (framework), binding materials (interface) in a part of the project. The helicopter, as mentioned, is a degenerate case replacing a project with another one, when it is worth talking about a different project. )

Simplify

:
* , ( );
* ( , , );
:
* , ( , , - , , );
* ( , , , ).

( ): ( );
( ): ( );
( ): ( , ).

And sometimes it is cheaper to use the natural way of carrying weights than the newly invented.



Or a modern example: sometimes it is easier to transfer data between computers on a flash drive than to establish a WiFi or LAN connection. Or if we talk about the design of projects, then the simplification is understood as the competent construction of the architecture of the project, which is sometimes more convenient to alter, having disassembled some of the previous pile of solutions.

Additional note

[ , ] :

* , ;
* ( , - ) ;
( , , , . .. "" "". )

, , .

Take care of customers. If you make a cart for which you are not paid, tomorrow you will die of hunger, and there will be no one to develop the cart, it will crack, it will be dragged to the wood, and it will never turn into a spaceship.