Pull to refresh

Comments 11

Видимо не программистам этого не понять…
Мне кажется, это попытка стилизации описания какой-то методологии. Честно говоря, не сумел догадаться, что значит «тропинка» и «узелки».

Несколько соображений по поводу стилизации:

Мне кажется, что стилизация — это довольно сложный процесс. Она предполагает не просто изменение порядка членов предложений, да подмену словесов всевозможных.
Надо и использовать и подходящие слова, и грамматику, и орфографию.
Очень повеселило старославянское слово «маг».

Несколько соображений по поводу методологии:

Пункт 1: не очень понятно, что имеется в виду. Стандарт есть стандарт, он общекорпоративен. Если разные группы следуют разным стандартам, то это не очень здорово.

Пункт 2: отличное время 11 часов утра! И не очень поздно, и не очень рано.

Пункт 3: сомнителен способ разработки в branch. Мне кажется, что одна из самых сложных операций — это merge. Проблема в том, что по определению надо работать с чужим, незнакомым кодом. Постоянный merge каждого разработчика может быть весьма багоёмким.

Пункт 4: я не очень понял метафору богомола, но очень грустно, что отношение к разработчику зависит от количества багов. Было бы здорово работать в команде, где коллеги помогали бы фиксить баги, а не теряли бы уважение.

Пункт 5: аааа! ежедневный отчет! Чур!
«Тропинка» — это название проекта, не приводится понятно по каким соображениям. Узелки — значит на память, чтобы не забыть. По поводу стилизацию — не претендую на филологическую истину, по-моему не стоит чересчур углубляться в это.

Еще маленькое замечание — это не вся методология проекта, а те ее составляющие, которые как-то отличаются от обычно нами используемых методов/методик.

1. Имеется в виду стандарт кодирования. В данном случае здравый смысл побеждает тупое следование стандартам. Есть куча кода со старым стандартом, а есть новый стандарт. Смысл в одном проекте получать мешанину из двух стилей?
3. Во-первых, проект так структурирован, что у каждого достаточно независимый кусок кода. Во-вторых, риск в данном случае осознанный (учитывая некий запас сроков). Одна из основных целей данного пункта — как раз научить людей выполнять merge. Да это может привести к проблемам, но всегда есть экспертиза кода.
4. Богомол <=> Mantis. Багтрекер такой. А про уважение — это естественно юмор. Взаимопомощь, взаимное уважение и командный дух я всячески поддерживаю в команде.
5. No comments.
Большое спасибо за адекватный ответ.

Теперь я всё понял.
Наверное, Вы правы, что при грамотной архитектуре и правильном руководстве много маленьких merge'ей лучше одного большого.

Единственное, что вызывает сомнение, это ежедневный письменный отчёт. Но это вызвано личными престрастиями. Уверен, что для определённых команд такая мера весьма полезна.

А про mantis мне следовало догадаться :)
И вам спасибо за некую критику. По поводу отчета — он не письменный, можно просто во внутренний Jabber. Меня собственно интересуют только метрики трудоемкости по функциям, вот и все. Хотя это все равно только эксперимент. Я сам не очень положительно к таким вещам отношусь.
Видимо не программистам этого не понять…
Следовало бы не только стиль, но и алфавит использовать великокняжеских времён, а не тридцатитрёхбуквенный огрызок, установленный девяносто лет назад ритуальным обрезанием жидобольшевицким.
Не знаютъ мои программеры алфавита (читай азбуки) сего.
Полностью согласен, подобное изложение информации для людей любого круга является эффективным т.к. вызывает улыбку, а положительные эмоции помогают человеку запомнить информацию лучше.

Опять же разнообразия ради, я был бы очень рад увидеть в каком — то служебном документе, исключительно для внутреннего пользования, такой текст.
Спасибо. Цель в том и была, чтобы людей как-то заинтересовать. Я еще сделал мини-бумажки из 5 пунктов, размером с листик блокнота, чтобы могли храниться у каждого на столе.
Sign up to leave a comment.

Articles