Как стать автором
Обновить

Комментарии 43

А Вы выставляете номера задач из багтрекера? Если нет, то рекомендую и их указывать.
Хорошая идея. Слава богу у нас не bug-driven разработка, пока не актуально.
Обязательно применю, когда появится смысл в баг-треккере.
В смысле нету баг-трекера? Вы реально «пишете без багов»?
Тьфу тьфу. Пока да.
Нет обнаруженных багов.
Проекты менее 5000 строк.
А если найду? :)
Будете экстрасенсом, ведь наша работа пока в секрете.
А багов нет — тк нет пока клиентов.
А все остальное исправляется в «эту же секунду»
Т.е. тестеров тоже нету, я правильно понял?
так точно, но я не хотел бы отходить так далеко от темы.
Компания маленькая.
Нет клиентов — нет багов.
так в баг-трекере не только баги пишутся, но и фичи
Фичи пишутся в mind-map, которая хранится также в репозитории.
Баги тоже пока там хранятся.
Простите, но как вы управляете задачами?
WorkSection.
Назначаю ответственного за подсистему и вперед.
Нет, речь немного о другом — как вы составляете список задач, как отслеживаете их выполнение, как убеждаетесь, что никакие задачи не забыли выполнить и что они выполнены правильно?
Я лично этим не занимаюсь.
Я говорю что мне нужно, а ответственный сам ставит эти задачи.
Записываем все на клейкие бумажки у мониторов.)
Т.е. я правильно понимаю, что задачи не фиксируете, и никак не проверяете точность их выполнения, равно как и вообще сам факт выполнения? И если предположить, что какая-то из клейких бумажек отвалится с монитора и будет выброшена уборщицей — вы сможете установить факт этого только случайно?
Чтобы узнать, затронули ли вас изменения — нужно запустить тесты.
Увы по бюджету и идеологии мы не можем обеспечить 100% покрытие.
Да и тут больше суть «стоит ли мне просматривать внимательно что произошло или можно проигноривать».
100% покрытие никто не может обеспечить, потому покрывают только то, что вам важно :-)

Так или иначе — тесты достовернее комментариев и процесса, в который с обеих стороны вовлечены люди: один пишет комментарии, другой их читает и помнит все зависимости своего кода.
Я не предлагал исключить тесты. Не занимайтесь анонизмом.
*Не плодите сущностей.
Обьясните, тот кто поставил минус. Чем руководствовался?

Не обеспечивают достаточного покрытия — ууу минусуем?
Наверное, потому что вы пригаете в крайности. Отсутствие возможности 100% покрытие не указызает на то, что тесты писать не нужно. Тем более речь идёт о регресивных тестах, которые писать столько же. сколько времени тратится на 1-2 проверки руками.

Вы настолько экономите на спичках, что в итоге будете мёрзнуть, потому что спичек вовсе не окажется под рукой.
>>Обьясните, тот кто поставил минус. Чем руководствовался?
А что конкретно случилось от того что Вам наминусовали? Доход компании упал? Может зарплата понизилась? Я к тому что не зачем париться из-за кол-ва каких-то плюсов\минусов. В любом случае самой адекватной кармой Вам будет продажи Вашего продукта. Если никакие, то и карма у Вас низкая, если серьезные, то Вам на карму вообще будет пофиг ибо заботы будут другие, к примеру «как бы на миллиарды выйти».
Занимайтесь делом, а не следите за кол-вом кармы или плюсов.
Почему не писать целиком?
Это пример который мне лень было расписывать.
А слова лучше заменять на символы, что бы интуитивно выделять то что важно сейчас.
Такое кодирование уже встречал когда-то всё. Кажется везде уже отмерло, но в вашем мире эволюционировало :)

Ваш код подменяет человеческий язык, а не расширяет его. Думаю это главная причина по которым будет трудно его реанимировать. Текст должен быть для людей, а код для машин. Почему markdown приживается лучше bbcode/html — а потому что его уже все знают, как писатели так и читатели.

Впрочем, отчасти эта проблема решилась бы если добавлять расшифровку символов зразу за ними (* починил..., ~ отрефакторил… и т.д.), но кажется у вас цель как раз в убирании избыточности.

— Эксепшены которые не подразумевают аварийное завершение программы
~ Методы константные по логике — стали такими
* Потеря памяти при переопределении чего то там
% Теперь есть fatal_exception и operation_fail

Второй жирный минус: сообщения в таком роде поощряют ориентацию на процесс (рефакторинга, оптимизации, разделения, ветвления и т.п.), а не на результат. В идеале каждый коммит должен решать business-valueable задачу. Условно говоря так, чтобы `git log --no-merges 1.0..2.0` можно было скопировать в «what's new in 2.0». Я не про то, что там непонятные символы, я про «нечленораздельные» изменения.

буду очень рад если мне предложат еще какие идеи

Идея простая: до стабильного релиза комитьте как и что угодно, а потом избавляйтесь от всех символов кроме + − и *. Делайте то, что нужно пользователями (через рефакторинг где надо), а не то что нужно девелоперам. Коммит (не локальный, в общую ветвь) должен фиксировать достижение какой-либо цели. Главное — ставить правильные цели до (иметь «приземленного» PM, или кого-то в роли него), а не шифровать целесообразность потраченного времени пост-фактум (см. закон Паркинсона).
Я бы предложил набрать в консоли…

$ hg help diff

… и ознакомиться с выводом, но это было бы дерзко и неуважительно с моей стороны поэтому я просто тихо поржу. Без условно у вас там своя атмосфера.

Проекты менее 5000 строк.

Это типа такие?

<?= "Hellow World!" ?>

Как раз меньше 5000 строк. Я гарантирую это.
Пост был специально для тех кто считает diff-way нерациональным.
Верхняя граница указана для того что бы показать уровень сложности систем.

Все остальное зависит от ваших психических отклонений.
Ваш кэп.
Если, как вы говорите, команда маленькая и кода не очень много, то просмотр диффов явно весьма рационален.
Если один коммит несет в себе множество рефактор изменений.
Скажите навскидку, за 10 секунд, какие изменения сделали модуль несовместимым и затрагивает ли это вас?
Я бы выделил больше 10 секунд на то, чтобы просто быть в курсе того, что в проекте происходит. А совместимо или нет — для этого тесты существуют, как вам выше уже писали.
Если один коммит несёт в себе множество изменений, заявленных как рефакторинг, но при этом таких, что они могу сделать модуль несовместимым, то первое, что я сделаю — это объясню закоммитевшему смысл слова «рефакторинг» (внесение изменений, не меняющих поведение и при этом улучшающих структуру программы или модуля). Второе, что я сделаю — это объясню, что каждый коммит должен быть минимальным (и, разумеется, не нарушающим целостность программы и при этом имеющим отдельную ценность). При этом любые рефакторинги должны идти отдельными коммитами, равно как и исправления стиля, опечаток и т.д.
Это ж brainfuck какой-то :)
Скажите, в коде вы тоже применяете сокращения? Ну там, m() вместо main(), t вместо transactionDetails и т.д.?))))))

И еще мне интересно, сколько времени вы сэкономили на этих закорючках. Ну, по сравнению со временем, потраченным на хабр и прочие интернеты.
Так посмотрите — «О себе: Страстно люблю оптимизации там где они требуются.» :)

«Прекрасная мысль. Полыхаев» (с)
pansa, спасибо. Я если честно устал отбиваться от нападков.
Нам как команде это удобно, решил поделиться с «миром».
Разочарую вас — это был сарказм. Цитата была из Золотого теленка, товарищ Полыхаев тоже любил оптимизировать, вы мне его и напомнили.
Я считаю ваш подход неправильным и неоправданным.
Мне нравятся такие вот обозначения: «New», «Fixed», «Refactored», «Optmized». Возможно они длиннее, но явно понятнее(особенно, когда появляется новый человек в команде). Например, «Fixed messages grid paginator», «Optmized email processing»(или «Fixed: messages grid paginator», «Optmized: email processing»), мне кажется, что это ж просто замечательно.

Если слишком накладно писать руками, то можно просто написать макрос, который будет менять значки на вразумительные слова.
Мы маленькая команда, и новички у нас появляются очень редко. Ваше замечание обосновнанно.
Но вы попробуйте, спустя месяц разработки эти символы становятся синонимами. Глядя на статус проекта в смс(где собираются только имена подсистем и общие флаги), вы можете узнать стоит ли вам обновляться/готова ли та часть что вам нужна.
Ну тут просто — главное, чтобы удобно было работать с этими сокращениями всей команде и чтобы единый подход использовался во всех проектах, над которыми работает команда.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории