20 k

2023-07-22

Читать главу
К книге Страница автора

 Полезные конспекты книг и авторские заметки по информационным технологиям | Глава 1

Писатель: Лот Алексей Сергеевич

Входит в цикл: “Справочник”

Глава в томе: Полезные конспекты книг и авторские заметки по информационным технологиям I

Случайный абзац

Полезные высказывания из книги "Agile для всех" Лемея В разделе приведены цитаты из [1]. Agile - термин, описывающий схожие по сути, но различные по методикам, подходы. Самый популярный Agile-подход - это Скрам: 1) работа разбивается на двухнедельные периоды, называемые спринтами; 2) в конце каждого периода должно быть что-то действительно завершенное и готовое для выпуска; 3) в течение каждого спринта проводится ежедневная планерка (daily standup) или скрам-митинг (scrum meeting); 4) во время митинга каждый член команды делится тем, что он завершил, над чем работает, и что может препятствовать прогрессу; 5) идея получать что-то готовое каждые две недели - стимул для повышения производительности и укрепления морального духа; 6) необходимость личного общения каждое утро - способ улучшить коммуникацию в команде (выявить разногласия); 7) приоритизация и передача результатов в двухнедельные циклы позволяют объективировать противоречия в видении продукта высокого уровня; 8) утренние планерки показывают отставание по срокам; 9) цель - повысить эффективность команды; 10) скрам дает набор рабочих процедур для структурирования деятельности компании. Agile требует соответствия предпринимаемых действий достигаемым целям, ставя вопрос о том, почему сотрудники, команды и организации делают так, а не иначе. Agile предполагает выполнение большего объема работ за меньшее время при условии привлечения больших ресурсов: энергии, открытости, готовности честно размышлять над трудными вопросами. Agile призывает превращать предположения в факты. agilemanifesto.org Agile можно применять во всех отраслях. Нет лучшего или правильного подхода к Agile. Принципы и ценности "Почему" - Практики "Как" - Результаты реального мира "Что" - Принципы и ценности "Почему" Если мы чувствуем, что не соответствуем "Почему", то можем менять "Как", а если "Как" не срабатывает для "Что", то нужно пересмотреть "Почему". Сначала нужно понять, почему возникла потребность в изменении привычного способа работы. Основополагающие принципы Agile: 1) мы начинаем с наших клиентов; 2) мы сотрудничаем на ранних стадиях и часто; 3) мы планируем неопределенность. Манифест Agile: - люди и взаимодействие важнее процессов и инструментов; - работающий продукт важнее исчерпывающей документации; - сотрудничество с заказчиком важнее согласования условий контракта; - готовность к изменениям важнее следования первоначальному плану. Важное здесь не отрицает остального. Mindset - образ мышления. 2001 - основание Agile-движ

Координаты: 1526 год; 0.13 кубика адреналина. Индекс удобочитаемости Флеша — 47, для студентов.

41 k

2023-07-22

Читать главу
К книге Страница автора

 Полезные конспекты книг и авторские заметки по информационным технологиям | Глава 2

Писатель: Лот Алексей Сергеевич

Входит в цикл: “Справочник”

Глава в томе: Полезные конспекты книг и авторские заметки по информационным технологиям I

Случайный абзац

Имена методов - глаголы или глагольные словосочетания. Методы чтения или записи и предикаты образуются из значения и префикса get, set и is. При перегрузке конструкторов использовать статические методы-фабрики с именами, описывающими аргументы (принудительное инспользование таких методов). Нет остроумных шуток. Ясность предпочтительнее развлекательной ценности. Нет просторечий и сленга. Нет шуток. Одно слово для каждой концепции. Имена функций законченные и логичные. Нет эквивалентных методов с именами fetch, retrieve, get в разных классах. Нет controller, manager, driver в одной кодовой базе. Имена различны принципиально. Единый, согласованный лексикон. Не используется одно слово в двух смыслах. Две разные идеи не обозначены одним термином. Нет каламбура. Мысли в коде выражаются доступно. Используются имена из пространства решения: термины из области информатики, названия алгоритмов, паттернов, математические термины, технические имена. Используются имена из пространства задачи (клиентские): если нет подходящего программизма, узнаются у специалиста в предметной области. Разделение концепций из пространств задачи и решения. Не содержательные сами по себе имена помещаются в определенный контекст для читателя кода - классы, функции и пространства имен с правильно выбранными названиями. В крайнем случае контекст уточняется префиксом. Контекст не должен вычисляться. Функции разделяются на меньшие смысловые фрагменты. Нет избыточности контекста. Нет работы против собственного инструментария. Короткие имена лучше длинных, если только их смысл понятен читателю кода. Имена экземпляров более точные. Развивать описательные навыки и единый культурный фон. Не должно быть опасения возражений при переименовании. Функции: Первый уровень структуризации. Длина не избыточна. Не содержит повторяющихся фрагментов кода. Один уровень абстракции. Функции компактны. Функции ещё компактнее. Функции желательно не более 20 строк. Все функции предельно очевидны. Блоки в командах if, else, while и так далее должны состоять из 1 строки, в которой обычно - вызов функции. Функции не содержат вложенных структур. Не более 1-2 отступов. Функция должна выполнять только одну операцию. Она должна выполнять её хорошо. И ничего другого она делать не должна. Если функция выполняет только те действия, которые находятся на одом уровне под объявленным именем функции, то эта функция выполняет одну операцию. Функции пишутся прежде всего для разложения более крупной концепции (иначе говоря, имени функц

Координаты: 2220 год; 0.13 кубика адреналина. Индекс удобочитаемости Флеша — 25, для магистров.

41 k

2023-07-22

Читать главу
К книге Страница автора

 Полезные конспекты книг и авторские заметки по информационным технологиям | Глава 3

Писатель: Лот Алексей Сергеевич

Входит в цикл: “Справочник”

Глава в томе: Полезные конспекты книг и авторские заметки по информационным технологиям I

Случайный абзац

Горизонтальное масштабирование посредством более дорогих и качественных компьютеров обеспечит более устойчивую и надежную работу. В крупных системах предпочтение стоит отдавать горизонтальному масштабированию. Систему с горизонтальным масштабированием проще обслуживать. Основной недостаток горизонтального масщтабирования - высокие затраты на администрирование и значительные накладные расходы, связанные с управлением десятками, сотнями и тысячами серверов (проблема решается API-интерфейсами администрирования). Горизонтальное масштабирование следует рассматривать в первую очередь для приложений со значительной целевой аудиторией и тенденцией к устойчивому росту. В некоторых случаях горизонтального масштабирования разработчики сталкиваются со специфическими требованиями к дизайну, которые не поддаются линейному масштабированию. При масштабировании уровня БД веб-приложения к вашим услугам вертикальное и горизонтальное масштабирования. В MSSQL масштабирование выполняется созданием федерации и секционированием. Выбирайте простую архитектуру, чтобы будущее расширение приложения не привело к недопустимым затратам на его обслуживание. Выбирайте дизайн, пригодный для горизонтального масштабирования. Используйте устройства для балансировки нагрузки (серверы можно добавлять и удалять в процессе работы). Правильный выбор аппаратного обеспечения практически всегда связан с использованием однотипного оборудования на всех серверах определенного типа. Стандартизация оборудования не только экономит средства за счет оптовых закупок, но также снижает затраты на диагностику и обслуживание. При сбое в ключевом компоненте приложение должно продолжать работу в сокращенном объеме (приложение должно быть отказоустойчивым). Отказоустойчивость следует применять только к более важным компонентам. На разработчике лежит ответственность за своевременное информирование руководства о важности создания отказоустойчивой инфраструктуры и о возможных вариантах её создания. Приложение должно проектироваться таким образом, чтобы минимизировать влияние зависимостей. Сужение функциональности лучше, чем сообщение об ошибке. Приложения должны быть просты в эксплуатации (приложение должно обладать управляемостью и сопровождаемостью). Данные инструментирования может собирать отдельная служба. Ведите активный мониторинг приложения. Выделите ключевые метрики и цели мониторинга. Планируйте стратегию роста и стратегию реакции на сбои. Масштабирование "по ролям": отдельные функциональные области масштабиру

Координаты: 1840 год; 0.11 кубика адреналина. Индекс удобочитаемости Флеша — 32, для бакалавров.

41 k

2023-07-22

Читать главу
К книге Страница автора

 Полезные конспекты книг и авторские заметки по информационным технологиям | Глава 4

Писатель: Лот Алексей Сергеевич

Входит в цикл: “Справочник”

Глава в томе: Полезные конспекты книг и авторские заметки по информационным технологиям I

Случайный абзац

Рефакторинг предоставляет технологию приведения кода в порядок, осуществляемую в более эффективном и управляемом стиле. При каждой возможности проводить тестирование. Цель рефакторинга - упростить понимание и модификацию ПО. Оптимизация производительности часто затрудняет понимание кода. Рефакторинг не меняет видимого поведения ПО. Рефакторинг улучшает композицию ПО. Изменение размера образа программы в памяти редко имеет значение. Удаление дублирующегося кода улучшает композицию. Рефакторинг облегчает понимание ПО. Рефакторинг делает код легким для чтения. Рефакторинг позволяет увидеть в коде больший объем системы. Рефакторинг помогает найти ошибки. Рефакторинг ускоряет понимание программ. Рефакторингом следует заниматься постоянно понемногу. Сначала необходимость рефакторинга будет неприятна. Чаще всего рефакторинг начинается с необходимости добавления в ПО новой функции. Рефакторинг - процесс быстрый и ровный. Получение сообщения об ошибке - причина провести рефакторинг. Проводить рефакторинг при разборе кода. Рефакторинг облегчает модификацию. Рефакторинг способствует получению более конкретных результатов от разбора кода. Использовать UML и CRC-карты при разборе дизайна кода. Рефакторинг разделяет большие объекты на несколько меньших . Благодаря помещению отдельного программного слоя между объектной моделью и моделью базы данных можно отделить модификации двух разных моделей друг от друга. Если изменяемый интерфейс используется недоступным для изменения кодом, то из старого интерфейса вызывать новый, пометив старый как устаревший. Не нужно предоставлять интерфейсы, которые не требуются. Не публиковать интерфейсы раньше срока. Определять родительский класс исключения для пакета в целом. Представлять себе возможный рефакторинг. Перед началом рефакторинга код должен выполняться в основном корректно, иначе - переписать код с нуля. Рефакторинг должен подразумевать его завершение. Окончание проекта может быть причиной отложения рефакторинга. Программа весьма отличается от физического механизма. Рефакторинг может быть полной заменой предварительному проектированию. При рефакторинге от предварительного проектирования требуется приемлемое решение, а не единственно правильное. Гибкие решения сложнее обычных. Даже если точно известно устройство системы, не заниматься гаданием, а провести замеры. Секрет создания быстрых программ: написать настраиваемую программу, а затем настроить так, чтобы достичь приемлемой скорости. Подходы написания быстрых программ: при дек

Координаты: 2240 год; 0.12 кубика адреналина. Индекс удобочитаемости Флеша — 26, для магистров.

41 k

2023-07-22

Читать главу
К книге Страница автора

 Полезные конспекты книг и авторские заметки по информационным технологиям | Глава 5

Писатель: Лот Алексей Сергеевич

Входит в цикл: “Справочник”

Глава в томе: Полезные конспекты книг и авторские заметки по информационным технологиям I

Случайный абзац

Поддержка языком операций вроде Open() или Close() при отсутствии информации о конкретном типе двери вплоть до периода выполнения называется полиморфизмом. Интерфейсы классов должны быть полными и минимальными, должны сообщать как можно меньше о внутренней работе класса (класс похож на айсберг, большая часть которого скрыта под водой). Разработка интерфейса класса - итеративный процесс (пытаться создать или использовать другой подход). Сокрытие аспектов проектирования позволяет значительно уменьшить объём кода, затрагиваемого изменениями (например, применение именованных констант вместо литералов; сокрытие информации: "id=new Id();" вместо "id=++g_maxId;"). Категории секретов: -секреты, которые скрывают сложность, позволяя программистам забыть о ней при работе над остальными частями программы; -секреты, которые скрывают источники изменений с целью локализации результатов возможных изменений. Барьеры, препятствующие сокрытию информации: -избыточное распространение информации (например, использование литералов вместо констант, распространение кода взаимодействия с пользователем по системе - GUI концентрировать в одном классе (пакете, подсистеме)); -круговая зависимость (B зависит от А, который зависит от B; не позволяет протестировать один класс, пока не будет готова часть другого); -ошибочное представление о данных класса как о глобальных данных; -кажущееся снижение производительности. Крупные программы, использующие сокрытие информации, в 4 раза легче модифицировать, чем программы, его не использующие. Размышлять о том, что скрыть. Подготовка к изменениям: 1.Определите элементы, изменение которых кажется вероятным; 2.Изолируйте элементы, изменение которых кажется вероятным. Интерфейс класса должен скрывать изменения в классе. Области, изменяющиеся чаще всего: -бизнес-правила; -зависимости от оборудования; -ввод-вывод; -нестандартные возможности языка; -сложные аспекты проектирования и конструирования; -переменные статуса. В качестве переменных статуса применять не булевы переменные, а перечисления. Вместо непосредственной проверки переменной использовать методы доступа. Проектировать систему так, чтобы влияние изменений было обратно пропорционально их вероятности. Если изменение маловероятно, но его легко предугадать, рассмотрите его внимательнее, чем более вероятное изменение, которое трудно спланировать. Функции, нужные пользователям - ядро системы, которое не потребуется изменять. Путём небольших приращений экстраполировать систему, определяя дополнител

Координаты: 1504 год; 0.14 кубика адреналина. Индекс удобочитаемости Флеша — 19, для профессионалов.

41 k

2023-07-22

Читать главу
К книге Страница автора

 Полезные конспекты книг и авторские заметки по информационным технологиям | Глава 6

Писатель: Лот Алексей Сергеевич

Входит в цикл: “Справочник”

Глава в томе: Полезные конспекты книг и авторские заметки по информационным технологиям I

Случайный абзац

Обзор кода эффективнее тестирования. Ошибки в требованиях или архитектуре обычно имеют более широкие следствия, чем ошибки конструирования. Повышение качества системы снижает расходы на ее разработку. Средняя производительность труда программистов эквивалентна 10-50 строкам кода на одного человека в день. Устранение дефектов - самый дорогой и длительный этап разработки ПО. На создание ПО без дефектов не всегда уходит больше времени, чем на написание ПО с дефектами. Разработчики допускают в среднем от 1 до 3 дефектов в час при проектировании и от 5 до 8 дефектов в час при кодировании. Каждый час инспекции кода предотвращает около 100 часов аналогичной работы (тестирования и исправления дефектов). Поддерживайте парное программирование стандартами кодирования. Не позволяйте парному программированию превратиться в наблюдение. Не используйте парное программирование для реализации простых фрагментов. Регулярно меняйте состав пар и назначаемые парам задачи. Объединяйте в пару людей, предпочитающих одинаковый темп работы. Убедитесь, что оба члена пары видят экран. Не объединяйте в пары людей, которые не нравятся друг другу. Не составляйте пару из людей, которые ранее не программировали в паре. Назначьте лидера группы. Инспектор может проанализировать за час около 500 строк. Тестирование - самая популярная методика повышения качества. Тестирование - средство обнаружения ошибок. Отладка - средство поиска и устранения причин уже обнаруженных ошибок. Тестированию, выполняемому разработчиками, следует посвящать от 8% до 25% общего времени работы над проектом. Искусство тестирования заключается в выборе тестов, способных обеспечить максимальную вероятность обнаружения ошибок. Структурированное базисное тестирование - протестировать каждый оператор программы хотя бы раз. Проверяйте код тестов. Планируйте тестирование программы так же, как и ее разработку. Храните тесты. Встраивайте блочные тесты в среду тестирования. Используйте генераторы случайных данных. Изучите программу, над которой работаете. Изучите собственные ошибки. Изучите качество своего кода с точки зрения кого-то, кому придется читать его. Изучите используемые способы решения проблем. Изучите используемые способы исправления дефектов. Формулируя гипотезу, используйте все имеющиеся данные. Детализируйте тесты, приводящие к ошибке. Проверяйте код при помощи блочных тестов. Используйте разные инструменты. Воспроизведите ошибку несколькими способами. Генерируйте больше данных для формулирования большего числа г

Координаты: 1874 год; 0.15 кубика адреналина. Индекс удобочитаемости Флеша — 30, для бакалавров.

14 k

2023-07-22

Читать главу
К книге Страница автора

 Полезные конспекты книг и авторские заметки по информационным технологиям | Глава 7

Писатель: Лот Алексей Сергеевич

Входит в цикл: “Справочник”

Глава в томе: Полезные конспекты книг и авторские заметки по информационным технологиям I

Случайный абзац

| | Не требуют нарушения закона для своего применения. | Не могут быть применены без нарушения закона. | | Горячие | Холодные | | Не требуют предварительной подготовки материала для своего применения. | Требуют предварительной подготовки материала для своего применения. | | Конечные | Бесконечные | | Не требуют останова исследователем. | Не имеют ограничений по продолжительности анализа, поэтому требуют останова исследователем. | | Рекуррентные | Нерекуррентные | | Используют рекурсию. | Не используют рекурсию.

Координаты: 2225 год; 0.11 кубика адреналина. Индекс удобочитаемости Флеша — 1, для академиков.