@Gudsaf
Школьник

Существуют книги с примерами, которые рассказывают, как правильно проектировать ПО?

Подскажите книжку, которая поможет мне правильно решить проблему разработки ПО с нуля: от идеи, до итоговой реализации.

Интересуют книги, в которых существует поэтапное описание разработки какого-нибудь выдуманного приложения, где сама разработка разбивается на этапы и для каждого этапа описано, как действовать, почему именно так и что собственно в результате данного этапа для приложения получается.

Например, крупными мазками:
  1. есть идея и примерное понимание задачи, уточнить задачу
  2. обдумать как решить задачу: проверить что, откуда, почему, все ли верно
  3. эскиз архитектуры ПО: прийти к какому-то эскизу архитектуры, подумать какие есть объекты (какие могут появиться новые объекты), какие для этих объектов нужны функции (что они согласно решению задачи могут делать, что они потом смогут сделать, как изменяться), возможно подправить эскиз архитектуры. Для данного эскиза разработать и посмотреть схемы БД, UML, какие еще? Схемы которые переводят метод решения задачи в сам код программы, описывают комплексно получаемый программный инструмент в виде схем.
  4. затем на 4 шаге подумать какие могут появиться новые объекты, новые функции, как они смогут потом изменяться. Подправить эскиз архитектуры и соответственно схемы, которые были сделаны на шаге 3
  5. написание кода,
  6. тестирование.


Хорошо, если в книге будут описаны принципы создания UML-диаграмм, применение и разработка каких-то иных диграмм и почему их надо применять, для чего они используются.

Такая книга в стиле «архитектор из домохозяйки», которая полностью на каком-то примере или примерах описывает все этапы разработки и используемые для этого инструменты.

Например, сейчас просматриваю «М. Фацулер. Архитектура корпоративных программных приложений», там есть схемы, но хотелось бы параллельно, читая книгу, еще и учиться проектировать сами схемы.
  • Вопрос задан
  • 2916 просмотров
Пригласить эксперта
Ответы на вопрос 10
dimonchik2013
@dimonchik2013
купил глушилку мабил: теперь в маршрутке тишина
не существует

по 5,6 книг полно
по 1 книг нет ( ну ладно, ладно,ТРИЗ - хаха) ну или пусть "Кроссфит мозга" будет
по 2 - книги по МБА, втирать до полного удовлетворения. Повторить
3 - любая по паттернам + язык
4 - любой пендель от начальства + костыли

в одно это все несовместимо, хотя бы потому что 5,6 и 1,2 для разных умов
да и 3 и 4 - тоже

P.S. без обид, но за "с примерами" - в лучшем случае твои книги - это 6
Ответ написан
@dmshar
Таких книг есть, и много. Однако, существует одно большое "но". Многие хотят "все и сразу" - быстро научиться программировать, быстро научиться проектировать ИС, быстро зарабатывать деньги.
На самом деле все сложнее. Можно быстро освоить язык программирования и его фреймворки. Можно относительно быстро разобраться с базами данных и все что вокруг себя. Можно быстро понять, как построены веб-приложения и как их писать. И пр.пр.пр. Таким образом вы приобретаете некие навыки, грубо говоря - это уровень советского ПТУ, техникума, по современному - наверное - колледж. А потом приходит такой молодой (и даже с опытом) специалист на работу, ему дают задачу "спроектировать некую ИС". И тут - засада. Оказывается, для этого мало знать технологии, о которых написал выше и им подобные. Для того, что-бы правильно, аккуратно, и главное - эффективно спроектировать ИС надо обладать некой эрудицией в области ИТ, которой очень трудно научить, и которая постигается только с опытом реальной работы. Системный архитектор - это не просто программист с Х-лет стажа, это человек который набрал много много опыта реальных проектов (К слову, не верьте, когда в Универе или еще где вам будут предлагать обучиться на эту специальность. Это просто профанация).
Однако не все так печально. Есть книги, в которых описаны множество различных методов и подходов к проектированию, которые призваны ПОМОЧЬ на пути освоения специальности Системного архитектора. Именно помочь, показать на примерах, объяснить и пр. А вот "стройной теории" как единственно правильно построить ИС нет и быть не может - уж очень разные ИС могут быть - от он-лайн магазина до системы управления работой АЭС, от медицинской диагностической системы до бухгалтерии. И при проектировании каждой такой системы применяются разные подходы.
Теперь про книги, которые как-то пытаются систематизировать эти знания, безотносительно к конкретным языкам, технологиям или предметным областям. Часто информация по теме в виде отдельных - и часто очень объемных частей - рассматривается в книгах, посвященных управлению процессом разработки ИС.
Есть "почти классика", или лучше сказать - специально-учебная литература, например,
- Геркул В.И. и др. Проектирование информационных систем, Курс лекций.
- Гвоздева Т.В, Проектирование информационных систем.
- Смирнов Н.В Проектирование информационных систем\ Конспект лекций
Есть более прикладные, но все еще обобщающие книги, например:
-КузнецовМ.В. и др. Практика разработки Web-сайтов
- Мацяшек Л. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML
- Горбаченко В.И. и др. Проектирование информационных систем с CA ERwin.
- Черемных С.В., Моделирование и анализ систем. IDEF – технологии.
- Исаев Г.Н. Проектирование информационных систем.
Есть куча книг переводных, в которых описываются как конкретные практики и подходы, так и общие идеи (некоторые из перечисленных ниже книг вообще были первыми, в которых поднималась некоторая тема, которая сегодня кажется общеизвестной):
- Ройс У. Управление проектами по созданию ПО.
-Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению.
- Вигерс К. (Разработка требований к программному обеспечению.
- Орама Э. Уилсон Г. Идеальная разработка ПО. Рецепты лучших программистов.
- Брауде Э.Дж. Технология разработки программного обеспечения.
- Фатрепп Р. и др. Управление программными проектами.
И т.д. до бесконечности.
Ну и стандарт ISO/IEC 12207 никто не отменял.
Если вы хотя-бы просмотрите хотя бы часть из этого (бесконечного) списка - некоторые вопросы проектирования ИС вам станет решать легче. Но не обольщайтесь, компонент неопределенности и личного творчества в этом деле все равно останется очень большим.
Удачи в продвижении к высотам профессии :-)
Ответ написан
planc
@planc
https://aosabook.org/en/index.html (роскомпозор как всегда на высоте, смотрим через прокси)
Ответ написан
AngryProgrammer001
@AngryProgrammer001
Unity C# Developer
Code complete - в нем все что вам нужно
Ответ написан
@ivodopyanov
NLP, python, numpy, tensorflow
"Совершенный код" МакКоннела
"Чистый код" Мартина
"Приемы объектно-ориентированного проектирования" Эрих Гамма и т.д. - т.н. "банда четырех"
"Scrum и XP: заметки с передовой"

За эскизы архитектуры и UML-диаграммы никто не заморачивается. Слишком часто архитектура меняется, и диаграммы быстро теряют актуальность. Задачу разработчику никто никогда не формулирует на уровне архитектуры классов. А когда ты сам начинаешь реализовывать какой-то функционал, твоя первоначальная задумка может раз 5 измениться, потому что какой-то момент в постановке забыл.
UML бывает полезен, когда один разработчик другому хочет свой код объяснить. Но в таком случае лучше бы он еще раз вышеупомянутые книжки перечитал.
Ответ написан
@asd111
@akimdi
смежный вопрос ссылка
Ответ написан
@dplsoft
сушествуют паттерны проектирования, существуют подходы и принципы (компонентно-ориентированная архитектура, избегание зависимостей все ко всем и пр).
есть разные книги это описывающие.

но важно понять: нет и не может быть указаний как правильно проектировать. есть только советы, лучшие практики и опыт. потому что правильная архитектура - контекстно-зависима : она зависит и отвечает ситуации, задаче в которой ты ее создаешь.

один и тот же прием в разных ситуациях может быть правильным или нет.
потому надо изучать принципы, подходы, шаблоны проектирования и понимать их границы применимости - когда тот или иной шаблон применять стоит, а когда его надо модифицировать, а когда и вовсе не применять.

все шаблоны проектирования не спроектированны специально, а "исторически проверены" - это лучшие практики - т.е. "вот эти варианты организации ситсем" в большей части ситуаций вызывали наименьшее число проблем. т.е. люди делали по разному, но "вот это приметилось". (при этом были комбинации в которых хорошо работали совсем уж "антипаттерны", и это , на самом деле нормально, но новичку луше не применять эту "черную магию").

в общем - тут нет чего то специально созданного и заявленного как "вот это правильно". потому и быть не может книги "о том, как правильно проектировать сами схемы".

архитектура должна обеспечивать выполнение задач программы/системы, не должна создавать лишних проблем при модификации и развитии.

пишите, создавайте... для оценки качества решений сначала подойдут критерии , что самая правильная архитектура - это когда программа работает, не содержит глюков, не ломается на неверных данных. ну и то, что в ней может разобраться ваш коллега, который не в курсе вашей задачи, что бы модифицировать её и модицификация и переработка не вызывают чрезмерных трудозатрат.
а дальше - уже по ситуации.
Ответ написан
@Ambrosian
Плюсом к упомянутым "Мифический человеко-месяц" Ф. Брукса.
Оно как бы для менеджеров управляющих программистами.
Но и программистам полезно.
Например, что оценки сложности/сроков работ у программистов "слишком оптимистичные, в разы"
Книжка тонюсенькая - прочитаете быстро.
Ответ написан
@Gudsaf Автор вопроса
Школьник
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development Крэга Лармана в коллекцию вопроса.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы