Answer the question
In order to leave comments, you need to log in
Are there books with examples that tell you how to design software correctly?
Tell me a book that will help me solve the problem of software development from scratch: from an idea to the final implementation.
I'm interested in books in which there is a step-by-step description of the development of some fictitious application, where the development itself is divided into stages and for each stage it is described how to act, why it is so and what actually results from this stage for the application.
For example, in large strokes:
Answer the question
In order to leave comments, you need to log in
there are no
5.6 books full
of 1 book no (okay, okay, TRIZ - haha) well, or let "Crossfit of the brain" be
2 - books on the MBA, rub until complete satisfaction. Repeat
3 - any in patterns + language
4 - any pendel from the authorities + crutches
in one it's all incompatible, if only because 5.6 and 1.2 are for different minds
and 3 and 4 are also
PS no offense, but for " with examples" - at best, your books are 6
There are many such books. However, there is one big "but". Many people want "everything at once" - learn to program quickly, learn to design ICs quickly, earn money quickly.
In fact, everything is more complicated. You can quickly master the programming language and its frameworks. You can relatively quickly deal with databases and everything around you. One can quickly understand how web applications are built and how to write them. And so on. Thus, you acquire certain skills, roughly speaking - this is the level of a Soviet vocational school, a technical school, according to a modern - probably - a college. And then such a young (and even with experience) specialist comes to work, he is given the task of "designing some kind of IS." And here is an ambush. It turns out that for this it is not enough to know the technologies that I wrote about above and the like. In order to correctly, accurately, and most importantly, effectively design an IS, one must have some erudition in the field of IT, which is very difficult to teach, and which is comprehended only with real work experience.
However, not everything is so sad. There are books that describe many different methods and approaches to design, which are designed to HELP on the path to mastering the profession of System Architect. It is to help, to show with examples, to explain, etc. But there is no and cannot be a "harmonious theory" of how to build an IS is the only correct way - there can be very different ISs - from an online store to a nuclear power plant operation control system, from a medical diagnostic system to accounting. And when designing each such system, different approaches are used.
Now about books that somehow try to systematize this knowledge, regardless of specific languages, technologies or subject areas. Often information on the topic in the form of separate - and often very voluminous parts - is considered in books on managing the process of developing IP.
There is "almost a classic", or better to say - specially-educational literature, for example,
- Gerkul V.I. and other Designing of information systems, Course of lectures.
- Gvozdeva T.V., Information systems design.
- Smirnov N.V. Information systems design \ Lecture notes
There are more applied, but still generalizing books, for example: -
Kuznetsov M.V. etc. The practice of developing Web-sites
- Macyashek L. Requirements analysis and system design. Development of information systems using UML
- Gorbachenko V.I. et al. Designing information systems with CA ERwin.
- Cheremnykh SV, Modeling and analysis of systems. IDEF - technologies.
- Isaev G.N. Design of information systems.
There are a lot of translation books that describe both specific practices and approaches, as well as general ideas (some of the books listed below were even the first to raise some topic that seems to be common knowledge today):
- Royce W. Software project management.
-Leffingwell D., Widrig D. Principles of working with software requirements.
- Vigers K. (Development of software requirements.
- Orama E. Wilson G. Ideal software development. Recipes of the best programmers.
- Braude E.J. Software development technology.
- Fatrepp R. et al. Software project management.
Etc. to infinity.
Well, the ISO / IEC 12207 standard has not been canceled.
If you at least look at at least part of this (endless) list, some IC design issues will become easier for you to solve. But make no mistake, the component of uncertainty and personal creativity in this matter will still remain very large.
Good luck in advancing to the heights of the profession :-)
"Perfect Code" by McConnell
"Clean Code" by Martin
"Object Oriented Design Techniques" by Erich Gamma, etc. - so-called. "Gang of Four"
"Scrum and XP: Notes from the Front"
No one bothers with architecture sketches and UML diagrams. Too often architecture changes and diagrams quickly become out of date. No one ever formulates a task for a developer at the level of class architecture. And when you yourself start to implement some functionality, your initial idea can change 5 times, because you forgot some point in the production.
UML is useful when one developer wants to explain his code to another. But in this case, it would be better if he re-read the above-mentioned books.
https://aosabook.org/en/index.html (Roskompozor, as always, is on top, we look through a proxy)
Code complete - it contains everything you need
Google books on the topic of Software Life Cycle or Systems development life cycle , also agile and waterfall.
there are design patterns, there are approaches and principles (component-oriented architecture, avoiding all-to-all dependencies, etc.).
There are various books that describe this.
but it is important to understand: there are no and cannot be instructions on how to design correctly. there are only tips, best practices and experience. because the right architecture is context-sensitive: it depends on and suits the situation in which you create it.
the same technique in different situations may or may not be correct.
therefore, it is necessary to study the principles, approaches, design patterns and understand their limits of applicability - when this or that pattern should be applied, and when it should be modified, and when it should not be applied at all.
all design patterns are not specifically designed, but "historically tested" are best practices - i.e. "these options for organizing systems" in most situations caused the least number of problems. those. people did it in different ways, but "this is what was noticed." (at the same time, there were combinations in which very "anti-patterns" worked well, and this is actually normal, but it's better for a beginner not to use this "black magic").
in general - there is nothing specially created and declared as "that's right." therefore, there can be no book "on how to properly design the circuits themselves."
the architecture should ensure the fulfillment of the tasks of the program / system, should not create unnecessary problems during modification and development.
write, create... to evaluate the quality of solutions, the criteria will first fit, that the most correct architecture is when the program works, does not contain glitches, does not break on incorrect data. well, the fact that your colleague, who is not aware of your task, can figure it out in order to modify it and modification and processing do not cause excessive labor costs.
and further - already on a situation.
Plus to the mentioned "Mythical man-month" by F. Brooks.
It is, as it were, for managers managing programmers.
But it is also useful for programmers.
For example, that the estimates of the complexity / terms of work for programmers are "too optimistic, at times"
The book is thin - you will read it quickly.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question