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

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

Не сомневаюсь, что частенько у Вас бывает поток мыслей о том, что необходимо исправить в разных участках кода. Для этого лучше все записывать. В конце рабочего дня это будет хорошим подспорьем.

Помечать удобнее прямо в коде, я себе добавил .git/hooks/pre-commit который не дает коммитить если найдет «FIXME» в добавленных строках:

#!/bin/sh
git diff --cached | grep ^+ | grep FIXME --color && echo "You probably didn't want to commit these lines, otherwise use \"git commit -n\" to avoid this check" && exit 1

Необходимо также chmod +x .git/hooks/pre-commit
Забыл, последней строчкой должно быть exit 0, а то может не дать коммитить
При работе с унаследованным или чужим кодом главные задачи:
1. Не навредить. Здесь на помощь приходяд VCS типа git-svn.
2. Осознать. Нужно понять что делает код. Для этого нужно бы его визуализировать, нарисовать uml диаграми, задокументировать и т.д.
3. Главное помнить, что вы не самый умный и не обязательно умнее автора кода. Поэтому правки нужно вносить очень осторожно, не нарушив пункт 1. Для этого изменения должны быть минимальными затрагивающими только одну задачу и завершенными коммитами, которые всегда можно откатить.
4. Не сотворите хаус — все ваши правки и новые фичи должны быть привязанными к тиккет системе. чтобы по номеру в коммите можно было посмотреть тиккет и для чего эти правки вносились.

Это пока всё что вспомнилось сходу.
>Не сотворите хаус

:D
2. Осознать. Нужно понять что делает код. Для этого нужно бы его визуализировать, …

Дебаггер FTW!
А если серьёзно — часто бывают неочевидные на первый взгляд конструкции. Запустить дебаггер и протрейсить всё, что интересует — самый правильный способ.
Хорошо покрытый тестами проект и проблем с чтением чужого кода просто не возникнет.
Хи, вы не видели хорошо покрытый тестами говнокод, в отличие от непокрытого — нужно еще разбираться с тем как работают длиннющие тесты, с длиннющими избыточными фикстурами :)
Как, а вы не знали о суперстарых и суперсовременных методологиях разработки?
Встречайте:
* Debug Driven Development.
* Brain Fuck Driven Development
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории