DM прислал свой комментарий:
Паша, спор произошел из-за того, что не было зафиксированного решения. Было много предложений, но никто не понял, что в результате было утверждено. Каждый ушел с собрания со своим мнением.
Я понимаю, что бюрократизм - это плохо, но на таких важных собраниях результат надо фиксировать.
И неплохо было бы все принятые решения собирать в одном общедоступном месте (опять же, на блоге, например).
Иначе, извини, это пустая болтовня.
Итак..
Естественно, это необходимо сделать, но вот вопрос - скорее это необходимо делать разработчикам, а не конкретному человеку связанным с маркетингом. Взять на себя обязанность разрабатывать SF и общий подход я не могу по след. причинам
1) на данный момент моих знаний просто не достаточно - я не видел ни одной строчки кода
2) все что я пытаюсь сделать это организовать команду - без инициативы "снизу" проект обречен на провал.
Ожидать от команды незамедлительно перехода невозможно - нас не 5 человек и проектов у нас не 5. Будут проблемы и к ним нужно отнестись с пониманием (это для SEXDrive) - есть communication/collaboration, который равен 0 на данный момент - это уже проблема всех.
1) c 15 февраля снимаем с pklimov все проекты и делаем его ответственным за поддержку SF
2) на этапе создания проекта делаем след шаги
a) забираем стабильную версию SF из репозитория
б) обновления SF идет только в пределах этой версии
в) критические изменения, затрагивающие core часть - выносим в новую версию
При возникновении проблем в исходниках SF - разработчик постит задачу в Jira с указанием версии и описанием проблемы.
Хочу отметить что мы будем документировать и разработку SF и разработку библиотек, модулей - есть собственно группа разработчиков, которые выявили желание работать над этим, включая семинары.. Но нужно выделить спец. время и следовать ему строго..
Пока до 15 числа делаем организационные моменты - много идет на это, к сожалению..
tools которые будем использовать я напишу отдельно...
Очень точно сформулирована сложившаяся ситуация: "возникла проблема после исправления проблемы". Проблема тут действительно шире, и если её не решить сейчас, то smartyforms повторит судьбу своего предшественника. В свете этого у меня есть концептуальные предложения и предложения технического характера, относящиеся непосредственно к коду. Итак, по порядку.
ОтветитьУдалить1. Централизованное хранение библиотеки должно быть официально узаконено, потому что сегодня были услышаны и другие мнения, чему был немало удивлён.
2. Создание версий библиотеки. Уже неоднократно повторяющиеся ситуации, когда некритичные изменения в библиотеке приводят к краху всего проекта, недопустимы. Просто потому, что pklimov подумал, что так будет удобней ему, а остальные пошли пересматривать все свои новые проекты. Получается так, что не он работает на команду, а команда на него. Что можно по этому поводу предложить... Разработчикам не нужны новые версии библиотеки каждый месяц. Нужно взять текущую версию библиотеки и сказать: "Стоп. Хватит нового функционала. Следующие полгода/год/два мы занимаемся тем, что совершенствуем этот инструмент". И только после этого приступить к разработке новой версии, в которой не будет ошибок предыдущей, и будет добавлен новый функционал. И естественно, после обсуждения (читай холивара) между разработчиками и техническим персоналом (rl).
3. Обратная совместимость внутри версии, что плавно вытекает из предыдущего пункта. Интерфейс библиотеки не должен меняться в рамках одной версии (если, конечно, изменения не критичны).
4. imho, "снимаем с pklimov все проекты" - думаю, это будет ошибкой. Человек и так пишет код, которые не будет работать на таких проектах, как thepickexchange и adventlocal просто из-за большого объёма данных. Человек должен иметь опыт разработки и знать, с чем сталкиваются в реальной жизни разработчики.
Относительно кода, думаю, тут детально говорить не нужно, надо просто сесть и обсудить это непосредственно за монитором. Отмечу лишь, что есть вещи, которые мне, с высшим образованием и 15-летним общим опытом программирования, просто непонятны, есть то, от чего, в частности, наша комната уже отказалась, потом вопросы оптимизации и прочие мелочи, которых много. В общем, должна быть обратная связь.
И ещё. Может стоит всё-таки задуматься над необходимостью software qa? Внешнее качество проверяется тестировщиком - это отдельная тема, но есть же и внутреннее качество, на которое сейчас мало кто обращает внимание. Однако, с этим надо что-то делать. Можно начать с малого и производить приёмку кода. А можно ещё лучше сделать, если давать любой, даже самый маленький проект не одному, а хотя бы двум программистам. Они и контролировать друг друга будут, и подсказывать, а заодно, может, и к единому стилю придём со временем. Но это было бы очень полезно.
P.S. sexdrive всё понимает, но не хочет сидеть сложа руки.