Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 43
А Вы выставляете номера задач из багтрекера? Если нет, то рекомендую и их указывать.
Хорошая идея. Слава богу у нас не bug-driven разработка, пока не актуально.
Обязательно применю, когда появится смысл в баг-треккере.
Обязательно применю, когда появится смысл в баг-треккере.
В смысле нету баг-трекера? Вы реально «пишете без багов»?
так в баг-трекере не только баги пишутся, но и фичи
Простите, но как вы управляете задачами?
WorkSection.
Назначаю ответственного за подсистему и вперед.
Назначаю ответственного за подсистему и вперед.
Нет, речь немного о другом — как вы составляете список задач, как отслеживаете их выполнение, как убеждаетесь, что никакие задачи не забыли выполнить и что они выполнены правильно?
Чтобы узнать, затронули ли вас изменения — нужно запустить тесты.
Увы по бюджету и идеологии мы не можем обеспечить 100% покрытие.
Да и тут больше суть «стоит ли мне просматривать внимательно что произошло или можно проигноривать».
100% покрытие никто не может обеспечить, потому покрывают только то, что вам важно :-)
Так или иначе — тесты достовернее комментариев и процесса, в который с обеих стороны вовлечены люди: один пишет комментарии, другой их читает и помнит все зависимости своего кода.
Так или иначе — тесты достовернее комментариев и процесса, в который с обеих стороны вовлечены люди: один пишет комментарии, другой их читает и помнит все зависимости своего кода.
Обьясните, тот кто поставил минус. Чем руководствовался?
Не обеспечивают достаточного покрытия — ууу минусуем?
Не обеспечивают достаточного покрытия — ууу минусуем?
Наверное, потому что вы пригаете в крайности. Отсутствие возможности 100% покрытие не указызает на то, что тесты писать не нужно. Тем более речь идёт о регресивных тестах, которые писать столько же. сколько времени тратится на 1-2 проверки руками.
Вы настолько экономите на спичках, что в итоге будете мёрзнуть, потому что спичек вовсе не окажется под рукой.
Вы настолько экономите на спичках, что в итоге будете мёрзнуть, потому что спичек вовсе не окажется под рукой.
>>Обьясните, тот кто поставил минус. Чем руководствовался?
А что конкретно случилось от того что Вам наминусовали? Доход компании упал? Может зарплата понизилась? Я к тому что не зачем париться из-за кол-ва каких-то плюсов\минусов. В любом случае самой адекватной кармой Вам будет продажи Вашего продукта. Если никакие, то и карма у Вас низкая, если серьезные, то Вам на карму вообще будет пофиг ибо заботы будут другие, к примеру «как бы на миллиарды выйти».
Занимайтесь делом, а не следите за кол-вом кармы или плюсов.
А что конкретно случилось от того что Вам наминусовали? Доход компании упал? Может зарплата понизилась? Я к тому что не зачем париться из-за кол-ва каких-то плюсов\минусов. В любом случае самой адекватной кармой Вам будет продажи Вашего продукта. Если никакие, то и карма у Вас низкая, если серьезные, то Вам на карму вообще будет пофиг ибо заботы будут другие, к примеру «как бы на миллиарды выйти».
Занимайтесь делом, а не следите за кол-вом кармы или плюсов.
Почему не писать целиком?
Такое кодирование уже встречал когда-то всё. Кажется везде уже отмерло, но в вашем мире эволюционировало :)
Ваш код подменяет человеческий язык, а не расширяет его. Думаю это главная причина по которым будет трудно его реанимировать. Текст должен быть для людей, а код для машин. Почему markdown приживается лучше bbcode/html — а потому что его уже все знают, как писатели так и читатели.
Впрочем, отчасти эта проблема решилась бы если добавлять расшифровку символов зразу за ними (* починил..., ~ отрефакторил… и т.д.), но кажется у вас цель как раз в убирании избыточности.
Второй жирный минус: сообщения в таком роде поощряют ориентацию на процесс (рефакторинга, оптимизации, разделения, ветвления и т.п.), а не на результат. В идеале каждый коммит должен решать business-valueable задачу. Условно говоря так, чтобы `git log --no-merges 1.0..2.0` можно было скопировать в «what's new in 2.0». Я не про то, что там непонятные символы, я про «нечленораздельные» изменения.
Идея простая: до стабильного релиза комитьте как и что угодно, а потом избавляйтесь от всех символов кроме + − и *. Делайте то, что нужно пользователями (через рефакторинг где надо), а не то что нужно девелоперам. Коммит (не локальный, в общую ветвь) должен фиксировать достижение какой-либо цели. Главное — ставить правильные цели до (иметь «приземленного» PM, или кого-то в роли него), а не шифровать целесообразность потраченного времени пост-фактум (см. закон Паркинсона).
Ваш код подменяет человеческий язык, а не расширяет его. Думаю это главная причина по которым будет трудно его реанимировать. Текст должен быть для людей, а код для машин. Почему markdown приживается лучше bbcode/html — а потому что его уже все знают, как писатели так и читатели.
Впрочем, отчасти эта проблема решилась бы если добавлять расшифровку символов зразу за ними (* починил..., ~ отрефакторил… и т.д.), но кажется у вас цель как раз в убирании избыточности.
— Эксепшены которые не подразумевают аварийное завершение программы
~ Методы константные по логике — стали такими
* Потеря памяти при переопределении чего то там
% Теперь есть fatal_exception и operation_fail
Второй жирный минус: сообщения в таком роде поощряют ориентацию на процесс (рефакторинга, оптимизации, разделения, ветвления и т.п.), а не на результат. В идеале каждый коммит должен решать business-valueable задачу. Условно говоря так, чтобы `git log --no-merges 1.0..2.0` можно было скопировать в «what's new in 2.0». Я не про то, что там непонятные символы, я про «нечленораздельные» изменения.
буду очень рад если мне предложат еще какие идеи
Идея простая: до стабильного релиза комитьте как и что угодно, а потом избавляйтесь от всех символов кроме + − и *. Делайте то, что нужно пользователями (через рефакторинг где надо), а не то что нужно девелоперам. Коммит (не локальный, в общую ветвь) должен фиксировать достижение какой-либо цели. Главное — ставить правильные цели до (иметь «приземленного» PM, или кого-то в роли него), а не шифровать целесообразность потраченного времени пост-фактум (см. закон Паркинсона).
Я бы предложил набрать в консоли…
… и ознакомиться с выводом, но это было бы дерзко и неуважительно с моей стороны поэтому я просто тихо поржу. Без условно у вас там своя атмосфера.
Это типа такие?
Как раз меньше 5000 строк. Я гарантирую это.
$ hg help diff
… и ознакомиться с выводом, но это было бы дерзко и неуважительно с моей стороны поэтому я просто тихо поржу. Без условно у вас там своя атмосфера.
Проекты менее 5000 строк.
Это типа такие?
<?= "Hellow World!" ?>
Как раз меньше 5000 строк. Я гарантирую это.
Если, как вы говорите, команда маленькая и кода не очень много, то просмотр диффов явно весьма рационален.
Если один коммит несет в себе множество рефактор изменений.
Скажите навскидку, за 10 секунд, какие изменения сделали модуль несовместимым и затрагивает ли это вас?
Скажите навскидку, за 10 секунд, какие изменения сделали модуль несовместимым и затрагивает ли это вас?
Я бы выделил больше 10 секунд на то, чтобы просто быть в курсе того, что в проекте происходит. А совместимо или нет — для этого тесты существуют, как вам выше уже писали.
Если один коммит несёт в себе множество изменений, заявленных как рефакторинг, но при этом таких, что они могу сделать модуль несовместимым, то первое, что я сделаю — это объясню закоммитевшему смысл слова «рефакторинг» (внесение изменений, не меняющих поведение и при этом улучшающих структуру программы или модуля). Второе, что я сделаю — это объясню, что каждый коммит должен быть минимальным (и, разумеется, не нарушающим целостность программы и при этом имеющим отдельную ценность). При этом любые рефакторинги должны идти отдельными коммитами, равно как и исправления стиля, опечаток и т.д.
Это ж brainfuck какой-то :)
Скажите, в коде вы тоже применяете сокращения? Ну там, m() вместо main(), t вместо transactionDetails и т.д.?))))))
И еще мне интересно, сколько времени вы сэкономили на этих закорючках. Ну, по сравнению со временем, потраченным на хабр и прочие интернеты.
И еще мне интересно, сколько времени вы сэкономили на этих закорючках. Ну, по сравнению со временем, потраченным на хабр и прочие интернеты.
Мне нравятся такие вот обозначения: «New», «Fixed», «Refactored», «Optmized». Возможно они длиннее, но явно понятнее(особенно, когда появляется новый человек в команде). Например, «Fixed messages grid paginator», «Optmized email processing»(или «Fixed: messages grid paginator», «Optmized: email processing»), мне кажется, что это ж просто замечательно.
Если слишком накладно писать руками, то можно просто написать макрос, который будет менять значки на вразумительные слова.
Если слишком накладно писать руками, то можно просто написать макрос, который будет менять значки на вразумительные слова.
Мы маленькая команда, и новички у нас появляются очень редко. Ваше замечание обосновнанно.
Но вы попробуйте, спустя месяц разработки эти символы становятся синонимами. Глядя на статус проекта в смс(где собираются только имена подсистем и общие флаги), вы можете узнать стоит ли вам обновляться/готова ли та часть что вам нужна.
Но вы попробуйте, спустя месяц разработки эти символы становятся синонимами. Глядя на статус проекта в смс(где собираются только имена подсистем и общие флаги), вы можете узнать стоит ли вам обновляться/готова ли та часть что вам нужна.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Систематизация коммитов