Комментарии 60
> В то же время стоит работать с относительно бОльшим числом СУБД.
Сколько времени работаю, кроме MySQL\sqllite пока что к сожалению ничего больше не требовалось.
Сколько времени работаю, кроме MySQL\sqllite пока что к сожалению ничего больше не требовалось.
ps за статью спасибо, поставил плюс ;)
спасибо, на самом деле действительно часто для веб-проектов и у нас MySQL. Но на относительно больших, самостоятельных (не CMS) проектах, стараемся склонить заказчика к другому выбору. В результате достаточно активно используем и PostgreSQL и даже Firebird. В прошлом занимались также поддержкой проекта на Oracle. Просто освоение новой СУБД по сравнению с освоением, например, новго фреймворка, «стоит» на несколько порядков дешевле, а кругозор (и резюме) расширяет существенно.
Вы склоняете заказчиков к использованию PostgreSQL вместо MySql ради «резюме», не имея представления принесёт ли ему это реальную пользу?
Видимо действительно вы имеете высокий авторитет у них. Вы же не гоните им маркетинговую пургу типа «мускул вчерашний день, особенно после того как его приобрела оракл, надо от них отвязываться и потому надо переписать логику хранения на взаимодействие с PostgreSQL, тем более, что он с Oracle почти совместим»?
Или реально сравниваете «за» и «против» двух разных SQL движков в конкретной ситуации? А про NoSQL задумывались? Это тоже «модно»!
Видимо действительно вы имеете высокий авторитет у них. Вы же не гоните им маркетинговую пургу типа «мускул вчерашний день, особенно после того как его приобрела оракл, надо от них отвязываться и потому надо переписать логику хранения на взаимодействие с PostgreSQL, тем более, что он с Oracle почти совместим»?
Или реально сравниваете «за» и «против» двух разных SQL движков в конкретной ситуации? А про NoSQL задумывались? Это тоже «модно»!
А вопрос-то провокационный :). Нет, подобной «пурги» не гоним. Но когда проект достаточно большой и априори известно, что хостинг будет на отдельном сервере, Вы не считаете оправданным использование полноценной реляционной СУБД? MySQL, даже с InnoDB, не дотягивает. И, да — мне лично не нравится то, как развивается (точнее не развивается) MySQL после покупки его саном и, соответственно, теперь ораклом. Но, конечно, я далека от мысли о его скорой кончине ввиду его тотальной распространенности.
А NoSQL пока не пробовали и даже не планируем пока — нет на чем :) — проект надо с соответствующим набором данных и — самое главное — экспериментальный.
А NoSQL пока не пробовали и даже не планируем пока — нет на чем :) — проект надо с соответствующим набором данных и — самое главное — экспериментальный.
Жестковато для 5-6 человек, имхо это уже 20+ нужна такая организация.
Да даже и для более крупных студий имхо некоторые пункты лишние.
К примеру, wiki и TDD. У не особо крупных студий вряд ли будут проекты требующие этой технологии, особенно учитывая web-специфику.
Да даже и для более крупных студий имхо некоторые пункты лишние.
К примеру, wiki и TDD. У не особо крупных студий вряд ли будут проекты требующие этой технологии, особенно учитывая web-специфику.
может быть и жестковато. Но по-другому не стоит :). на самом деле очень существенной является предпосылка о том, что наша задача в первую очередь строить не «студию» (с упором на дизайн), а все-таки контору по программировию (у нас дизайна в среднем около 5-10% по проекту, хотя есть, конечно, проекты и по 50%).
Wiki — для внутреннего пользования просто незаменимая вещь.
Wiki — для внутреннего пользования просто незаменимая вещь.
Команды +20 рождаются из 3-5 человек. если на первоначальном этапе нет общих принципов и у каждого зоопарк, то на команде 20+ наложить такой устав будет ой как сложно.
Насчёт TDD не соглашусь. Даже в «студии» из одного человека она приносит ощутимую пользу. И, как не странно, именно в веб-специфике. Она даёт возможность простым способом (анализом текста) охватить полный (почти, если не трогать JS) поток выполнения. В случае, например, с GTK+ вы, извините за выражение, задолбаетесь его эмулировать стабами и моками.
Неплохо было бы в первый список еще добавить написание технического задания и оценка времени и стоимости выполнения работ. Как показывает практика этого как раз и не хватает для нормальной работы подобной команды. Так что наличие технического писателя в такой команде просто необходимо на мой взгляд, поскольку заказчики редко приходят с нормальной спецификацией (вообще практически не приходят).
На словах все красиво. На деле работал я в 3 вебстудиях — максимум 3 пункта из 22 использовались
Ни кто ни чего и ни кому не должен :) Реальность заставляет отступать от правил и принципов.
А вообще ваша компания чем только не занимается, но при этом вы хотите разделить все полномочия среди сотрудников. У вас только дизайнера не хватает :)
А вообще ваша компания чем только не занимается, но при этом вы хотите разделить все полномочия среди сотрудников. У вас только дизайнера не хватает :)
Если что-то из этого выполняется у вас, не могли бы вы рассказать по пунктам по-подробнее свой опыт?
не все работает, конечно. в статье описан идеал: чего хотелось бы достичь.
Но многое работает, конечно. Из того, что не работает, это в первую очередь дисциплина ведения проекта, планирование и учет времени, не работает TDD. Многое работает не полностью, но такие вещи как, например, стандарт кодирования, контроль версий, трехуровневая разработка — все это работает.
Но многое работает, конечно. Из того, что не работает, это в первую очередь дисциплина ведения проекта, планирование и учет времени, не работает TDD. Многое работает не полностью, но такие вещи как, например, стандарт кодирования, контроль версий, трехуровневая разработка — все это работает.
В целом всё верно, на мой взгляд, но со вторым пунктом смею не согласиться. Важно не общее IDE, а поддержка ими функциональности, которая необходима. Как то: настройка общего стиля кодирования (форматирования), интеграция с СУБД/CVS/другое (ant, запуск/дебаггер локального сервера, если используется и т.д.).
Благо хороших IDE не мало, а привыкать к новому инструменту/ОС не всем хочется.
Благо хороших IDE не мало, а привыкать к новому инструменту/ОС не всем хочется.
Поддержу, но замечу, что указанный пункт имеет право на жизнь. Но в одном случае только. Когда имеем унифицированное рабочее место. Т.е. теоретически любой разработчик может сесть за любое рабоче место и начать работу. Имхо, такое возможно только в больших студиях в условиях массового производства. А для небольшой студии вероятность близка к 0.
конечно важна поддержка функциональности. Но мы же не занимаемся разработкой драйверов и веб-разработкой. Исходим из того, что программируем только под web и даже больше — используем одну (ну максимум две) технологии (например php и perl).
Важно именно унифицированное рабочее место (как откомментировано ниже), имхо.
Прекасная штука — парное программирование (стоит время от времени практиковать) невозможна без единого IDE. Без единого IDE страдает процесс обучения.
Важно именно унифицированное рабочее место (как откомментировано ниже), имхо.
Прекасная штука — парное программирование (стоит время от времени практиковать) невозможна без единого IDE. Без единого IDE страдает процесс обучения.
С интересом прочел, но в целом есть огромное количество НО. В принципе все они сводятся к одой генеральной линии. В условиях небольшой студии они просто нереализуемые. Потому что их просто некому делать. Особенно это касается документации, обучения. Даже если такие вещи насаждаются сверху, то очень быстро стухают. Ну нежиснеспособны они в условиях небольшой студии, нежиснеспособны.
Я даже возьму на себя смелость утверждать, что попытка в небольшой студии выполнить все эти пункты может привести к краху. Потому что ресурсы, коих и так немного, будет отвлекаться на задачи прок от которых сомнителен, а время они требуют.
Кстати. 7 лет довольно приличный срок в нашей сфере. Сколько реально из указанных пунктов получилось реализовать у себя в полном объеме? Каких затрат это стоило, какой профит принесло? Т.е. я предлагаю не уходя в абстрактные размышления рассмотреть ваш конкретный случай.
Я даже возьму на себя смелость утверждать, что попытка в небольшой студии выполнить все эти пункты может привести к краху. Потому что ресурсы, коих и так немного, будет отвлекаться на задачи прок от которых сомнителен, а время они требуют.
Кстати. 7 лет довольно приличный срок в нашей сфере. Сколько реально из указанных пунктов получилось реализовать у себя в полном объеме? Каких затрат это стоило, какой профит принесло? Т.е. я предлагаю не уходя в абстрактные размышления рассмотреть ваш конкретный случай.
реализуемые :). Конечно описан идеал — как хотелось бы работать.
Но даже если вы работаете один, многое из этого списка надо реализовать, имхо.
У нас работает не все: хуже всего с учетом и планированием. И еще с тестами. Но такие базвые вещи, как стандарт кодирования, как контроль версий, уровни доступа, внутренняя база знаний и вики — это все работает.
И работает, кстати, обучение — у нас почти все время 2-3 стажера (студенты), не все остаются, не все из оствшихся остаються на долго, но иначе работать вообще будет не с кем. Стараемся регулярно проводить семинары — это очень интересно, кстати.
Но даже если вы работаете один, многое из этого списка надо реализовать, имхо.
У нас работает не все: хуже всего с учетом и планированием. И еще с тестами. Но такие базвые вещи, как стандарт кодирования, как контроль версий, уровни доступа, внутренняя база знаний и вики — это все работает.
И работает, кстати, обучение — у нас почти все время 2-3 стажера (студенты), не все остаются, не все из оствшихся остаються на долго, но иначе работать вообще будет не с кем. Стараемся регулярно проводить семинары — это очень интересно, кстати.
Многое != все.
Кстати обучение может быть разным. Обучение работы с платформой на которых идет разработка — необходимость. А вот обучение более общим вещам уже не работает. Хороший специалист не знает, хороший препод. Как ни крути, но это разные специализации которые редко можно найти в одном человеке. А нанимать отдельного спеца тупо не выгодно.
Кстати обучение может быть разным. Обучение работы с платформой на которых идет разработка — необходимость. А вот обучение более общим вещам уже не работает. Хороший специалист не знает, хороший препод. Как ни крути, но это разные специализации которые редко можно найти в одном человеке. А нанимать отдельного спеца тупо не выгодно.
да, конечно, но я же не сказала, что мы так работаем, я написала, что мы хотим так работать, что это важно.
С обучением, конечно, не все так просто. Но можно выделить 2 часа в конце дня раз в неделю, собраться всем за чаем у доски и послушать кого-то одного, потом подискутировать и разойтись по домам думать :). Имхо — это очень, очень важно. 2 года у нас не было семинаров (была серьезная причина) — очень все соскучились, возобновили. Все равно вы с коллегой где-то на кухне обсуждаете какие-то детали, например архитектуры (использовать синглтон, или нет например) — так имеет смысл вынести это на семинар в конце недели — у кого-то другие мысли конструктивные будут. И даже студент, который и слова то не знает такого, прочтет на доске о чем дискуссия будет, и тот википедию посмотрит и тоже чего-то там для себя из этого возьмет.
С обучением, конечно, не все так просто. Но можно выделить 2 часа в конце дня раз в неделю, собраться всем за чаем у доски и послушать кого-то одного, потом подискутировать и разойтись по домам думать :). Имхо — это очень, очень важно. 2 года у нас не было семинаров (была серьезная причина) — очень все соскучились, возобновили. Все равно вы с коллегой где-то на кухне обсуждаете какие-то детали, например архитектуры (использовать синглтон, или нет например) — так имеет смысл вынести это на семинар в конце недели — у кого-то другие мысли конструктивные будут. И даже студент, который и слова то не знает такого, прочтет на доске о чем дискуссия будет, и тот википедию посмотрит и тоже чего-то там для себя из этого возьмет.
Если не секрет, сколько человек составляют «ядро» (время работы у вас от года), сколько человек всего? Есть ли какие то свои, студийные наработки. Есть ли архитектор вообще (человек, который решает, что использовать и в каком виде)?
всего сейчас у нас работает 7 человек, из них «ядро» — 4.
Решения по архитектуре проектов принимаются, как правило, коллегиально (2-3 чел).
Свои наработки, конечно, же есть, есть даже идея выложить в open source один проект, но он требует подготовки и доработки пока. По существенным причинам (рождение ребенка) мы сильно притормозили, если не сказать вообще откатились назад за последние 2 года, но это временно, надеюсь. Не хочу, поэтому, называть здесь никаких URL.
Из интересного нетипичного опыта у нас серьезные проекты на связке php+Firebird.
Решения по архитектуре проектов принимаются, как правило, коллегиально (2-3 чел).
Свои наработки, конечно, же есть, есть даже идея выложить в open source один проект, но он требует подготовки и доработки пока. По существенным причинам (рождение ребенка) мы сильно притормозили, если не сказать вообще откатились назад за последние 2 года, но это временно, надеюсь. Не хочу, поэтому, называть здесь никаких URL.
Из интересного нетипичного опыта у нас серьезные проекты на связке php+Firebird.
Хм… ребенок. Имхо, личные обстоятельства одно из участников влияющие на вектор развития проекта в целом это очень плохо. По крайне мере для проекта такого возраста наличие ключевых людей — потенциальный фактор который может все потопить.
А со сторонними разработчиками сотрудничайте?
А со сторонними разработчиками сотрудничайте?
работать, по возможности, с максимум СУБД — это путь в ад )
не соглашусь. максимум здесь не очень высок — выбор и так небольшой. Но освоение новой СУБД достаточно «дешево» — все-таки SQL и нормальную форму никто не отменял, а профит от этого относительно большой: вы расширяете рамки и работы и собственного понимания. Например на данный момент мы работаем все-то с тремя СУБД: MySQL, PostgreSQL и Firebird.
Спасибо, но вопрос. Пункт 18, что вы имели ввиду под «режимом только для чтения» и почему необходимо использовать именно его, а не полноценную версию продакшена, в качестве превью?
спасибо вам :).
Возможно я не до конца понятно изложила мысль. Пример из жизни:
у нас два (если не считать заказчиков) собственных сервера: одиин вннутренний, на котором ведется разработка и живут превью версии, другой — продакшен.
Речь о режиме доступа к внутреннему серверу: все ресурсы (проекты) закрыты под авторизацию: т.е. каждое изменение и даже каждый просмотр не анонимны. Исключением может быть сайт с базой знаний — он открыт изнутри (локальная сеть) но извне тоже требует авторизации.
Полноценная версия продакшена в качестве превью не годится, так как вам заказчик во-первых еще не за работу не заплатил, а если вы работаете над дополнительными фичами для уже существующего сайта, так сначала нужно «ок» от заказчика получить, а потом и на продакшем можно. Продакшен для превью не годится еще и потому, что превью часто «сырой» материал и ложить весь продакшен сервер из-за одного циклического редиректа, например, совсем не стоит.
Возможно я не до конца понятно изложила мысль. Пример из жизни:
у нас два (если не считать заказчиков) собственных сервера: одиин вннутренний, на котором ведется разработка и живут превью версии, другой — продакшен.
Речь о режиме доступа к внутреннему серверу: все ресурсы (проекты) закрыты под авторизацию: т.е. каждое изменение и даже каждый просмотр не анонимны. Исключением может быть сайт с базой знаний — он открыт изнутри (локальная сеть) но извне тоже требует авторизации.
Полноценная версия продакшена в качестве превью не годится, так как вам заказчик во-первых еще не за работу не заплатил, а если вы работаете над дополнительными фичами для уже существующего сайта, так сначала нужно «ок» от заказчика получить, а потом и на продакшем можно. Продакшен для превью не годится еще и потому, что превью часто «сырой» материал и ложить весь продакшен сервер из-за одного циклического редиректа, например, совсем не стоит.
Забыли упомянуть о «стандартизации» процедуры деплоя(выкладки) проектов на прод\стейджинг(превью) сервера.
Было бы отлично для всех членов команды использовать одни и те же инструменты(капистрано, фабрик и т.п.)
Было бы отлично для всех членов команды использовать одни и те же инструменты(капистрано, фабрик и т.п.)
BugTracker + SVN (с разграничением доступа) + Wiki (простенький) + CRM (крайне простенький) — это Вам Redmine в помощь.
С разрешения автора :) список из статьи на стену повешу, буду партнера в него тыкать — «Смотри, это не я один такой, это умные люди придумали»
С разрешения автора :) список из статьи на стену повешу, буду партнера в него тыкать — «Смотри, это не я один такой, это умные люди придумали»
НЛО прилетело и опубликовало эту надпись здесь
> 2. Общее IDE и общий набор других инструментов (напр. программ для работы с базами данных). Мессенджер, конечно, каждый может использовать какой кому нравится, но работая по одной технологии нельзя держать зоопарк IDE даже если это и не стоит денег.
Дальше читать не хочется. А если IDE напарника реализаует тот же функционал, что и ваше, то какая вам разница, чем он пишет код?
Дальше читать не хочется. А если IDE напарника реализаует тот же функционал, что и ваше, то какая вам разница, чем он пишет код?
большая разница. Выше уже отвечала: когда вы работаете в группе и используете одну IDE, вам проще и легче показать и обьяснить другому члену команды, например, над чем вы работаете. Кроме того без единого IDE невозможно практиковать парное программирование. Иными словами выиграш в легкости передачи знаний в первую очередь.
Вы первая успели ответить (((
А кто определяет каким IDE будет пользоваться команда? Интересно, как вы будете уговаривать закостенелых вимеров или емаксеров пользоваться чем-нибудь типа NetBeans.
видите ли, когда вы устраиваетесь на работу, такие вещи должны быть оговорены. А кто определяет зависит от модели отношений в команде: может быть и единоличное решение, а можно и коллегиально. Новый человек должен подчиниться общим правилам, иначе не будет команды. Переход на новое IDE (сейчас у нас Eclipse) возможен, но здесь уже надо выслушать всех.
А вы можете назвать примеры компаний, где используется такая практика?
когда человек приходит на тестовый период в любую более-менее продвинутую команду и не желает подчиниться общим правилам, его просто-напросто не возьмут (если, конечно, не нанимают гуру у которого сами собираются учиться). Не возьмут не потому, что принципиальный или непрофессиональный, а потому что неуступчив и потенциально конфликтный. Я не назову вам конкретных имен компаний, но, поверьте, такие ньюансы выясняются еще до приема на постоянную работу и часто нет даже необходимости закреплять их формально соглашением на бумаге.
Примеры из личной жизни — NetBeans vs ZendStudio 8
— форматирование отступов по умолчанию — 4 пробела vs tab.
Возможно, это все настраиваемое, но из коробки у меня работало именно так.
Очень неприятно знаете ли смотреть на код «елочкой», когда он добавляет какую-либо строчку посреди моей функции.
— баги/особенности при работе с SVN у каждой IDE свои. Проще договориться что именно не стоит делать. У меня были случаи, когда NetBeans не мог провести svn update после какого-нибудь извращенного комита от ZS.
И таких мелочей может быть очень много. Зачем это все испытывать на своей шкуре?
Это при работе с напарником. При работе со стажером проще из памяти достать сочетание кнопок (расположение в меню) именно той IDE, которой пользуешься сам, чем подходить и разбираться.
Кроме того, баги IDE при работе с SVN у каждой
— форматирование отступов по умолчанию — 4 пробела vs tab.
Возможно, это все настраиваемое, но из коробки у меня работало именно так.
Очень неприятно знаете ли смотреть на код «елочкой», когда он добавляет какую-либо строчку посреди моей функции.
— баги/особенности при работе с SVN у каждой IDE свои. Проще договориться что именно не стоит делать. У меня были случаи, когда NetBeans не мог провести svn update после какого-нибудь извращенного комита от ZS.
И таких мелочей может быть очень много. Зачем это все испытывать на своей шкуре?
Это при работе с напарником. При работе со стажером проще из памяти достать сочетание кнопок (расположение в меню) именно той IDE, которой пользуешься сам, чем подходить и разбираться.
Кроме того, баги IDE при работе с SVN у каждой
Часть пунктов конечно не является истиной в последней инстанции, остальное, вроде бы очевидно, но некоторое до сих пор не ввели у себя. Лень матушка…
Все верно. У нас это называется процедуры. Есть по каждому блоку работы: проектирование, дизайн, верстка, программирование, тестирование и конечно менеджмент. Всего сотни пунктов, каждого заставляем использовать, а каждый этап проверяет тестер и менеджер проектов, смотрят соответствие этапа нормам качества прописанным в процедурах.
Из этих пунктов используем где-то 17-18, у нас немного другая специфика и еще используем куча своих пунктов. Кстати, может кому интересно посмотреть на такие процедуры в форме чеклистов? Выложить на Хабре списками?
Из этих пунктов используем где-то 17-18, у нас немного другая специфика и еще используем куча своих пунктов. Кстати, может кому интересно посмотреть на такие процедуры в форме чеклистов? Выложить на Хабре списками?
Большое спасибо, очень полезная информация :)
А не могли бы вы сказать в какой компании всё это используется? :)
ВСЕ не используется нигде — это же идеал :).
Но мы стараемся :). Что работает на данный момент, а с чем — проблемы, уже овечала несколько раз выше: плохо работает планирование, частично менеджмент, тестирование. Если Вас действительно интересует название маленькой компании на Западной Украине, смотрите мой профайл, хотя по некоторым причинам он 2 года не обновлялся — будем исправляться.
Но мы стараемся :). Что работает на данный момент, а с чем — проблемы, уже овечала несколько раз выше: плохо работает планирование, частично менеджмент, тестирование. Если Вас действительно интересует название маленькой компании на Западной Украине, смотрите мой профайл, хотя по некоторым причинам он 2 года не обновлялся — будем исправляться.
>Стремиться к тому, чтобы разработчики не работали одновременно над несколькими проектами (насколько это возможно, конечно).
Это возможно только в случае крупного или очень крупного проекта с таким количеством человек в команде. У вас их несколько одновременно, я так понимаю? Зачем тогда к этому стремиться? Или вы стремитесь (стратегически) к крупным проектам (и, как следствие, чтобы разработчики с ним одним и работали)?
Это возможно только в случае крупного или очень крупного проекта с таким количеством человек в команде. У вас их несколько одновременно, я так понимаю? Зачем тогда к этому стремиться? Или вы стремитесь (стратегически) к крупным проектам (и, как следствие, чтобы разработчики с ним одним и работали)?
специфика компаний по веб-разработке такова, что в работе, как правило, одновременно относительно большое число опять же относительно небольших проектов. Сложно, конечно, в таких условиях работать конкретному человеку только над одним проектом, понятно. Но желательно все же стремиться к этому по той простой причине, что при частых переключениях между задачами существенно страдает эффективность работы. Поэтому я написала «насколько возможно». То, что можно все-таки сделать в таких условиях, это, например, оградить программиста от звонков и других прямых контактов (через мессенджер, например) с заказчиком, планировать работу из расчета, например, сегодня и завтра — один проект, послезавтра — другой, до обеда — один проект, послк обеда — другой, или, например, по однотипных задачах: настраиваем сегодня систему управления новостями для проекта 1 и 2, завтра — книгу отзывов и т.п.
И да, конечно, имеет смысл стремиться к крупным проектам, стратегически это выгодно.
И да, конечно, имеет смысл стремиться к крупным проектам, стратегически это выгодно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как должна работать компания по web-программированию