Защитить историю паролем (дополнительный пароль на серверную историю) будет работать в следующем релизе. А сегодня серверная история защищена доступом к учетной записи в протоколе обмена сообщениями. (Грубо: не зная UIN/пароля моей аськи никто не может прочитать мою серверную историю, при этом сервер пароля моей аськи не получает).
Да, согласен, прошу прощения, не очень четко написал. Хотел сказать: как можно раньше найти ошибку, не ошибку вида «у объекта нет метода хххх», а вида «ожидали объект Класс1, а получили типа Класс2». Спасибо.
Хотелось бы отметить, что в динамических языках программирования полиморфизм есть как бы «всегда». Можно накидать в массив объекты, классы которых не имеющие общих предков. И если у них у всех есть метод с одинаковой сигнатурой, его можно вызвать у всех объектов. Это, конечно же, не best-practice, и пример автора с интерфейсами куда правильнее.
Но в динамическом языке программирование работает именно позднее связывание, т.е. возможность вызова метода у объекта определяется только во время выполнения.
В некоторых языках программирования объект может получить метод после своего создания, например, что тоже может обеспечивать некоторый полиморфизм. (Например, можем «обогатить» ряд объектов дополнительной функциональностью).
Поэтому в PHP полиморфизм как таковой повсюду, в любом вызове метода. Но есть возможность четко контролировать интерфейсы классов, что чаще всего лучше (проверка на этапе компиляции).
Как раз наоборот, мой пост говорит об обратной практике. О том, что надо структурировать разработку, тогда можно будет меньше заглядывать в дифф (если не нужен code review), а самое главное, это позволит именно упорядочить свои мысли в конце дня и вместо комита с логом «день закончился» будет в течение дня серия осмысленных комитов, производящих осмысленные изменения. Часто невозможность это сделать и необходимость делать какие-то временные комиты (например, добавить срочно функцию в интерфейс в интересах другого разработчика) говорит о том, что в процессе разработки что-то не так (сугубо моё личное мнение, не обобщаю...)
Ну это только в теории. На практике всегда, даже в самом хорошо организованном коде становится понятно, что структура и организация неидеальны. Это становится понятно не сразу, а потом, по мере роста кода. Переписывать времени/денег нет.
Поэтому мы все только пытаемся приблизиться к идеалу, каждый новый проект делает это лучше, но с каждым новым проектом становится понятнее, что до идеала еще далеко.
Также и с логом комита. По началу кажется, что одного достаточно, потом добавляется еще что-то, он лучше структурируется и т.п. Это такой бесконечный итерационный процесс, прогресс ему имя, наверное :)
А они и пишутся прямо в лог, просто используется шаблон, чтобы это выглядело красиво и единообразно, и чтобы можно было автоматически это распарсить. Примерно как в посте в примере про CSS. Это называется 'commit template' обычно.
Не какие именно (добавил/удалил/изменил), а описывать их! Зачем, почему и т.п. Как называется добавленный параметр, какого он типа и т.п. — это всё видно из дифа, а вот зачем? На этот вопрос обычно диф не ответит, и он скрыт в голове программиста :)
Совершенно согласен! Только мелкий комит неатомарен, потому что не покрывает минимальную единицу изменения, а слишком большой неатомарен, потому что в нём несколько явных замыслов и идей.
Бывает, что надо закомитить в 10 файлов связанные изменения (например, добавили в интерфейс новый метод и во всех его потомков реализацию), а бывает что эти 10 файлов лучше закомитить по отдельности, потому что каждый из 10 комитов — это отдельный этап решения задачи.
Т.е. атомарность, имхо — это очень субъективная штука.
Комит должен быть атомарным, желательно делающим одно конкретное изменение. Так что сколько комитов в день — это сложный вопрос. Один человек за день, имхо, может сделать разумно десять-пятнадцать комитов, всё остальное — это уже какие-то технические вещи (например, мерж).
Но всё-таки я хочу подчеркнуть, что я говорю не о дублировании. А о документировании изменения как такового.
Могу привести пример: изменение может даже путешествовать между проектами, жить в виде патча и т.п., когда оно отделено от системы контроля версий. И лог ему нужен. И я писал про то, что лог как раз не дублирует информацию тикета, а дополняет её.
Само собой, автоматизация — трекер + VCS. Но попытка задуматься и написать нормальный лог упорядочивает программирование, вот что я хотел сказать. А копи-паст из тикета или просто ссылка на него не заставляет задуматься, это механическое действие.
Да, это так. Но не позволяет понять, почему было сделано конкретное изменение. Например, в процессе работы над какой-то фичей я могу внести в интерфейс дополнительный метод. А зачем я это сделал? От того, что работал над фичей? Нет, у меня была более конкретная мотивация, которая является частью изменений этого конкретного модуля. А ссылка на тикет обязательна.
Я чувствовал, что мой пост вызовет много возражений. Мне хотелось тут не в большей степени рассуждать о том, что лог должен содержать (а примерно то, что Вы пишите, он содержит у нас), а то, что написание разумного лога (до некоторой степени самодостаточного) позволяет улучшить качество программирования. Лог не может быть полностью самодостаточным — нужен тикет, чтобы понять зачем вообще это изменение затевалось (если задача решается серией комитов). Но всё-таки по отношению к изменению непосредственному он должен быть максимально автономен, то есть по логу должно быть понятно, что же именно поменялось и зачем в этом файле. Общая идея, склеивающая изменение — в тикете, в вики общая документация по коду/модулю. А каждое изменение заслуживает своей доки, опять-таки имхо. Я в конце писал о том, что именно написание самого лога упорядочивает мысли и позволяет выявить ошибки в коде.
Я своим постом хотел подвести, в частности, к этой мысли. Именно не повторять дифф и не повторять код, а давать что-то новое и важное по сравнению с кодом. Пример с CSS у меня неудачный, видимо. Спасибо.
Возможно, но тогда надо писать лог «смотри дифф». И потом если таких логов много, плюешь на всё и ищещь багу другими путями или перестаешь читать историю. Потому что её хочется именно читать, а не тыкаться в диффы ко всем ревизиями, некоторые из которых могут быть маленькими… А вот некоторые — совсем нет. Да и замысел автора из диффа чаще всего неочевиден.
Я пытался как раз написать о том, что лог комита экономит время. Т.е. время, затраченное на его написание, окупается. Хотя «лень», и хочется «побыстрее»…
Но в динамическом языке программирование работает именно позднее связывание, т.е. возможность вызова метода у объекта определяется только во время выполнения.
В некоторых языках программирования объект может получить метод после своего создания, например, что тоже может обеспечивать некоторый полиморфизм. (Например, можем «обогатить» ряд объектов дополнительной функциональностью).
Поэтому в PHP полиморфизм как таковой повсюду, в любом вызове метода. Но есть возможность четко контролировать интерфейсы классов, что чаще всего лучше (проверка на этапе компиляции).
Поэтому мы все только пытаемся приблизиться к идеалу, каждый новый проект делает это лучше, но с каждым новым проектом становится понятнее, что до идеала еще далеко.
Также и с логом комита. По началу кажется, что одного достаточно, потом добавляется еще что-то, он лучше структурируется и т.п. Это такой бесконечный итерационный процесс, прогресс ему имя, наверное :)
Бывает, что надо закомитить в 10 файлов связанные изменения (например, добавили в интерфейс новый метод и во всех его потомков реализацию), а бывает что эти 10 файлов лучше закомитить по отдельности, потому что каждый из 10 комитов — это отдельный этап решения задачи.
Т.е. атомарность, имхо — это очень субъективная штука.
Как-то так ;)
Но всё-таки я хочу подчеркнуть, что я говорю не о дублировании. А о документировании изменения как такового.
Могу привести пример: изменение может даже путешествовать между проектами, жить в виде патча и т.п., когда оно отделено от системы контроля версий. И лог ему нужен. И я писал про то, что лог как раз не дублирует информацию тикета, а дополняет её.
Само собой, автоматизация — трекер + VCS. Но попытка задуматься и написать нормальный лог упорядочивает программирование, вот что я хотел сказать. А копи-паст из тикета или просто ссылка на него не заставляет задуматься, это механическое действие.