книги по проектированию приложений

Как прокачаться в проектировании программного обеспечения — список книг

книги по проектированию приложений

Mar 18 · 11 min read

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

книги по проектированию приложений

Сами книги я условно поделил на 3 категории, которые больше сфокусированы на отдельных вопросах

И начнем мы с вопроса

Что делаем

Для того, чтобы с д елать хорошую архитектуру системы хорошо бы глубоко разобраться в предметной области и дальше учитывать это знание при проектировании. Для этого подойдет концепция Domain Driven Design и я рекомендую прочитать пару книг по этой теме.

Domain-Driven Design: Tackling Complexity in the Heart of Software

книги по проектированию приложений

Каноническая книга, в которой Эрик Эванс изложил концепцию Domain Driven Design. Про нее часто говорят, но гораздо реже ее начинают читать, а дочитывают до конца только избранные. Возможно, причина этого станет ясна, если посмотреть на рис.1, где представлена заглавная страница книги:)

книги по проектированию приложений

What Is Domain-Driven Design?

книги по проектированию приложений

Отличная книга Владика Кононова, который простыми словами обобщил основные концепции и дал рекомендации как их применять в реальном мире. Более подробный разбор книги можно прочитать в моем обзоре.

Как делаем

Fundamentals of Software Architecture

книги по проектированию приложений

В этой книге авторы постарались раскрыть сложную тему основ архитектуры программного обеспечения… и у них получилось достаточно хорошо. Они почти смогли избежать как капитанства, так и общего занудства книг про архитектуру программного обеспечения. Например, они не свалились в бесконечную рефлексию относительно того, что такое архитектура в общем, а также что именно относится к архитектурным решениям. Книга состоит из трех частей:

и раскрываются они хорошо. Подробности о книге можно прочитать в моем обзоре.

Building Evolutionary Architectures

книги по проектированию приложений

Отличная книга, в котором делается акцент на будущих изменениях системы и важности того, что архитектура системы должна позволять осуществляться такой эволюции. Книга написана простым языком и определенно стоит прочтения. Если говорить про содержание, то она состоит из 8 глав, представленных ниже:

Книга определенно заслуживает отдельного обзора. Возможно, у меня и дойдут когда-то рукои до его написания.

Designing Data-Intensive Applications

книги по проектированию приложений

Читал эту книгу в переводе от издательства “Питер”, которое перевело название книги как “Высоконагруженные приложения”. Заметим, что ни слова про высокую нагрузку по данным:) В остальном перевод вышел довольно хорошим.

О качестве книги говорит то, что после первых 2 глав я заказал себе бумажную копию книги и поставил рядом с 2 томиками Таненбаума, книжкой GoF и другими классическими книгами. Кстати, отдельно надо сказать про иллюстрации к каждой главе — они превосходны. Очень наглядно отображены взаимосвязи между сущностями, про которые дальше упоминает автор книги. Прочтение книги у меня заняло почти месяц с перерывами, т.к. книга чрезвычайно емкая по содержанию.

Книга разбита на три части и 12 глав:

Первая часть является вводной и состоит из глав:

Вторая часть включает в себя главы:

Часть 3 состоит из глав:

Книга просто превосходна для тех, кому приходится проектировать/разрабатывать системы, которые хранят/обрабатывают данные:)

Designing Distributed Systems

книги по проектированию приложений

Автор книги является сооснователем kubernetes, поэтому его опыт в проектировании распределенных систем является довольно актуальным:) Книга мне показалось хорошей, но одновременно слишком простой. Но за счет этого она отлично подойдет новичкам вступающим на запутанную дорожку distributed systems:)

Книга состоит из 3х частей:

Все паттерны даются в контексте контейнеров и их оркестрации, книга содержит практические примеры, для реализации которых используется инсталляция kubernetes и его примитивы, такие как pods, deployments, services, etc. Ближе к концу книги вы попробуете использовать helm для разворачивания etcd, kafka и иже с ним.

В первой части рассматриваются паттерны:

Во второй части рассматриваются:

В третьей части рассматриваются паттерны проектирования систем пакетных вычислений:

Architecting for Scale, 2nd Edition

книги по проектированию приложений

Читать лучше на английском, т.к. на русском первое издание этой книги назвали как “Масштабирование приложений. Выращивание сложных систем”. Выращивать можно на даче картошку:) А тут все вертится относительно правильной архитектуры приложений, которая позволяет масштабироваться, сохраняя высокую доступность. Кстати, есть еще проблема, что переводные русские термины не сопровождаются их английскими аналогами — это приводит к тому, что не всегда очевидно о чем рассказывает переводчик. Приходиться восстанавливать это знание из контекста перевода:) Если абстрагироваться от перевода и заглянуть в содержание книги, то автор раскрывает следующие мысли:

Cloud Native

книги по проектированию приложений

Книжка про самый популярный сейчас способ разработки ПО, а именно про разработку приложений, готовых к облакам:) В будущем я планирую написать саммари по этой книге.

Patterns of Enterprise Application Architecture

книги по проектированию приложений

Каноническая книга, которой в следующем году исполнится 20 лет. Я не мог здесь ее не упомянуть, но читать стоит с осторожностью, т.к. все эти паттерны из мира Java приложений, которые были на рубеже тысячелетий:)

Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions

книги по проектированию приложений

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

А если серьезно, то в самом начале книги (2 глава) дается отличный обзор разных стилей интеграции приложений:

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

Дальше (в главе 3) авторы рассказывают про составные части системы обмена сообщениями, а в следующих главах подробно рассматривают паттерны для каждой из частей, а именно

В конце (глава 11) рассматриваются вопросы управления системой, которые очень полезно рассмотреть, чтобы не погрязнуть в непроработанных заранее вопросах тестирования и отладки системы. Приятно, что в системе есть 3 практикума, где рассматривается создание несложных систем, с использованием только что рассмотренных паттернов. Изюминкой является рассмотрение процесса проектирования реальной системы по торговле облигациями в главе 13 данной книги.

Очень рекомендую почитать книгу тем, кто планирует или реализует архитектуру с использованием микросервисов:) Знание этих паттернов позволит вам не наступать на грабли и не изобретать велосипеды.

Monolith to Microservices

книги по проектированию приложений

Книжка определенно хороша. Правда, она является не продолжением книги про создание микросервисов, а скорее приквелом для выпущенной изначально книги. Об этом говорит и сам автор во вступлении, посыпая голову пеплом относительно того, что он открыл ящик Пандоры с микросервисами, что привело к массовому adoption’у их всеми подряд без глубокого понимания границ применимости этого подхода:)

В новой книге Сэм Ньюман рассматривает такие темы как:

Во всех упоминавшихся выше темах автор приводит логичные аргументы

Особенно мне нравятся заключительные слова автора о двух идеях, которыми он хотел поделиться в своей книге:

First, give yourself enough space and gather the right information to make rational decisions. Don’t just copy others; think instead about your problem and your context, assess the options, and move forward, while being open to change if you need to later. Second, remember that incremental adoption of microservices, and many of the associated technologies and practices, is key

Очень логичные и понятные мысли, которые заставляют трезво смотреть на любые подходы к решению задач. И да, на микросервисы тоже:)

Building Microservices, 2nd Edition

книги по проектированию приложений

Если говорить кратко, то книга объективно хороша. Автор рассматривает проектирование программного обеспечения от и до.

В книге на примерах демонстрируется какие преимущества есть у монолита (да, они тоже есть) и какие у микросервисов (а их гораздо больше).

Не забывает автор и о “сопутствующих” вопросах, навроде интеграции всей пачки получившихся микросервисов, их тестирования, развертывания и мониторинга. Забавно, что если не рассматривать эти вопросы в самом начале, то система из микросервисов будет напоминать пазл с потерянными кусками, которые препятствуют его сбору в финальный продукт.

Упоминает автор и про закон Конвея, который говорит о том, что техническая архитектура повторяет организационную структуру компании. Автор делает предположение, что это работает и в обратную сторону. Если данная гипотеза верна, то это позволяет получить помимо более удачной технической архитектуры и более удачную организационную в случае применения микросервисов.

На закуску рассматриваются вопросы масштабирования микросервисов.

В общем, читайте книгу и не пожалеете.

Правда, для максимальной простоты прочтения хорошо бы, чтобы Вы имели опыт разработки и прошли все стадии от создания монолитов до перехода к микросервисной архитектуре. В этом случае книга будет читаться элементарно, а автор будет восприниматься как Капитан Очевидность:))

Как эксплуатируем

Release It!, 2nd Edition

книги по проектированию приложений

Начинается все с введения, где автор рассказывает о том, что побудило написать эту книгу, дальше он переходит к первой части, в которой рассматривается такое понятие как стабильность:)

Часть посвященная стабильности состоит из глав, в которых рассказывается о

Дальше автор переходит ко второй части, в которой обсуждает дизайн системы для production, в третьей части идет речь про delivery вашей системы, а в четвертой — про решение системных проблем. В общем, отличная книжка для людей участвующих в разработке программного обеспечения.

Site Reliability Engineering

книги по проектированию приложений

Книга определенно мне понравилась, но есть нюанс …

Нюанс заключается в том, что название SRE в головах людей получило коннотацию Devops, что в принципе неплохо, но … у кого из знакомых разработчиков я не спрашивал читали ли они эту книгу, то получал ответ в стиле “Нет, это вроде что-то для devops’ов”

На самом деле книга определенно хороша и ряд глав стоит прочесть разработчикам в первую очередь. Структура книги довольно проста и состоит из 5 частей:

В введении кратко описывается содержание книги, а вот уже в принципах начинается интересное и рассматриваются вопросы, касающиеся:

В части, касающейся практик, приводится порядка 20 глав, среди которых особо важны для разработчиков главы касающиеся:

В части про управление рассказано о некоторых вопросах менеджмента команд SRE. А в последней части, называющейся “Выводы” проводятся параллели между разработкой ПО в Google и разработкой mission critical систем в авиастроении, кораблестроении, атомной энергетике и т.д.

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

The Site Reliability Workbook

книги по проектированию приложений

Данная книга является продолжением предыдущей и рассказывает о том, как внедрить SRE подходы в вашей компании:)

Источник

Книги о проектировании и разработке программного обеспечения

Шаблоны проектирования

книги по проектированию приложенийЭ. Гамма Приемы объектно-ориентированного проектирования. Паттерны проектирования / Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес. – СПб.: Питер, 2009. – 366 с.

Классическая и наиболее известная книга о шаблонах проектирования. Описание каждого шаблона достаточно подробное, обычно содержит несколько вариантов реализации с их слабыми и сильными сторонами. Примеры в книге приведены на C++ и Smalltalk, однако словесное описание и UML диаграммы помогут разобраться программистам на других языках. Рекомендую посмотреть книгу всем без исключения будущим программистам.

книги по проектированию приложенийВлиссидес Джон. Применение шаблонов проектирования. Дополнительные штрихи. : Пер. англ. М.: Издательский дом «Вильямс

Хорошее дополнение к книге Гаммы и Хелма с несколько другим способом изложения и местами более интересными примерами. Начинается книга с заблуждений о шаблонах — далеко не все, особенно студенты, понимают как ими пользоваться. По ходу книги автор ставит перед читателем ряд проблем и всякий раз выполняет поиск подходящих шаблонов проектирования, при этом приводится даже некоторый алгоритм выполнения такого поиска. Первым примером книги является проектирование файловой системы (с сущностями «Файл», «Каталог», «Ярлык»), на нем рассматриваются паттерны Composite, Proxy (для реализации «Ярлыка» файла — этот пример сильно отличается от того, что приведено в GoF), Visitor (тоже очень удачное применение) и Template Method (в контексте рефакторинга и инверсного управления). Затем, в пример добавляется владелец файла, но пользователей нужно создавать, а еще они объединяются в группы. На примере системы управления пользователями рассматриваются шаблоны Singleton и Mediator (для связи пользователей с группой «многие ко многим»). В конце второй главы приводится хорошая диаграмма «pattern: role annotation». В третьей главе рассматриваются тонкости и проблемы реализации шаблонов — начинаются с Singleton-а (проблема с зависимостями между несколькими Одиночками, параллельным программированием и освобождением памяти из под них). Затем также рассматривается Observer и Visitor (на мой взгляд, выбран слишком примитивный пример с построением графического интерфейса из двух полей ввода и кнопкой). В конце главы описывается «нестандартный» шаблон Generaton Gap — лично я про него читал впервые, применить вы его сможете лишь в тех случаях если ваша система генерирует исходный код программ, рассматривается он на примере генератора пользовательского интерфейса (типа Qt Designer), но отмечается что нечто подобное используется в YACC. Цель паттерна Generaton Gap — убрать зависимость между сгенерированным системой кодом и тем, что дописывает потом вручную пользователь, для этого предлагается, казалось бы очевидное решение — генерируемый код помещается в базовый класс, который пользователь может наследовать для увеличения функциональности (хотя я бы рассмотрел также вариант с композицией). Последним примером книги является система обработки событий (Event), при этом ставится проблема — типов событий много, но, получив событие, мы не хотим выполнять кучу dynamic_cast для установления его типа. На этом примере описаны шаблоны Mulicast и Typed Message — лично мне это показалось бесполезным. В конце книги приводится рекомендации по разработке шаблонов проектирования (семь правил, которые помогут вам придумать новый шаблон) — я бы назвал это правилами по изучению шаблонов (советую прочитать). В целом, хорошая книга, но с плохим переводом (очень много явных ляпов) и местами устаревшая (т.к. примеры написаны на С++, который развивался и сильно изменился, а книга старая) — например не совсем правильно подмечены недостатки Singleton-а Маерса и описан неактуальный подход с Double-Clecked Locking (хотя для истории и кругозора может пригодится).

UML и объектно-ориентированный анализ

книги по проектированию приложенийБуч Градди Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е изд. / Буч Градди, Максимчук Роберт А., Энгл Майкл У., Янг Бобби Дж., Коналлен Джим, Хьюстон Келли А.: Пер с англ. — М.: ООО «И.Д. Вильямс», 2010. — 720 с.

Классическая книга по программированию от очень авторитетного автора. В книге есть множество интересных и важных для программиста вещей, но они обильно разбавлены рассуждениями на отвлеченные темы и, на мой взгляд, очень неудачными примерами про теплицы. Во второй вам расскажут про общие принципы ООП; в третьей главе — дополнят некоторыми обозначениями UML и интересным разделом про качество классов и объектов; в четвертой — рассматриваются различные подходы к классификации и уточнению абстракций. Пятая глава книги содержит описание 13 видов UML диаграмм, но на мой взгляд Буч выбрал не самые лучшие примеры и недостаточно времени уделил описанию назначения этих диаграмм. Шестая глава содержит описание процесса разработки программного обеспечения, при этом выделяются макропроцесс (жизненный цикл проекта) и микропроцесс (проектирование) — для них описываются стадии с видами деятельности на каждой из них. Седьмая глава завершает изложение очень коротким описанием организационных вопросов. Вторую половину книги составляют примеры приложений (можно посмотреть в каком порядке Буч предлагает их проектировать и какие виды диаграмм использовать).
Все главы кроме пятой очень обзорные — в них нет смысла вчитываться, по этим темам написаны отдельные толстые книги. Например, про качество ПО в нескольких книгах рассуждает Роберт Мартин, а про проектирование ПО (микропроцесс) написал отдельную книгу Розенберг — при этом он использует другой подход (ICONIX). Очень часто долгие рассуждения Буча касаются очевидных вещей и как бы вы не вчитывались — не получится узнать что-то новое, поэтому я считаю, что книгу достаточно бегло просмотреть. Наиболее полезные, на мой взгляд, части книги:

Книга посвящена разработке программного обеспечения в соответствии с процессом ICONIX, поэтому несмотря на то, что в названии фигурирует UML — рассматриваются всего 4 вида диаграмм (прецедентов, пригодности, последовательности и классов). Диаграмма пригодности не описана во многих других книгах по UML, т.к. в стандарте UML она описана в дополнении. В книге не только описываются сами диаграммы, но и процесс разработки ICONIX, который является итеративным, что оказывает влияние на процесс построения диаграмм. Каждому виду диаграммы посвящена отдельная глава, в конце которой приводится топ 10 ошибок — это тоже очень полезная и интересная часть. Книга в 7 раз тоньше произведения Буча, а полезной информации, на мой взгляд, в ней больше.

книги по проектированию приложенийБуч Г., Рамбо Д., Джекобсон А. Язык UML Руководство пользователя — С-П.: Издательство «Питер», 2010 — 432 с.

Долгое время единственной действительно хорошей книгой, посвященной объектно-ориентированному анализу и проектированию, была книга Буча, в которой рассматривалась его нотация. Основываясь на ней, конечно же, можно было понять UML, но почему-то лишь немногие были на это способны. В тоже самое время, иногда появлялись какие-то журнальные статьи, в которых упоминался UML. Обычно эти статьи не отличались подробностью и просто пересказывали то, что когда-то услышал автор по этой теме. Вообще, это происходит потому, что практикующие пользователи UML редко когда пишут статьи.

Практически каждый программист слышал словосочетание Rational Rose, но обычно плохо себе представляет что это такое. Мало того, традиционна следующая ситуация: программист что-то услышал о программном продукте, с радостью его установил себе на компьютер (давайте не будем уточнять, как он достал себе копию), запустил программу… а она оказалась совсем не похожей на WinWord. Т.е., как нарисовать стрелку ясно, а что за ней стоит и как это потом использовать — непонятно.

Надо сказать, что использование CASE продуктов подразумевает наличие хотя бы базовых знаний об используемой технологии. Я сомневаюсь, что человек, основываясь на одном лишь здравом смысле, сможет понять зачем нужна Rational Rose. По крайней мере потому, что там используется специфическая терминология для выбранной нотации.

Так вот, эта книга, является одной из трех книг, написанных создателями UML. Это полное изложение UML, позволяющее читателю изучить его и приступить к практическому использованию. В книге не рассматриваются принципы объектно-ориентированного анализа, поэтому от читателя потребуется знакомство с ним (например, по соседней книге Буча).

Поэтому, если вы уже применяете UML достаточно долгое время, то «Руководство пользователя» вряд ли будет для вас обладать какой-то особенной ценностью, но если вы хотите овладеть им — нверное, это то что нужно.

Итог:
Книга, несомненно, достойна того, что бы ее прочитали хотя бы для ознакомления с нотацией. Она не является основополагающей, как «Объектно-ориентированный анализ и проектирование» Гради Буча, но все равно достаточно интересна.

Чистый код и рефакторинг

книги по проектированию приложенийМартин Р. Чистый код. Создание, анализ и рефакторинг. Библиотека программиста. — СПб.: Питер, 2014. — 464 с.

Книга посвящена вопросам написания программного кода, который легко поддерживать — обсуждаются не только стили кодирования, форматирования, но и, например, структура хорошего кода, юнит-тестирование, использование исключений. В контексте чистого кода описываются некоторые шаблоны проектирования. Альтернативой можно считать книгу Фаулера (она также посвящена чистому коду), но Роберт Мартин пишет гораздо интереснее. Рекомендую прочитать книгу всем студентам, прошедшим курс объектно-ориентированного программирования.

книги по проектированию приложенийФаулер М. Рефакторинг. Улучшение существующего кода/ М. Фаулер. Символ-Плюс, 2008. 432 с.
книги по проектированию приложенийАллен Э. Типичные ошибки проектирования / Э.Аллен: Пер. с англ. – СПб.: Питер, 2003. – 224 с.

Книги Мартина Фаулера и Эрика Аллена посвящены чистому коду и рефакторингу, но в отличии от книги Боба Мартина, в них делается попытка каталогизации видов рефакторинга (у Фаулера) или ошибок (у Аллена). Если вы разрабатывали что-то чуть-чуть сложнее тетриса — то книги читаются быстро т.к., значительная часть материала вам и так знакома. Книги стоит пролистать, бегло найти интересные моменты и посмотреть их более детально. Покупать их не стоит (я взял на работе почитать), вряд-ли вы будете это перечитывать. С другой стороны, знакомый тимлид требует от работников при рефакторинге указывать конкретный вид (название берется из каталога вот этой книги) в комментарии к коммиту в репозитории. Из книги Аллена мне больше всего понравились главы 2, 3 и 22 — в них можно кое-что узнать об экстремальном программировании, спецификации и тестировании, а также прочитать краткое (но достаточное) описание «паттернов проектирования для отладки». Советую читать именно эти главы.

Другое

книги по проектированию приложенийЧакон Скотт, Страуб Бен Git для профессионального программиста. — СПб.: Питер, 2016. — 496 с.: ил.

В книге автор рассказывает про систему контроля версий «git», при этом делает это не поверхностно (как многочисленные статьи в интернете), а очень подробно. Главы выстроены таким образом, чтобы читатель сразу мог начать пробовать некоторые команды git, а затем узнавать про различные варианты их использования. Очень помогает читать обилие иллюстраций к примерам. Книга настолько полно описывает git, что после нее по этой теме можно читать только stack overflow (какие-то конкретные вопросы все равно будут возникать), но вы будете уметь работать в команде, использующей git, выбирать оптимальный вариант использования git для своей команды, настраивать git на сервере и т.д.

книги по проектированию приложенийС. Бобровский Технологии Пентагона на службе российских программистов. Программная инженерия. — СПб.: Питер, 2003. — 222 с.: ил.

Основная проблема, обсуждаемая в книге — ошибки в программах. В контексте проблемы рассматриваются модели разработки ПО и управления проектами и языки программирования. Книга состоит из четырех глав:

Итог: интересная книга для общего развития. Первая глава слишком поверхностная и посвящена скорее вопросам психологии и мотивации личностного роста программиста. Вторая и четвертая главы имеют полностью обзорный и исторических характер — с их помощью можно расширить кругозор, но не более. Наиболее полезной является третья глава, но ее стоит читать только в том случае если вы решили заняться управлением проектами и никаких других книг по этой теме не читали.

книги по проектированию приложенийБрукс, Ф. Мифический человеко-месяц или как создаются программные системы / Ф. Брукс. — М.: СПб: Символ-Плюс, 2016. — 304 c.

Эта книга не о программировании на конкретном языке. В ней очень ясным, живым языком рассказывается о тех выводах, к которым пришел автор в процессе руководства работы над операционной системой OS/360. Некоторые моменты, конечно же, устарели; например, проблема машинного времени уже не стоит в таком остром ракурсе перед программистами (во всяком случае, в большинстве проектов). Тем не менее, общие рекомендации по обеспечению работы большой группы программистов очень сложно переоценить. Например, вы можете сразу же ответить, что лучше: тысяча посредственных программистов, сто хорошиих или десять гениев? Имеется в виду, для реализации очень крупного проекта в разумное время. Я не говорю о том, что в книге есть ответ на этот вопрос — в книге есть очень полезные мысли на эту тему, которые пригодятся вам при начале работы и наборе сотрудников.

«Мифический человеко-месяц» — это, судя по тому что это выражение вынесено в название, для Брукса самый важный момент в книге. Брукс пишет о том, что нельзя мерять время выполнения проекта просто линейно считая, что если один человек сделает его за сто лет, то сто человек сделают его за один год.

От первого издания отличается тем, что в него добавлена статья «Серебряной пули нет», в которой Брукс двадцать лет назад предупреждал о том, что в течение этих лет в программировании ничего революционного не произойдет и статьей, которая была написана специально для второго издания. Эта статья посвящена актуальным аспектам проектирования и ответу на вопрос о том, почему же «Мифический человеко-месяц» до сих пор остался современным.

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

книги по проектированию приложенийС. Макконнелл Сколько стоит программный проект – СПб.: Питер – 2007

В коммерческой разработке важно уметь оценивать время и прочие затраты, также, нужно уметь делать это до начала разработки. Научиться делать это поможет книга С. Макконнелла, в ней приведены различные методики оценки проекта, для разных условий и размеров компании. Приняв что-то из нее на вооружение можно вдумчиво анализировать реальную ситуацию и давать реальные сроки, а не «пару недель» лишь для того чтобы отстали, срок который, как показывает практика, обычно написан на потолке с правой стороны.

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

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *