 |
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция
FEATURE DRIVEN DEVELOPMENT
РАЗРАБОТКА, УПРАВЛЯЕМАЯ ФУНКЦИОНАЛЬНОСТЬЮ
Джеф Д. Люка и Питр Кодд — авторы методологии.
Упор делается на коротких итерациях, в результате каждой итерации разрабатывается часть системы, каждая итерация в среднем длится две недели.
Включает пять этапов:
в начале проекта:
1) Разработка общей модели;
2) Составление списка требуемых свойств системы;
3) Планирование работы над каждым свойством;
на каждой итерации:
4) Проектирование каждого свойства;
5) Реализация каждого свойства;
Каждый из этапов разбивается на задачи и имеет чёткий критерий верификации.
Все разработчики в соответствии с этой методологией делятся на два типа:
— Владельцы классов.
— Старшие программисты. Именно им поручается реализация каких-то свойств системы. Самостоятельно они ничего не делают, а определяют, анализируют в какие классы нужно внести изменения и выдают задания владельцам этих классов. Старший программист выступает в роли координатора команды владельцев классов.
Методология расписана в работе «UML in Color».
Итоги:
· Гибкие методологии целесообразно использовать, когда предполагается изменение требований проекта, вторая причина: когда требования неизвестны изначально чётко.
· Гибкие методологии предполагают небольшую команду программистов (например, Crystal использовался в командах до 50 человек).
· Гибкие методологии можно использовать тогда, когда есть команда разработчиков высокой квалификации.
· Заказчик должен быть готов участвовать в процессе разработки.
· Заказчик должен быть готов к гибкой стоимости проекта.
· Какую бы мы не выбрали гибкую методологию, она нам всё равно не подойдёт, её всё равно придётся адаптировать под нашу команду и под наш проект в процессе работы.
АНТИПАТТЕРНОЕ ПРОГРАММИРОВАНИЕ
Примеры неудачных проектных решений (примеров программирования):
1) Программирование копипастом.
Проблемы: ошибки, связанные с недомодифицированостью программного кода.
Решение: ни один фрагмент кода не должен присутствовать в коде дважды.
2) Спагетти-код — использование goto, неструктурированная система.
Причины: лень, недостаток опыта в разработке, неэффективные code review, удалённая работа большого количества программистов.
3) «Золотой молоток» — мы изучали какой-то один приём, и начинаем его применять везде, к месту, не к месту, просто потому, что он нам нравится.
4) Магические числа — в программном коде иногда попадаются непонятные числа, которые никак не документированы.
Пример: z = x + y + 3. Откуда взялась тройка?
Борьба: все числа присваивать переменным с говорящими именами.
Причина: спешка при разработке, низкая квалификация.
5) Жёсткое кодирование — в программный код внедряются данные о окружении программы (например, задание пути к файлу).
6) Мягкое кодирование — следствие параноидальной болезни жёсткого кодирования, в программе настраивается абсолютно всё. Излишние усложняется конфигурирование программ.
7) Избыточная сложность.
Причина: отсутствие code review.
8) Лодочный якорь. «Чемодан без ручки». В проекте сохранятся куски кода, которые стали ненужными после оптимизации или рефакторинга.
9) Изобретение велосипеда.
10) Изобретение одноколёсного велосипеда (с квадратными колёсами) — реализация своего плохого решения, когда есть хорошие аналоги.
11) Поток лавы — на каком-либо этапе разработки вы можете осознать, что некоторая часть кода очень давно не менялась и вообще недокументирована, или такому коду сопутствует комментарий вида "// Не знаю, как оно работает, но оно работает.
Причины: написание больших частей проекта одним программистом, отсутствие code review, ошибки в проектировании архитектуры.
12) Программирование перебором — применение костылей, чтобы программа заработала здесь и сейчас.
13) Слепая вера — недостаточная проверка корректности входных данных, исправления ошибки или результатов работы кода.
Решение: всегда проверяйте корректность входных данных.
14) Бездумное комментирование — большое количество лишних и неинформативных комментариев.
Решение: код должен сам себя пояснить.
Поиск по сайту: