Комментарии 11
Что это!???
Видимо не программистам этого не понять…
Мне кажется, это попытка стилизации описания какой-то методологии. Честно говоря, не сумел догадаться, что значит «тропинка» и «узелки».
Несколько соображений по поводу стилизации:
Мне кажется, что стилизация — это довольно сложный процесс. Она предполагает не просто изменение порядка членов предложений, да подмену словесов всевозможных.
Надо и использовать и подходящие слова, и грамматику, и орфографию.
Очень повеселило старославянское слово «маг».
Несколько соображений по поводу методологии:
Пункт 1: не очень понятно, что имеется в виду. Стандарт есть стандарт, он общекорпоративен. Если разные группы следуют разным стандартам, то это не очень здорово.
Пункт 2: отличное время 11 часов утра! И не очень поздно, и не очень рано.
Пункт 3: сомнителен способ разработки в branch. Мне кажется, что одна из самых сложных операций — это merge. Проблема в том, что по определению надо работать с чужим, незнакомым кодом. Постоянный merge каждого разработчика может быть весьма багоёмким.
Пункт 4: я не очень понял метафору богомола, но очень грустно, что отношение к разработчику зависит от количества багов. Было бы здорово работать в команде, где коллеги помогали бы фиксить баги, а не теряли бы уважение.
Пункт 5: аааа! ежедневный отчет! Чур!
Несколько соображений по поводу стилизации:
Мне кажется, что стилизация — это довольно сложный процесс. Она предполагает не просто изменение порядка членов предложений, да подмену словесов всевозможных.
Надо и использовать и подходящие слова, и грамматику, и орфографию.
Очень повеселило старославянское слово «маг».
Несколько соображений по поводу методологии:
Пункт 1: не очень понятно, что имеется в виду. Стандарт есть стандарт, он общекорпоративен. Если разные группы следуют разным стандартам, то это не очень здорово.
Пункт 2: отличное время 11 часов утра! И не очень поздно, и не очень рано.
Пункт 3: сомнителен способ разработки в branch. Мне кажется, что одна из самых сложных операций — это merge. Проблема в том, что по определению надо работать с чужим, незнакомым кодом. Постоянный merge каждого разработчика может быть весьма багоёмким.
Пункт 4: я не очень понял метафору богомола, но очень грустно, что отношение к разработчику зависит от количества багов. Было бы здорово работать в команде, где коллеги помогали бы фиксить баги, а не теряли бы уважение.
Пункт 5: аааа! ежедневный отчет! Чур!
«Тропинка» — это название проекта, не приводится понятно по каким соображениям. Узелки — значит на память, чтобы не забыть. По поводу стилизацию — не претендую на филологическую истину, по-моему не стоит чересчур углубляться в это.
Еще маленькое замечание — это не вся методология проекта, а те ее составляющие, которые как-то отличаются от обычно нами используемых методов/методик.
1. Имеется в виду стандарт кодирования. В данном случае здравый смысл побеждает тупое следование стандартам. Есть куча кода со старым стандартом, а есть новый стандарт. Смысл в одном проекте получать мешанину из двух стилей?
3. Во-первых, проект так структурирован, что у каждого достаточно независимый кусок кода. Во-вторых, риск в данном случае осознанный (учитывая некий запас сроков). Одна из основных целей данного пункта — как раз научить людей выполнять merge. Да это может привести к проблемам, но всегда есть экспертиза кода.
4. Богомол <=> Mantis. Багтрекер такой. А про уважение — это естественно юмор. Взаимопомощь, взаимное уважение и командный дух я всячески поддерживаю в команде.
5. No comments.
Еще маленькое замечание — это не вся методология проекта, а те ее составляющие, которые как-то отличаются от обычно нами используемых методов/методик.
1. Имеется в виду стандарт кодирования. В данном случае здравый смысл побеждает тупое следование стандартам. Есть куча кода со старым стандартом, а есть новый стандарт. Смысл в одном проекте получать мешанину из двух стилей?
3. Во-первых, проект так структурирован, что у каждого достаточно независимый кусок кода. Во-вторых, риск в данном случае осознанный (учитывая некий запас сроков). Одна из основных целей данного пункта — как раз научить людей выполнять merge. Да это может привести к проблемам, но всегда есть экспертиза кода.
4. Богомол <=> Mantis. Багтрекер такой. А про уважение — это естественно юмор. Взаимопомощь, взаимное уважение и командный дух я всячески поддерживаю в команде.
5. No comments.
Большое спасибо за адекватный ответ.
Теперь я всё понял.
Наверное, Вы правы, что при грамотной архитектуре и правильном руководстве много маленьких merge'ей лучше одного большого.
Единственное, что вызывает сомнение, это ежедневный письменный отчёт. Но это вызвано личными престрастиями. Уверен, что для определённых команд такая мера весьма полезна.
А про mantis мне следовало догадаться :)
Теперь я всё понял.
Наверное, Вы правы, что при грамотной архитектуре и правильном руководстве много маленьких merge'ей лучше одного большого.
Единственное, что вызывает сомнение, это ежедневный письменный отчёт. Но это вызвано личными престрастиями. Уверен, что для определённых команд такая мера весьма полезна.
А про mantis мне следовало догадаться :)
Видимо не программистам этого не понять…
Следовало бы не только стиль, но и алфавит использовать великокняжеских времён, а не тридцатитрёхбуквенный огрызок, установленный девяносто лет назад ритуальным обрезанием жидобольшевицким.
Полностью согласен, подобное изложение информации для людей любого круга является эффективным т.к. вызывает улыбку, а положительные эмоции помогают человеку запомнить информацию лучше.
Опять же разнообразия ради, я был бы очень рад увидеть в каком — то служебном документе, исключительно для внутреннего пользования, такой текст.
Опять же разнообразия ради, я был бы очень рад увидеть в каком — то служебном документе, исключительно для внутреннего пользования, такой текст.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Узелки