вторник, 2 февраля 2010 г.

Smartyforms - предложения и проблемы

Сегодня возникла проблема после исправления проблемы безопасности в SmartyForms (SF). Были закомичены ревизии, затронувшие xajax методы. Из-за этого потребовалось делать ревизию кода во всех тек. проектах.

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 которые будем использовать я напишу отдельно...

1 комментарий:

  1. Очень точно сформулирована сложившаяся ситуация: "возникла проблема после исправления проблемы". Проблема тут действительно шире, и если её не решить сейчас, то smartyforms повторит судьбу своего предшественника. В свете этого у меня есть концептуальные предложения и предложения технического характера, относящиеся непосредственно к коду. Итак, по порядку.
    1. Централизованное хранение библиотеки должно быть официально узаконено, потому что сегодня были услышаны и другие мнения, чему был немало удивлён.
    2. Создание версий библиотеки. Уже неоднократно повторяющиеся ситуации, когда некритичные изменения в библиотеке приводят к краху всего проекта, недопустимы. Просто потому, что pklimov подумал, что так будет удобней ему, а остальные пошли пересматривать все свои новые проекты. Получается так, что не он работает на команду, а команда на него. Что можно по этому поводу предложить... Разработчикам не нужны новые версии библиотеки каждый месяц. Нужно взять текущую версию библиотеки и сказать: "Стоп. Хватит нового функционала. Следующие полгода/год/два мы занимаемся тем, что совершенствуем этот инструмент". И только после этого приступить к разработке новой версии, в которой не будет ошибок предыдущей, и будет добавлен новый функционал. И естественно, после обсуждения (читай холивара) между разработчиками и техническим персоналом (rl).
    3. Обратная совместимость внутри версии, что плавно вытекает из предыдущего пункта. Интерфейс библиотеки не должен меняться в рамках одной версии (если, конечно, изменения не критичны).
    4. imho, "снимаем с pklimov все проекты" - думаю, это будет ошибкой. Человек и так пишет код, которые не будет работать на таких проектах, как thepickexchange и adventlocal просто из-за большого объёма данных. Человек должен иметь опыт разработки и знать, с чем сталкиваются в реальной жизни разработчики.

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

    И ещё. Может стоит всё-таки задуматься над необходимостью software qa? Внешнее качество проверяется тестировщиком - это отдельная тема, но есть же и внутреннее качество, на которое сейчас мало кто обращает внимание. Однако, с этим надо что-то делать. Можно начать с малого и производить приёмку кода. А можно ещё лучше сделать, если давать любой, даже самый маленький проект не одному, а хотя бы двум программистам. Они и контролировать друг друга будут, и подсказывать, а заодно, может, и к единому стилю придём со временем. Но это было бы очень полезно.

    P.S. sexdrive всё понимает, но не хочет сидеть сложа руки.

    ОтветитьУдалить