http://habrahabr.ru/post/188604/
Поверьте - никого не хочется "уговаривать". Но хочется всё же - "донести мысль". Тем более, что она кажется перспективной. И она - так или иначе - опробована на практике.
Поверьте - никого не хочется "уговаривать". Но хочется всё же - "донести мысль". Тем более, что она кажется перспективной. И она - так или иначе - опробована на практике.
Основные претензии, которые я увидел, такие:
1. У вас неправильно организован процесс.
2. У вас недостаточно выразительный язык.
3. UML - мешает полёту мысли.
4. Неудобные инструменты.
Для начала хочется сказать - ужасно неприятно полемизировать с людьми скрытыми за "никами" и анонимностью.
Значит по поводу процесса. А кто-нибудь может ответить на вопросы:
1. Вы писали проекты сравнимые хотя бы с Word?
2. Сколько в них разнородных сущностей?3. Сколько ответственностей в среднем на сущность?
4. Сколько UseCase'ов верхнего уровня в системе?
5. Каков объём требований?
6. Сколько экранных форм?
7. Сколько людей в среднем в проекте?
8. В скольких проектах используются одни и те же проектные и компонентные решения?
9. Сколько строк кода попадает в среднем в день в систему контроля версий?
10. Сколько аспектов "пронизывают" ваши приложения?
По поводу выразительности:
1. Рефакторинг. В "квадратиках" - проще.
2. Конструктивизм - возможность создания "крупных" конструкций из более "мелких" кубиков. С возможностью статической подстановки типов и определения статической арности связей.
3. Шаблонные решения. Нарисовать что-нибудь типа "фабричный метод" - однозначно проще, чем закодировать. Другие сложные шаблонные решения - тем более.
4. Тестовый проект, тестирующий GUI, из обычного проекта делается просто. Гораздо проще, чем "в коде".
5. Возможность генерации дополнительных сущностей. Например контрольных точек или обвязки для тестирования.
6. Возможность генерации инфраструктуры проекта. Например поддержки ночных сборок. Или прочих cmd-файлов или make-скриптов.
7. Наглядная трассировка требований в код и обратно.
8. Как одно из "шаблонных решений". Но стоит выделения "отдельной строкой". MVC-подобные решения - проще и правильнее воспринимаются на модели, а не в "голом" коде.
9. Форматы документов удобнее и правильнее описывать на модели (или другом мета-языке) нежели чем в императивном коде.
4. Тестовый проект, тестирующий GUI, из обычного проекта делается просто. Гораздо проще, чем "в коде".
5. Возможность генерации дополнительных сущностей. Например контрольных точек или обвязки для тестирования.
6. Возможность генерации инфраструктуры проекта. Например поддержки ночных сборок. Или прочих cmd-файлов или make-скриптов.
7. Наглядная трассировка требований в код и обратно.
8. Как одно из "шаблонных решений". Но стоит выделения "отдельной строкой". MVC-подобные решения - проще и правильнее воспринимаются на модели, а не в "голом" коде.
9. Форматы документов удобнее и правильнее описывать на модели (или другом мета-языке) нежели чем в императивном коде.
По поводу "мешает":
1. За себя лично - Я СЧАСТЛИВ, что модель ограничивает "поток сознания".
2. За других скажу - кому "мешает" - это он либо из "вредности" (чисто заради абсолютного обсуждения свободы), либо - от недостатка информации. В том-то и дело, что если что-то "мешает" - всегда можно настроить. Главное - ОСОЗНАВАТЬ - "что" и "зачем". А "абсолютная" свобода выражения "потока сознания" в код - если не "зло", то уж точно - неудобство. При достаточно большом количестве участников. По-любому возникают всякие "инструкции программирования" и прочие Development case.
to be continued...
>>Основные претензии, которые я увидел, такие:
ОтветитьУдалитьэто ты где разглядел? ))
В комментариях
Удалить