Rapid Application Development (RAD) для сайтов

Дмитрий Сергеев, 13.02.2007 13:24

Когда узнаю побольше, напишу подробнее. Что передирать статьи из Википедии? :)

Скорее всего рассказ про RAD для веб-приложений должен быть тесно связан с обзором CASE-средств. И наверное в ближайшее время буду думать в этом направлении.

Если полный фид действительно нужен, то сделаю как-нибудь. Ссылку скажу.

Дмитрий Сергеев, 13.02.2007 18:06

Занятное решение, но мне кажется, работать не будет.

Группам сложно взаимодействовать между собой. При этом еще и проблемы информационного обмена внутри групп. Слишком много времени будет тратится на синхронизацию видения проекта.

Вообще, такая частая смена предмета труда вряд ли поможет. Лучше уж пусть группы меняются проектами раз в неделю.

При этом всем программистам придется думать сразу над двумя разными проектами. Не будет ли это в ущерб качеству?

Ну и, конечно же, коллективная ответственность. Вряд ли это хорошо.

Васильев Артем, 12.07.2007 14:03

Названы минусы, но у такого подхода есть и плюсы.
1. Программистам придеться писать код по стандартам и с коментариями, что повышает качество хотя и немного сказывается на времени.
2. Смена предмета труда может приносить новые идеи, или переносить идеи с одного проекта на другой, но тут нужен контроль, чтобы не заиграться.
3. Проблемы информационного обмена могут возникнуть только у очень крупных команд, и крупных проектах.

Дмитрий Сергеев, 12.07.2007 14:07

Согласен.

Вот еще минус придумал: у некоторых программистов наверняка появится любимый проект. И тогда полдня он будет вдохновенно работать, а еще полдня ждать следующего раза. Не получится ли так, что один из проектов будет делаться спустя рукава?..

Васильев Артем, 12.07.2007 14:17

Возможно любимые появятся, тогда пусть им занимается пока не надоест, рутины то не будет.
А если его оторвать на другой проект, то заня что чем быстрее он выполнит работу на новом проекте, тем быстрее он вернется к любимому, чем не мотивация?

Дмитрий Сергеев, 12.07.2007 14:49

Тут могут возникнуть проблемы с дисциплиной. Представь, ты говоришь людям: «Вот вам два проекта, работаете посменно. Если выберете любимый, можете не меняться». Программеры, чуть что, будут менять «любимый проект» и бегать туда-сюда. У них всегда будет лазейка: сделал плохо -- перешел в другой любимый проект.

Васильев Артем, 12.07.2007 15:00

А для того существует контроль качества, сделал плохо, переделай.

[Представь, ты говоришь людям: «Вот вам два проекта, работаете посменно. Если выберете любимый, можете не меняться».]

Если так сказать, то точно по вашему получится.
Это вопрос индивидуальный.

Дмитрий Сергеев, 12.07.2007 15:14

Может быть. Но мне кажется такие игры могут сильно отвлечь разработчиков от основных задач.

Дмитрий Сергеев, 13.02.2007 22:44

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

Дмитрий Сергеев, 13.02.2007 22:41

Если платят и не гоняют -- у разработчика нет нужды совершенствоваться. В результате скорее всего получится изделие посредственного качества.

Значит нужно гонять и не платить :)

Mr. Mishin Oleg, 14.02.2007 10:05

а вот уже тогда не видать вам хороших разработчиков на этом месте =)

Дмитрий Сергеев, 14.02.2007 10:46

Круг замкнулся.

Странно, что ситуации, когда все "хорошие", -- редкость. Как бы здорово было: дальновидный заказчик ценит профессионального разработчика и наоборот. Все честно делают, что должны. Эдем :)

Дмитрий Сергеев, 14.02.2007 10:55

Вот и мне кажется, что небольшие команды, в которых есть "чистые" кодеры, и есть те, кто много думают обо всём, очень конкурентоспособны.

Размышления -- самая трудная работа. Похоже, поэтому ею занимается так мало людей. (Генри Форд)

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

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

Kristy, 14.02.2007 18:54

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

Дмитрий Сергеев, 14.02.2007 20:13

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

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

Дмитрий Сергеев, 15.02.2007 11:37

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

Читал, как один маститый программист говорил о том, что реально удается эффективно работать часа два в день. А всё остальное время либо «разогреваешься», либо уже устал.

По себе знаю, бывает, пишешь что-нибудь -- чуть с ума не сходишь от того, сколько всего в голове нужно держать. А потом сны плохие снятся :)

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

Поэтому нужно стремиться к использованию разных генераторов приложений и готовых компонентов. А суровое программирование приберегать для особых случаев.

Mr. Mishin Oleg, 15.02.2007 12:11

Использовать чужие наработки можно только в том случае, если есть абсолютная уверенность в их работе (производительность, оптимальность, стабильность), но к сожалению даже среди распространенных библиотек классов много либо нестабильных либо избыточных библиотек... Использование таких ведет либо к увеличению потребляемых ресурсов, либо к нестабильности приложений.
Лично я нестабильность счетаю вообще недопустимой, а ресурсы - ну где-то это допустимо... В любом случае при использовании чужих наработак исполнитель должен разобраться в тонкостях работы левого пакета. Между прочим - кодеру иногда даже бывает проще написать подобный по примеру, чем использовать чужой код.
Но по хорошему - это все должен предусмотреть проектировщик. Ведь думать - это его задача =)

Кстати, 2 часа программирования в день про !кодера! - это очень мало. Для проектировщика - допустимо.

А про сны.... - согласен, случается =)

Дмитрий Сергеев, 15.02.2007 12:20

Есть еще и платные компоненты. Иногда к ним стоит присматриваться. Например, CodeCharge. Как-нибудь посмотрю демку.

У меня в хорошие дни получается качественно писать код часа четыре подряд.

Однажды приснился кошмар: я отлаживал форумный движок, а он всё не работал и не работал. Проснулся в холодном поту.

Дмитрий Сергеев, 13.03.2007 01:03

Мы, наверное, делаем разные сайты :) У меня в последнее время что ни проект -- так серьезная база данных, в которой полно связей "многие ко многим". Такие структуры сложно вписать в какую-нибудь CMS. И приходится выдумывать разные штуки.

С осени наметился сильный перекос в сторону проектирования. Какие-то вещи связаны с детальным изучением бизнес-процессов.

Сайты развиваются в общем эволюционно. Работа идет не столько над созданием, сколько над улучшением и развитием сайтов, повышением отдачи от них.

А на счет "Лего" вы правы. Вот захотел я себе блог, взял Drupal и настраиваю под себя. Правда этот тюнинг длится уже четвертый месяц и конца не видно. Эволюция :)

Кочанов Сергей, 13.03.2007 09:29

Свои проекты по идее и не должны никогда заканчиваться, а просто обязаны постоянно совершенствоваться. Что же касается сложных сайтов, то это смотря с какой стороны посмотреть. Реализация логики может быть и сложной, но в итоге задача сводится лишь к генерации данных для страницы и рендеринга ее из шаблона представления. Свойств у страницы не так много. Сильно упрощая, конечно, меняются только пара-тройка свойств. По сути, есть класс, генерирующий страницу. Для реализации ЛЮБОГО функционала необходимо лишь наследовать базовый класс и перекрыть функцию генерации страницы. При этом все сопутствующие базовые функции уже реализованы в родительском классе. В этом и преимущество ООП со всеми вытекающими. Какой бы сложной не была структура данных, базовые функции формирования страниц в 90% остаются неизменными (построение меню, хлебных крошек, набора информационных блоков и etc). Т.е. в моем случае построение страницы производится автоматом, необходимо лишь правильно организовать наборы данных.

Дмитрий Сергеев, 13.03.2007 09:47

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

Иногда нужно как-нибудь причудливо настроить вывод, иногда прикрутить к VML-дереву функциональность по управлению его структурой, иногда автозаполняющееся поле нужно необычное, иногда нужна генерация сложного облака тегов с агрегацией синонимов и заменой единственного числа употребляемых слов на множественное. Вот и получается, что «базовая» работа проходит незаметно, а запоминаются разные нетиповые новинки.

В этом и интерес. Разработчик развивается, постоянно учится. Если бы этого не было, сайтами бы занимались только роботы-сборщики.

Дмитрий Сергеев, 13.03.2007 13:17

Спасибо, почитаю. Выглядит многообещающе.

Согласен с вами по всем пунктам :) К счастью я делаю сайты не в промышленных масштабах, и мне не нужно совершенствовать процессы разработки только на основе уже имеющихся инструментов в ущерб обучению.

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

Сергей Кочанов, 13.03.2007 14:01

Альтернатива есть всегда. К тому же "кубики" тоже не пишутся "на века". Их периодически пересматривают, модифицируют и дорабатывают. И про это есть в вышеуказанной мною книге. Главное, разработать хороший интерфейс блока, чтобы его можно было безболезненно заменять при необходимости более функциональным и это не сказывалось на работе всей системы в целом. А делается это, как Вы правильно заметили, именно для:
1. Оптимизации процесса разработки.
2. Упрощения поддержки и дальнейшего развития продукта, когда его можно модернизировать поэтапно без изменения структуры всей программы и остановки ее работы.
Опять же хочу повториться. Это имеет смысл только для более-ли менее сложных проектов. В противном случае накладные расходы на проектирование становятся не рентабельными и не оправдывают себя.