Structure rules. Learning how to structure programmes, exploring possibilities, errors, solutions, etc. - page 4

New comment
 
C-4:

And what happens to your clear structure if in the middle, or even closer to the end of the project, the customer suddenly changes:

  • 5% of the original requirements;
  • 10% of the original requirements;
  • 25% of the original requirements.

This is a good test of how ready and resilient your project is to change.

This is the problem, which is why I am in this thread.

I want to find an answer on how to design (or how to cram the customer into such a framework), so that both his wants are satisfied and the project is not broken.

SZY because the coin has two sides, with one you can change the project, with another you can say "No as part of this project can not do," the truth is somewhere in the middle.

The best thing is to design the development in such a way that most of the customer's essential wants are realizable.

 
C-4:
No normal programmer draws flowcharts these days. All this is theoretical nonsense designed to be taught to schoolchildren, but not for work in real projects.

It all depends on what to put on paper.

I am not in favour of writing, but sometimes you have to draw up a general structure on paper. It is convenient and quick, it's like a sketch for a jeweller, the overall picture should be clear.

Perhaps that is why there are a lot of non-normal programmers because they do not draw flowcharts.

 
C-4:
Nowadays, no normal programmer draws flowcharts. All this is theoretical nonsense designed to teach schoolchildren, but not to work in real projects.
Well, I would not call it "theoretical nonsense" so sharply. In this or that form drawing "squares with arrows" on paper is widely used in programming. Take at least the same UML - full of "arrows with squares". :) So, also block diagrams at the initial stages can be useful...
 
C-4:
Nowadays, no normal programmer draws a flowchart.
There is no block diagram. You still have to draw the architecture.
 
sanyooooook:

I guess that's why there are a lot of abnormal programmers, because they don't draw flowcharts.

;)
 
MetaDriver:
I would not so sharply call it "theoretical nonsense". Drawing "squares with arrows" on paper is widely used in programming. Take UML for example - full of "arrows with squares". :) So, also block diagrams at the initial stages can be useful...

I've tried designing with UML, it's nonsense (IMHO).

All these squares and arrows I can perfectly keep in my head, but abstractions do not fit in my head, so I sketch them out.

HI If you dig deeper, the human brain is well suited to memorizing pictures, maps, behavior patterns, but not to building abstractions, abstraction is the hardest thing a person can do.

So mankind has always tried to formalize abstraction into something more familiar.

 
Urain:

The human brain is well suited to remembering pictures, maps, behaviour patterns, but not to build abstractions; abstractions are the most difficult task for a human being.

ZZZI That's why mankind always strives to formalize abstraction into something more familiar.

I agree.

I have my own methods of rewiring my own brain in this area, I even have software development (I can share on occasion), but the development is very slow (though noticeable in hindsight).

--

In a sense, all and any programming is abstraction work, but there is a huge variation in the level and skill of the practical handling of abstract concepts.

 
MetaDriver:

I agree.

I have my own methods for sharpening my own brain in this area, I even have software developments (I can share them on occasion), but development has been very slow (although noticeable in hindsight).

--

In a sense, all and any programming is work with abstractions, but there is a great difference in the level and skill of practical use of abstractions.

We're not interested in abstraction for abstraction's sake, are we?

I think since we are not evolutionarily best adapted to abstraction ?! (debatable, at least better than the other inhabitants of this planet), we should try to build crutches.

For example, people invented such a technique as brainstorming.

I often have trouble naming an entity, giving it a succinct name that is both comprehensible enough and extremely short. When that succeeds, the abstraction is easily assimilated.

Sorry, I can't write much now (it's not convenient to do it from a mobile phone), I won't have time to do it when I get there. I can't write much now (it's not convenient on the phone). I won't have the time.

 
I read the ToR, and if a solution in the form of a structure does not come to mind - I do my work on other projects, usually I never start implementation on the first day. If the program is not an ICL or XML, then I read, calculate implementation variations, structure types, classes. When I have a common picture in my head, I start to cut blocks or write basic modules. If something does not work, I crash on the couch with some tetris-like toy and play until I completely solve the problem, or until I get bored :)
 
Urain:

Sorry I can't write much now (it's not convenient from my mobile), I won't have time when I get there. Better tomorrow.

No problem. I too have a bad time today. Very much hope that the branch will become a permanent fixture (such as "bugs, bugs, questions"). If only the format of the discussion gradually settled in a constructive vein.
1234567891011...20
New comment