АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция

FEATURE DRIVEN DEVELOPMENT

Читайте также:
  1. Biophysical features of an aorta.
  2. Biophysical features of arterioles of the big circle of blood circulation.
  3. Development of tractor advertisements
  4. Of a Certain Feature of a Thing or Phenomenon
  5. TOPIC 2: Morphological Features of the Noun as Part of Speech
  6. TOPIC 3: Morphological Features of the Verb as Part of speech
  7. Vocabulary development
  8. Визначення долі (призначення) закладених органів (developmental fate).
  9. Заняття № 20. Розвиток сучасної техніки в рамках концепції сталого розвитку. Engineering for Sustainable 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) Бездумное комментирование — большое количество лишних и неинформативных комментариев.

Решение: код должен сам себя пояснить.

 


1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |

Поиск по сайту:



Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.004 сек.)