Перейти к содержимому

Книги

Книга «Не спеша, эффективно и правильно – путь разработки», автор Никита Зайцев

Рекомендую к прочтению книгу «Не спеша, эффективно и правильно – путь разработки», автор Никита Зайцев (a.k.a WildHare).

Никита Зайцев (a.k.a WildHare)

Черновой вариант книги Никиты Зайцева, a.k.a.WildHare. Разработкой на платформе 1С автор занимается с 1996-го года, специализация — большие и по-хорошему страшные системы. Квалификация «Эксперт», несколько успешных проектов класса «сверхтяжелая». Успешные проекты ЦКТП. Четыре года работал в самой «1С», из них два с половиной архитектором и ведущим разработчиком облачной Технологии 1cFresh. Ну — и так далее. Не хвастовства ради, а понимания для. Текст написан не фантазером-теоретиком, а экспертом, у которого за плечами почти двадцать три года инженерной практики на больших проектах.

«Коллеги, вашему вниманию предлагается почти финальный вариант моей книжки. В третьей части, она же практическое руководство, не хватает нескольких глав, и не факт, что у меня получится их дописать. К сожалению, проблемы со здоровьем. Но хочется, чтобы труд не пропал, поэтому весь текст отдается в открытый доступ. Можно публиковать где угодно, цитировать и так далее. Единственное условие – ничего в тексте не менять и указывать авторство. Автор текста – Никита Викторович Зайцев (также известный как WildHare).
Книжка повествует об эффективной разработке программного обеспечения. Можно сказать, что это дистиллят моей личной практики, наработанного опыта, знаний и умений. Издать ее уже скорее всего не получится, но не хотелось бы, чтобы пропало. Поэтому отдается в открытый доступ.
»

Интервью с автором: Никита Зайцев (a.k.a WildHare): «Я – универсальный солдат в мире 1С».

Дополнение:
В первой части, говорится о книге «Вальсируя с Медведями. Управление рисками в проектах по разработке программного обеспечения.», авторы Том ДеМарко и Тимоти Листер. Так же, рекомендую к прочтению, несколько цитат из книги:

Не беритесь за проект, если в нем нет рисков.
Риски и выгоды всегда ходят парой. Проект полон рисков потому, что ведет на нехоженый путь. Он расширяет ваши возможности, и его успешное осуществление доведет ваших конкурентов до безумия. Но главное – в том, что ваши собственные возможности распространятся настолько, что конкурентам будет нечем ответить. Это дает вам конкурентное преимущество и помогает создать собственный, заметный на рынке брэнд.

Риск:
1. Возможное в будущем событие, которое приведет к нежелательным результатам.
2. Сам нежелательный результат.

Первое – причина, а второе – результат, но не пытайтесь обманывать себя, рассчитывая справиться с обоими. Управление рисками как дисциплина целиком занята управлением причинными рисками. Это – те риски, которыми вы можете управлять (Однако оправданность управления рисками, в первую очередь, связана с результатами).

Риск – это проблема, которая еще не возникла, а проблема – это риск, который уже материализовался.
До своего проявления риск – просто абстракция. Это нечто, что может повлиять на ваш проект, а может и не повлиять. Существует вероятность, что игнорирование риска пройдет безнаказанным. Но даже в этом случае вы не избежите обвинения в том, что оказались плохим управленцем, не учтя риск.
Управление рисками – это процесс продумывания корректирующих действий прежде, чем возникнет проблема, пока она еще остается всего лишь абстракцией. Противоположностью управлению рисками является кризисное управление, попытка понять, что делать с проблемой после того, как она появилась.

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

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

Дополнение:
📻 Старт второго сезона подкаста «Радио 1С Энтерпрайз» Радио 1С Энтерпрайз

Высоконагруженные приложения

Рекомендую к прочтению книгу «Высоконагруженные приложения. Программирование, масштабирование, поддержка» автор Мартин Клеппман, в книге объединены и описаны основные проблемы, нюансы и особенности, с которыми сталкиваешься при работе с высоконагруженными информационными системами.

Обзор книги издательством: https://habr.com/ru/company/piter/blog/352742/

Высоконагруженные приложения. Программирование, масштабирование, поддержка
Высоконагруженные приложения

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

Несколько абзацев из книги:

Чтобы сделать БД отказоустойчивой, реализации B-деревьев обычно включают дополнительную структуру данных на диске: журнал упреждающей записи (write-ahead log, WAL), также именуемый журналом повтора (redo log). Он представляет собой файл, предназначенный только для добавления, в который все модификации B-деревьев должны записываться еще до того, как применяться к самим страницам дерева. Когда база возвращается в норму после сбоя, этот журнал используется для восстановления B-дерева в согласованное состояние.

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

Обеспечиваемые транзакциями гарантии функциональной безопасности часто описываются известной аббревиатурой ACID (atomicity, consistency, isolation, durability — атомарность, согласованность, изоляция и сохраняемость). Она был придумана в 1983 году Тео Хэрдером (Theo H.a.rder) и Андреасом Ройтером (Andreas Reuter) [7] в попытке создать четкую терминологию для механизмов обеспечения отказоустойчивости в базах данных.