Подход к проектированию и реализации в программировании

[Hector]

Не совсем спец в проектировании сложных сайтов. Возникли вопросы такого характера. Вот например задача сделать сайт с форумом.

Что нужно использовать? Фреймворки, CMS, или Самопис? Когда лучше взять готовый движок форума а когда писать с нуля? Всегда ли программист который говорит что писать с нуля лучше подготовлен чем тот что строит сайт на Друпал.

Как определять эти грани? Понятно что нужно подходить исходя из задачи, но если можно вкрутить уже готовый движок форума, зачем писать его с нуля и ловить глюки?

[Matro]

Сообщение от digg

самопис либо под какие-то хитровыебанные модули, либо под что-то чего еще нет в природе

по поводу шелов согласен, надо еще потом по всяким листам скуэл инжекшен тестить надо чужой двиг

Самопис - это даже большая куча нечеканых уязвимостей. Надежда лишь на то что этот сайт никому не понадобится/не попадет под раздачу поиском по гуглю.
А если на фреймворке, то у них своих багов миллион, и их самое смешное обычно их-то уже ни кто не обновляет, а они так же публичны фактически.

[Athos]

Есть опыт работы с еб_утым заказчиком
Работа велась на друпале и когда было готово 90% проекта и дэдлайн был очень близко резко поменялось ТЗ. А так как заказчик "крупнейшее и авторитетнейшее предприятия и там тоже не дураки работают" отказ от проекта не принимался... В общем если бы не over100500 модулей в срок я бы не успел.

[Saymon]

Мы работаем так:
1) Определяем и описываем функционал приложения
2) Определяем набор сущностей и объектов системы, которым предстоит взаимодействовать

Далее идет работа в UML (как среда у нас используется Visual Paradigm for UML Enterprise Edition версии 8.0)

3) Проектируем структуру базы данных. Отсутствие данного этапа или ошибка на нем, как правило приводит к немасштабируемости проекта, или как минимум создает оооочень много проблем.., и в итоге приходишь к тому, что надо менять структуру, а прожект уже в лайве = гемор
3) рисуем диаграммы классов. ORM, и модели не относящиеся к работе с БД
4) создаем список всех возможных сценариев приложения (все возможные последовательности действий различных пользователей с различными ролями в различных ситуациях).
5) рисуем диаграммы прецедентов, там где необходимо внятные sequence диаграммы. Это идет с одновременной корректировкой диаграмм классов, т.к. как раз на этом этапе удобнее всего распределить обязанности объектов (каким классам какие методы назначить)

Если проект подразумевает одновременное использование группой лиц с одновременным доступом к каким-то объектам в бд, то есть смысл сразу применить TDD.

Часто не лишним является вспомнить, что существует scrum и что это гибкая методология, которую можно подстроить под команду и ситуацию. Просто некоторые начинают подстраиваться под методологию в том виде в котором она описана в википедии, что не есть правильно))) на эту тему есть ряд трактатов о культе карго в этой теме... вот тут главное подойти с умом и не переборщить.

что дает такой подход:

1) вначале делается проект и потом только кодируется. так и должно в идеале быть, а не запили, а потом "блеааать!! что теперь с этим делать??! сука, мы не учли то и сё.. блеать!.."
2) TDD - помогает свести кол-во багов к минимуму и о глючности начинаешь забывать
3) фаза проектирования приложения становится как правило дольше фазы кодирования, однако это позволяет:

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

Это и есть один из основных плюсов документированного в UML проекта. Разработчикам не надо знать сути проекта, достаточно видеть диаграмму чтобы просто написать какой-то метод. В приложении к примеру 3000 методов. Сели 30 индусов и каждый за 3-4 дня наваял по 100 методов. Ни кто не откурил при этом сути проекта, но появился код, реализованный согласно документации, который можно прогнать Unit-тестами, подправить и запустить. Это так же акуенный плюс, когда есть идея, но страшно отдать на разработку дабы не спиздили.
Это был ответ по сабжу топика.
Именно форум самому писать это имхо лишнее. Есть куча движков, стабильных, внятных, очевидных в использовании и настройке.
А вот если есть кастомная бизнеслогика - тут только свое делать. Допиливание друпала или чего-то другого, как правило, приводит к тяжести проекта и к его закономерному тупику. Это в корне отличается от самостоятельно спроектированной системы, проектируя которую, ты сам заложился под 100500 всяких ситуаций на случай масштабирования... тогда и дальнейший сапорт и развитие продукта становятся и быстрее и дешевле.
Как-то так. Это если более-менее по-взрослому если совсем по-взрослому то все еще круче), но то скорее уже при разработке коробочного или под клиента, а для кодирования под себя такого подхода как правило с головой хватает.

[chesser]

Saymon, в целом +1, интересный пост.

1) стандартный use case UML: сначала рисуется концептуальные модели, потом уже делают детализацию. По идее рисовать ORM в самом начале это неправильно, или нет? И вряд ли это сильно зависит от проекта
2) сколько человек работает с VP и какие у них роли?
3) какой язык программирования используйте?
4) пробовали применять на практике round-trip инжиниринг в VP
5) что происходит, когда выкатили релиз, но нужно изменить бизнес-логику? модель приводите в соответствие?

Допиливание друпала или чего-то другого, как правило, приводит к тяжести проекта и к его закономерному тупику.

если это категоричное высказывание, то несоглашусь. Друпал очень гибок и по сути является фреймворком для быстрого создания сайта по имеющейся бизнес-логике. Зачастую этого уровня абстракции хватает: 1) для быстрой разработки 2) для избавления себя от реализации мелкого "сайтового" функционала, который не реализуется на стандартный MVC-фреймворках.

А если проект подразумевает действительно кастомную бизнес-логику, то спору нет, фрейморки тут без вариантов.

Я немного использую VP, но кодогенерацией пока пользуюсь только для БД. В основном описываю в нем бизнес-логику: UCD, CD и SD. Хочу попробовать round-trip, но для этого надо перейти на Java.
А для сайтов-порталов друпал самое оно, имхо.

[chesser]

Сообщение от chesser

UCD, CD и SD

неправильно написал, вместо SD надо AD, т.е. диаграмма деятельности.
В AD удобнее описываться общую логику бизнес-процессов и поведение объектов.

[Saymon]

Сообщение от chesser

Saymon, в целом +1, интересный пост.

1) стандартный use case UML: сначала рисуется концептуальные модели, потом уже делают детализацию. По идее рисовать ORM в самом начале это неправильно, или нет? И вряд ли это сильно зависит от проекта
2) сколько человек работает с VP и какие у них роли?
3) какой язык программирования используйте?
4) пробовали применять на практике round-trip инжиниринг в VP
5) что происходит, когда выкатили релиз, но нужно изменить бизнес-логику? модель приводите в соответствие?

1) chesser, конечно же ORM это не первое. Сорри, я не осветил этот момент. У нас это происходит на 1,2 пунктах моего поста. К их окончанию уже достаточно концептуальности. Юзаем обычную доску и маркеры.
2) 3 человека. Роли не закрепляем, все динамически по ходу пьесы. Да, команда у нас не большая, но в своей весовой категории достаточно эффективная за счет высокой степени повторного использования кода. Как только какой-то функционал подозревается в возможной применимости в другом проекте, он сразу же выносится в отдельную компоненту, которая ессно не должна знать о том где её применяют. Т.е. высокий уровень модульности и универсальности. Соответственно 50% работы часто делать просто не нужно, т.к. она уже готова. А так мы все и архитекторы и кодеры. Все рисуют, проектируют, клепают скетчи, кодируют...
3) PHP
4) Нет, но было бы круто. Вот у нас есть своё ядро. Все проекты мы делаем на ZendFramework. Вот это ядро - есть набор универсальных компонент (подключаемых модулей), список которых аккуратно пополняется, а старые допиливаются и рефакторятся по мере необходимости. Так вот изначально документации не было, и когда это стало уже критично мы сделали reverse и получили её. Теперь работаем только forward, а round-trip ручками. Херня конечно... честно - пока просто не разобрались с инструментами для этого. Хотя по воспоминаниям как проходил реверс - что-то мне там не понравилось, больно много херни нагенерило) Надо выделить время, разобраться и возможно недоверие к инструменту пройдет
5) У нас в ядре своя система апдэйта. Происходит это так: svn update на сервере и далее updateAction(), там уже применяется для версии необходимые изменения в БД и файловой системе. Если же надо изменить - меняем и апдэйтим. Версия инкрементируется.

На счет друпала - нет, не категоричное вовсе. Я именно имел ввиду бредовость ситуаций когда жесткую кастомность начинают накручивать на друпал, вордпресс или джумлу только потому что или нет знаний сделать правильно или бабла не хватает. Видели такое и видели исход. Конечно если это просто CMS то нафига делать велосипед? Тут и друпал и вп подойдет. Вообще на вкус и цвет все фломастеры разные Я говорил ТОЛЬКО о реально кастомных случаях.

[Saymon]

Сообщение от Matro

А если на фреймворке, то у них своих багов миллион, и их самое смешное обычно их-то уже ни кто не обновляет, а они так же публичны фактически.

Ну хз хз.., у Zend например достаточно живое комьюнити, Simfony тоже живет и дохнуть вроде как не собирается, Ruby тоже...

Сообщение от Matro

Самопис - это даже большая куча нечеканых уязвимостей

А уязвимости дело такое.. если ты знаешь как защищаться от хsrf, xss и т.п., то, имхо, реализуй защиты сам. От скл инъекций зенд защищен в нативной поставке, защита от хсрф у нас, например, реализована в базовом классе формы который наследуется от Zend_Form а далее от него уже все остальные.. ну и т.д. и с xss и прочими..
Фреймворк это набор библиотек, а не готовое решение, хотя много чего в них уже готово. А дальше все от разработчика зависит.... На нашем ядре на Zend Framework работает пара шопов в US с реально охуенными нагрузками и оборотами бабла. Все окей, McAfee SECURE™ trustmark в наличии, инцидентов пока не было.
На уязвимости надо чекать. JBroFuzz, например, он не только уязвимости чекает а вообще фаззинг делает. Есть и статические анализаторы кода типа RATS, покажет потенциальные уязвимости в коде.. все упирается в знание инструментов и технологий и умение ими пользоваться

[chesser]

Сообщение от Saymon

5) У нас в ядре своя система апдэйта. Происходит это так: svn update на сервере и далее updateAction(), там уже применяется для версии необходимые изменения в БД и файловой системе. Если же надо изменить - меняем и апдэйтим. Версия инкрементируется.

про апдейт кода или БД - это понятно, интересует именно апдейт UML-модели. Т.е. поддерживаете ли вы ее актуальность внутри VP: руками или автоматически - это не важно.
Но в VP это можно делать автоматически. Я сам не пробовал, но судя по описаниям оно работает. Т.е. изменения в модели отображаются в коде и наоборот. Когда я начинал изучать UML в 2003 году таких средств еще не было. Раньше были только прямая и обратная генерация кода, теперь вот реализовали сопровождение и это круто. Только работает не на всех языках, java нужна или C++.
Т.е. в идеале высококвалифицированный проектировщик разрабатывает проект, потом дешевые кодеры кодят методы. Если модель(бизнес-логика) меняется, проектировщик делает рефакторинг свой ранее сделанной модели и применяет изменения к уже написанному коду. Кодеры видят места, которые нужно переписать/дописать и выполняют свою работу. (Раньше при форвард-инжениринге генерился только пустой каркас, т.е. старые уже написанные методы стирались)

А кстати, как вы решили проблему db-migration + VCS ? или зенд-фреймворк это поддерживает из коробки?
я не могу использовать фреймворки в виду лицензионной политики софта с которым работаем, а как по-человечески коммитить SQL изменения я так и не нашел способа. http://chesser.ru/blog/how_to_commit_db_changes/ - попробовал так, но не особо удобно анализировать sql-дифы. Интересует решение без коннекта к БД.

[Saymon]

Сообщение от chesser

интересует именно апдейт UML-модели. Т.е. поддерживаете ли вы ее актуальность внутри VP: руками или автоматически - это не важно.

Конечно поддерживаем. Пока что руками.

Сообщение от chesser

Но в VP это можно делать автоматически. Я сам не пробовал, но судя по описаниям оно работает.

Да, инструментарий есть, и вроде как с PHP там все хорошо, но у нас именно другие сложности. А конкретно хитрая иерархия хранения PHP моделей, т.е. сама структура папок/файлов. У нас она даже не нативная как в Zend_Framework где все модели в одной папке, контроллеры тоже все рядом тусят. У нас покомпонентно все и в каждой компоненте свои контроллеры, а модели ваще хитро разложены. И вот тут чтобы надрочить парадигму хавать это всё и работать корректно с нашей структурой надо потратить время. Его пока просто не нашли, но планируем. Ибо поддержка актуальности вручную в итоге по времени дороже встает.

Сообщение от chesser

Т.е. в идеале высококвалифицированный проектировщик разрабатывает проект, потом дешевые кодеры кодят методы. Если модель(бизнес-логика) меняется, проектировщик делает рефакторинг свой ранее сделанной модели и применяет изменения к уже написанному коду. Кодеры видят места, которые нужно переписать/дописать и выполняют свою работу.

Именно так в идеале и должно быть. А высококвалифицированный проектировщик зовется обычно архитектором

Сообщение от chesser

А кстати, как вы решили проблему db-migration + VCS ? или зенд-фреймворк это поддерживает из коробки?

1) есть такая штука как phing. тогда все сводится по сути к svn update и сразу phing update
2) в Zend - нет, НО (!) в доктрине есть свои механизмы. Почти тоже самое что и в phing. Версионная миграция, но есть еще и diff миграция, которая сравнивает схемы моделей и генерит разницу. Это вроде делает вторая доктрина. У коллег есть опыт использования сам не пробовал. На сайте доктрины валяется стандалоновский phar. Ему надо только конфиги скормить и можешь натравить его на свои схемы
3) есть еще db-deploy
4) у нас это не есть проблема и мы юзаем пока что свой механизм. если есть интерес могу рассказать подробно в личке, врядли это будет кому-то в паблике интересно...

[Matro]

Сообщение от Saymon

Ну хз хз.., у Zend например достаточно живое комьюнити, Simfony тоже живет и дохнуть вроде как не собирается, Ruby тоже...

Да не, речь не о смерти их как таковой, обновления-то идут, но в данном случае этого мало...
Обновление-то не происходит самостоятельно. Для начала нужно иметь желание переделывать работающий проект, с заменой каких-то частей. Обычно "пока работает" - мало кому трогать охота-то.

Сообщение от Saymon

все упирается в знание инструментов и технологий и умение ими пользоваться

И кроме того, нужно желание и наличие денег у заказчика оплачивать переработку/апдатирование до очередной версии фреймворка каждого из его многих проектов.
Ну потратят денег и найдут дырки, потом надо искать того, кто делал этот проект, чтобы платить еще бабок на исправление. В мире масса проектов которые живут только потому что не тратят деньги "по-пусту", на подобную постоянную переработку. И вот в них-то эти всплывшие дыры использованного когда-то фреймворка остаются навечно. А какие там только McAfee SECURE™ не висят, вешали-то когда пускали...

Этим стандартные двиги лучше - у них сам апдейт автоматом, нажал кнопу и готово. Если бы каждый из вп-овнеров платил за пределку кода для апдейта, заняты были бы все 1.5млрд индусов.

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