всего сейчас у нас работает 7 человек, из них «ядро» — 4.
Решения по архитектуре проектов принимаются, как правило, коллегиально (2-3 чел).
Свои наработки, конечно, же есть, есть даже идея выложить в open source один проект, но он требует подготовки и доработки пока. По существенным причинам (рождение ребенка) мы сильно притормозили, если не сказать вообще откатились назад за последние 2 года, но это временно, надеюсь. Не хочу, поэтому, называть здесь никаких URL.
Из интересного нетипичного опыта у нас серьезные проекты на связке php+Firebird.
да, конечно, но я же не сказала, что мы так работаем, я написала, что мы хотим так работать, что это важно.
С обучением, конечно, не все так просто. Но можно выделить 2 часа в конце дня раз в неделю, собраться всем за чаем у доски и послушать кого-то одного, потом подискутировать и разойтись по домам думать :). Имхо — это очень, очень важно. 2 года у нас не было семинаров (была серьезная причина) — очень все соскучились, возобновили. Все равно вы с коллегой где-то на кухне обсуждаете какие-то детали, например архитектуры (использовать синглтон, или нет например) — так имеет смысл вынести это на семинар в конце недели — у кого-то другие мысли конструктивные будут. И даже студент, который и слова то не знает такого, прочтет на доске о чем дискуссия будет, и тот википедию посмотрит и тоже чего-то там для себя из этого возьмет.
спасибо вам :).
Возможно я не до конца понятно изложила мысль. Пример из жизни:
у нас два (если не считать заказчиков) собственных сервера: одиин вннутренний, на котором ведется разработка и живут превью версии, другой — продакшен.
Речь о режиме доступа к внутреннему серверу: все ресурсы (проекты) закрыты под авторизацию: т.е. каждое изменение и даже каждый просмотр не анонимны. Исключением может быть сайт с базой знаний — он открыт изнутри (локальная сеть) но извне тоже требует авторизации.
Полноценная версия продакшена в качестве превью не годится, так как вам заказчик во-первых еще не за работу не заплатил, а если вы работаете над дополнительными фичами для уже существующего сайта, так сначала нужно «ок» от заказчика получить, а потом и на продакшем можно. Продакшен для превью не годится еще и потому, что превью часто «сырой» материал и ложить весь продакшен сервер из-за одного циклического редиректа, например, совсем не стоит.
не соглашусь. максимум здесь не очень высок — выбор и так небольшой. Но освоение новой СУБД достаточно «дешево» — все-таки SQL и нормальную форму никто не отменял, а профит от этого относительно большой: вы расширяете рамки и работы и собственного понимания. Например на данный момент мы работаем все-то с тремя СУБД: MySQL, PostgreSQL и Firebird.
реализуемые :). Конечно описан идеал — как хотелось бы работать.
Но даже если вы работаете один, многое из этого списка надо реализовать, имхо.
У нас работает не все: хуже всего с учетом и планированием. И еще с тестами. Но такие базвые вещи, как стандарт кодирования, как контроль версий, уровни доступа, внутренняя база знаний и вики — это все работает.
И работает, кстати, обучение — у нас почти все время 2-3 стажера (студенты), не все остаются, не все из оствшихся остаються на долго, но иначе работать вообще будет не с кем. Стараемся регулярно проводить семинары — это очень интересно, кстати.
конечно важна поддержка функциональности. Но мы же не занимаемся разработкой драйверов и веб-разработкой. Исходим из того, что программируем только под web и даже больше — используем одну (ну максимум две) технологии (например php и perl).
Важно именно унифицированное рабочее место (как откомментировано ниже), имхо.
Прекасная штука — парное программирование (стоит время от времени практиковать) невозможна без единого IDE. Без единого IDE страдает процесс обучения.
не все работает, конечно. в статье описан идеал: чего хотелось бы достичь.
Но многое работает, конечно. Из того, что не работает, это в первую очередь дисциплина ведения проекта, планирование и учет времени, не работает TDD. Многое работает не полностью, но такие вещи как, например, стандарт кодирования, контроль версий, трехуровневая разработка — все это работает.
конечно правила на то и придуманы, чтобы от них отступать :). лучший вариант, если под все роли есть сотрудники, но дизайнера не всегда реально загрузить по полной, поэтому дизайнера, да, не хватает.
может быть и жестковато. Но по-другому не стоит :). на самом деле очень существенной является предпосылка о том, что наша задача в первую очередь строить не «студию» (с упором на дизайн), а все-таки контору по программировию (у нас дизайна в среднем около 5-10% по проекту, хотя есть, конечно, проекты и по 50%).
Wiki — для внутреннего пользования просто незаменимая вещь.
спасибо, на самом деле действительно часто для веб-проектов и у нас MySQL. Но на относительно больших, самостоятельных (не CMS) проектах, стараемся склонить заказчика к другому выбору. В результате достаточно активно используем и PostgreSQL и даже Firebird. В прошлом занимались также поддержкой проекта на Oracle. Просто освоение новой СУБД по сравнению с освоением, например, новго фреймворка, «стоит» на несколько порядков дешевле, а кругозор (и резюме) расширяет существенно.
Решения по архитектуре проектов принимаются, как правило, коллегиально (2-3 чел).
Свои наработки, конечно, же есть, есть даже идея выложить в open source один проект, но он требует подготовки и доработки пока. По существенным причинам (рождение ребенка) мы сильно притормозили, если не сказать вообще откатились назад за последние 2 года, но это временно, надеюсь. Не хочу, поэтому, называть здесь никаких URL.
Из интересного нетипичного опыта у нас серьезные проекты на связке php+Firebird.
С обучением, конечно, не все так просто. Но можно выделить 2 часа в конце дня раз в неделю, собраться всем за чаем у доски и послушать кого-то одного, потом подискутировать и разойтись по домам думать :). Имхо — это очень, очень важно. 2 года у нас не было семинаров (была серьезная причина) — очень все соскучились, возобновили. Все равно вы с коллегой где-то на кухне обсуждаете какие-то детали, например архитектуры (использовать синглтон, или нет например) — так имеет смысл вынести это на семинар в конце недели — у кого-то другие мысли конструктивные будут. И даже студент, который и слова то не знает такого, прочтет на доске о чем дискуссия будет, и тот википедию посмотрит и тоже чего-то там для себя из этого возьмет.
Возможно я не до конца понятно изложила мысль. Пример из жизни:
у нас два (если не считать заказчиков) собственных сервера: одиин вннутренний, на котором ведется разработка и живут превью версии, другой — продакшен.
Речь о режиме доступа к внутреннему серверу: все ресурсы (проекты) закрыты под авторизацию: т.е. каждое изменение и даже каждый просмотр не анонимны. Исключением может быть сайт с базой знаний — он открыт изнутри (локальная сеть) но извне тоже требует авторизации.
Полноценная версия продакшена в качестве превью не годится, так как вам заказчик во-первых еще не за работу не заплатил, а если вы работаете над дополнительными фичами для уже существующего сайта, так сначала нужно «ок» от заказчика получить, а потом и на продакшем можно. Продакшен для превью не годится еще и потому, что превью часто «сырой» материал и ложить весь продакшен сервер из-за одного циклического редиректа, например, совсем не стоит.
Но даже если вы работаете один, многое из этого списка надо реализовать, имхо.
У нас работает не все: хуже всего с учетом и планированием. И еще с тестами. Но такие базвые вещи, как стандарт кодирования, как контроль версий, уровни доступа, внутренняя база знаний и вики — это все работает.
И работает, кстати, обучение — у нас почти все время 2-3 стажера (студенты), не все остаются, не все из оствшихся остаються на долго, но иначе работать вообще будет не с кем. Стараемся регулярно проводить семинары — это очень интересно, кстати.
Важно именно унифицированное рабочее место (как откомментировано ниже), имхо.
Прекасная штука — парное программирование (стоит время от времени практиковать) невозможна без единого IDE. Без единого IDE страдает процесс обучения.
Но многое работает, конечно. Из того, что не работает, это в первую очередь дисциплина ведения проекта, планирование и учет времени, не работает TDD. Многое работает не полностью, но такие вещи как, например, стандарт кодирования, контроль версий, трехуровневая разработка — все это работает.
Wiki — для внутреннего пользования просто незаменимая вещь.