Pull to refresh

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

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

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

Если слишком накладно писать руками, то можно просто написать макрос, который будет менять значки на вразумительные слова.
Мы маленькая команда, и новички у нас появляются очень редко. Ваше замечание обосновнанно.
Но вы попробуйте, спустя месяц разработки эти символы становятся синонимами. Глядя на статус проекта в смс(где собираются только имена подсистем и общие флаги), вы можете узнать стоит ли вам обновляться/готова ли та часть что вам нужна.
Ну тут просто — главное, чтобы удобно было работать с этими сокращениями всей команде и чтобы единый подход использовался во всех проектах, над которыми работает команда.
UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.