Неинтересная работа утомляет. Создание сайта, длящееся месяцами, превращается в рутину. Эффективность труда разработчиков значительно снижается. Поэтому сайт должен делаться быстро.
Я бы сказал, что добротный средний сайт должен создаваться за пару месяцев.
Главная проблема продолжительных проектов — усталость разработчиков. Другая причина избегать длительных сроков — возможность значительных изменений требований к системе «в процессе».
Rapid application development (RAD) — методология разработки программного обеспечения с высокой частотой цикличности, подразумевающая обильное создание прототипов и применение CASE-средств. При этом функциональность приносится в ущерб времени разработки, необходимости постоянно выпускать работающие версии.
При интенсивной разработке повышаются требования к планированию. Особенно важной задачей становится расстановка приоритетов. Умение отделить ключевую функциональность от забавных фич — ключ к успеху RAD.
В английской Википедии можно узнать о RAD побольше.
Мои знания о RAD, к сожалению, не слишком глубоки, поэтому в ближайшее время собираюсь почитать книгу «Rapid Application Development» Джеймса Мартина (James Martin).
Дмитрий Сергеев, 26 лет, разрабатываю сайты на Drupal, управляю интернет-проектами
Комментарии
Brokenbrake, 13.02.2007 12:53
Статья хорошая... была бы, напиши ты ее подробнее :) А вообще, суть ясна. Мне неинтересно становится иногда с самого начала почему-то, потому что многие действия все равно приходится повторять (то есть вообще в жизни они далеко не впервые). Так что стараюсь браться только за мелкие работы типа сайта-визитки или блога какого-нибудь.
P.S. Ты не мог бы фид отдавать полностью?
Дмитрий Сергеев, 13.02.2007 13:24
Когда узнаю побольше, напишу подробнее. Что передирать статьи из Википедии? :)
Скорее всего рассказ про RAD для веб-приложений должен быть тесно связан с обзором CASE-средств. И наверное в ближайшее время буду думать в этом направлении.
Если полный фид действительно нужен, то сделаю как-нибудь. Ссылку скажу.
Dead Krolik, 13.02.2007 17:56
А не позволит ли посменная работа над сайтом (ну например одна группа пол дня делает один сайт, а вторая другой, после обеда меняются) - решить вопрос усталости программистов. Меняются задачи, разнообразие появляется.
Дмитрий Сергеев, 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 20:58
На самом деле один-два человека могут делать сложный сайт и полгода, и год. А как сделать, чтобы они "не заскучали" через месяц -- вопрос мотивационных механизмов, ответ на который должен знать менеджер проекта.
Но не спорю, приятно, когда сайт растет на глазах и готов уже через месяц :)
Дмитрий Сергеев, 13.02.2007 22:44
Кстати, мотивировать разработчиков -- большое искусство. Особенно когда денежный вопрос не стоит слишком остро, и они ищут "чего-то большего".
Dead Krolik, 13.02.2007 22:07
Прикол как раз не в рутине, а в оплате. Тут еще аспект всплывает - если платят, и в принципе не гоняют - а зачем торопиться. Чем дольше, тем физически более продолжительный период времени человек будет получать деньги.
Кроме того все зависит от того как человек получает деньги. Фрилансер или стабильная работа. Если фрилансер, то да - надо крутиться. Если стабильно - то собственно стоит срок, стоит задача, делай себе помаленьку. Если зарплата устраивает - значит все гут.
Дмитрий Сергеев, 13.02.2007 22:41
Если платят и не гоняют -- у разработчика нет нужды совершенствоваться. В результате скорее всего получится изделие посредственного качества.
Значит нужно гонять и не платить :)
Mr. Mishin Oleg, 14.02.2007 10:05
а вот уже тогда не видать вам хороших разработчиков на этом месте =)
Дмитрий Сергеев, 14.02.2007 10:46
Круг замкнулся.
Странно, что ситуации, когда все "хорошие", -- редкость. Как бы здорово было: дальновидный заказчик ценит профессионального разработчика и наоборот. Все честно делают, что должны. Эдем :)
Юрий Гугнин, 14.02.2007 10:45
Я работал в IT-компаниях около пяти лет и сделал вывод, что скорость реализации проекта, как правило, обратно пропорциональна количеству кодеров, работающих над ним. Оптимальное количество — двое-трое (если это, конечно, не биллинговая система какая-нибудь, хотя там обычно хватает пятерых). Тем более, что сайт это не настолько огромная задача для профессионального кодера. Обычно применяются обкатанные на ранних этапах решения, постепенно накапливаются свои библиотеки итд.
Другой вопрос: кодеры только кодят или занимаются еще и архитектурой, и менеджментом? Если только кодят — тогда точно двое-трое быстро сладят. А вот если это случай маленькой компании, где каждый и жнец и на дуде игрец, то тут уже может быть засада...
Всем хорошего настроения 8)
Дмитрий Сергеев, 14.02.2007 10:55
Вот и мне кажется, что небольшие команды, в которых есть "чистые" кодеры, и есть те, кто много думают обо всём, очень конкурентоспособны.
Размышления -- самая трудная работа. Похоже, поэтому ею занимается так мало людей. (Генри Форд)
Кодеры -- это производители. Плохо, когда они вынуждены думать о крайне разнородных аспектах проекта и отвлекаться от своего основного занятия.
Кто-то должен много думать, кто-то заниматься миллионом мелких вопросов, а кто-то писать код. При этом все они делают сайт. Получается дружно и весело :)
Kristy, 14.02.2007 18:54
да, мне тоже кажется, что при росте количества программистов производительность резко падает.
Дмитрий Сергеев, 14.02.2007 20:13
Вряд ли резко падает. Просто повышаются затраты на обеспечение информационного обмена между ними, синхронизацию знаний по проекту.
С другой стороны размер команды должен соответствовать масштабу проекта. Поскольку большинство сайтов -- небольшие приложения, программистов обычно нужно немного.
Mr. Mishin Oleg, 15.02.2007 10:26
Скорость работы большо команды все равно растет, нодинамика роска остается обратнопропорциональна количеству программистов и прямопропорциональна грамотности управления ими (читай - синхронизации рабочих данных).
Здесь еще играет роль такой фактор как "время погружения". Кто занимался программированием - знает что в памяти приходися держать огромные объемы данных. Именно поэтому програмистов не рекумендуется пееркидывать с проекта на проект впринципе. Пару лет назад буржуи проводили исследование, и был составлен график на основе большого количества наблюдаемых программистов в разных областях: в сренем программист достигает пика своей производительности через 3 часа после перерыва в работе.
Если по русски: приш8ел ты на работу в 9 часов, а толко в 12 ты работаешь с максимальной производительностью. в 13 - обед. В 13:30 проолжаешь работать. В 15 ты начал набирать свою скорость, но пошел курить и скорость опять упала...
Всем знакома ситуация когда програмист работает ночью? Именно потому что когда его не отрывают по пустякам (заправить принтер, покурить, всякие приколы по аське...) - производительность намного выше.
То есть скорость зависит от менеджмента, грамотного построения рабочего времени, слаженности команды. При идеальных условиях этих параметров скорость падать не будет.
Дмитрий Сергеев, 15.02.2007 11:37
Если программист пишет сложный код, а не занимается подкручиванием гаек, то устает он достаточно быстро. При этом если отвлечется на несколько дней, значительное время может потратить на восстановление образа в памяти.
Читал, как один маститый программист говорил о том, что реально удается эффективно работать часа два в день. А всё остальное время либо «разогреваешься», либо уже устал.
По себе знаю, бывает, пишешь что-нибудь -- чуть с ума не сходишь от того, сколько всего в голове нужно держать. А потом сны плохие снятся :)
Так уж получилось, что люди -- не роботы, продолжительное время сложными вещами заниматься не могут. Нужен и отдых, и отвлечение. Сложно найти баланс.
Поэтому нужно стремиться к использованию разных генераторов приложений и готовых компонентов. А суровое программирование приберегать для особых случаев.
Mr. Mishin Oleg, 15.02.2007 12:11
Использовать чужие наработки можно только в том случае, если есть абсолютная уверенность в их работе (производительность, оптимальность, стабильность), но к сожалению даже среди распространенных библиотек классов много либо нестабильных либо избыточных библиотек... Использование таких ведет либо к увеличению потребляемых ресурсов, либо к нестабильности приложений.
Лично я нестабильность счетаю вообще недопустимой, а ресурсы - ну где-то это допустимо... В любом случае при использовании чужих наработак исполнитель должен разобраться в тонкостях работы левого пакета. Между прочим - кодеру иногда даже бывает проще написать подобный по примеру, чем использовать чужой код.
Но по хорошему - это все должен предусмотреть проектировщик. Ведь думать - это его задача =)
Кстати, 2 часа программирования в день про !кодера! - это очень мало. Для проектировщика - допустимо.
А про сны.... - согласен, случается =)
Дмитрий Сергеев, 15.02.2007 12:20
Есть еще и платные компоненты. Иногда к ним стоит присматриваться. Например, CodeCharge. Как-нибудь посмотрю демку.
У меня в хорошие дни получается качественно писать код часа четыре подряд.
Однажды приснился кошмар: я отлаживал форумный движок, а он всё не работал и не работал. Проснулся в холодном поту.
Вячеслав, 27.12.2008 15:15
"А потом сны плохие снятся :)"
Особенно когда ложишься под утро. Я думал это только мой баг :)
Кочанов Сергей, 12.03.2007 23:29
Млин, ребята, читаю я вас и складывается впечатление, что вы каждый сайт с нуля начинаете писать. Вы в каком веке живете? 95% сайтов по функционалу похожи как близнецы. Я сайтами начал заниматься лет 5 назад. Сначала появился класс доступа к данным, который использовался в каждом проекте. Позже появилось еще куча всяких классов и модулей. Теперь в 80% случаев программирование заключается в игру с конструктором "Лего". Больше времени уходит на верстку и написание шаблонов представления. Когда есть уже куча модулей, которые и составляют движок сайта, программистов можно разделить на системщиков и прикладников. Первые пишут недостающие модули, вторые ими пользуются. Вот и не будут уставать люди, потому что больше 3-5 дней над одной задачей не работают. А сайт делкется по такому принципу за 3-4 дня, в зависимости от сложности верстки (при условии, что дизайн уже отрисован).
Дмитрий Сергеев, 13.03.2007 01:03
Мы, наверное, делаем разные сайты :) У меня в последнее время что ни проект -- так серьезная база данных, в которой полно связей "многие ко многим". Такие структуры сложно вписать в какую-нибудь CMS. И приходится выдумывать разные штуки.
С осени наметился сильный перекос в сторону проектирования. Какие-то вещи связаны с детальным изучением бизнес-процессов.
Сайты развиваются в общем эволюционно. Работа идет не столько над созданием, сколько над улучшением и развитием сайтов, повышением отдачи от них.
А на счет "Лего" вы правы. Вот захотел я себе блог, взял Drupal и настраиваю под себя. Правда этот тюнинг длится уже четвертый месяц и конца не видно. Эволюция :)
Кочанов Сергей, 13.03.2007 09:29
Свои проекты по идее и не должны никогда заканчиваться, а просто обязаны постоянно совершенствоваться. Что же касается сложных сайтов, то это смотря с какой стороны посмотреть. Реализация логики может быть и сложной, но в итоге задача сводится лишь к генерации данных для страницы и рендеринга ее из шаблона представления. Свойств у страницы не так много. Сильно упрощая, конечно, меняются только пара-тройка свойств. По сути, есть класс, генерирующий страницу. Для реализации ЛЮБОГО функционала необходимо лишь наследовать базовый класс и перекрыть функцию генерации страницы. При этом все сопутствующие базовые функции уже реализованы в родительском классе. В этом и преимущество ООП со всеми вытекающими. Какой бы сложной не была структура данных, базовые функции формирования страниц в 90% остаются неизменными (построение меню, хлебных крошек, набора информационных блоков и etc). Т.е. в моем случае построение страницы производится автоматом, необходимо лишь правильно организовать наборы данных.
Дмитрий Сергеев, 13.03.2007 09:47
Даже притом, что базовые методы уже давно написаны, постоянно появляется что-то новое.
Иногда нужно как-нибудь причудливо настроить вывод, иногда прикрутить к VML-дереву функциональность по управлению его структурой, иногда автозаполняющееся поле нужно необычное, иногда нужна генерация сложного облака тегов с агрегацией синонимов и заменой единственного числа употребляемых слов на множественное. Вот и получается, что «базовая» работа проходит незаметно, а запоминаются разные нетиповые новинки.
В этом и интерес. Разработчик развивается, постоянно учится. Если бы этого не было, сайтами бы занимались только роботы-сборщики.
Сергей Кочанов, 13.03.2007 12:04
В любом случае придется разделять тех, кто "играет в кубики" и тех, кто эти кубики "создает". Ибо квалификация разная нужна и совмещать ее нецелесообразно. Предвкушаю Ваше возражение на данный счет по поводу того, что системы, порой, бывают очень сложные. Но это не отменяет сию концепцию. В любом случае любой, даже самый сложный проект, можно разбить на составные блоки - те самые кубики, как и сколь угодно сложную функцию на конечное число элементарных функций (с известной долей приближения есс-но). Блоки эти со временем накапливаются и существуют уже практически на 90% случаев из жизни. Не зря ведь люди придумали ООП и повторное использование кода. На сему вопросу ОЧЕНЬ рекомендую прочесть книжечку http://www.books.ru/shop/books/25950. Как раз она очень полезна при разработке сложных систем.
Дмитрий Сергеев, 13.03.2007 13:17
Спасибо, почитаю. Выглядит многообещающе.
Согласен с вами по всем пунктам :) К счастью я делаю сайты не в промышленных масштабах, и мне не нужно совершенствовать процессы разработки только на основе уже имеющихся инструментов в ущерб обучению.
Пусть я буду не так эффективен, зато будет много альтернативных способов решения одной и той же задачи.
Сергей Кочанов, 13.03.2007 14:01
Альтернатива есть всегда. К тому же "кубики" тоже не пишутся "на века". Их периодически пересматривают, модифицируют и дорабатывают. И про это есть в вышеуказанной мною книге. Главное, разработать хороший интерфейс блока, чтобы его можно было безболезненно заменять при необходимости более функциональным и это не сказывалось на работе всей системы в целом. А делается это, как Вы правильно заметили, именно для:
1. Оптимизации процесса разработки.
2. Упрощения поддержки и дальнейшего развития продукта, когда его можно модернизировать поэтапно без изменения структуры всей программы и остановки ее работы.
Опять же хочу повториться. Это имеет смысл только для более-ли менее сложных проектов. В противном случае накладные расходы на проектирование становятся не рентабельными и не оправдывают себя.