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

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

В среднем детали реализации помню в течении ~1 месяца.
Системы взаимодействия и связей, близко ~3х месяцев.
Архитектуру проекта, год и более.

В чужом коде разбираюсь быстро, в зависимости от его «говнивости». Хорошие проекты можно понять за час, тупы можно неделю теребить.
Сроки, приблизительно как у Вас.
Да, от качества кода, понятности переменных зависит читаемость и понимаемость кода.
Сотрудник на бывшей работе уже год сейчас пытается допиливать в одиночку проект, который писался 3 людьми несколько лет без svn, почти без комментов, и весь в печали — карта зависимостей компонентов и карта БД VSтудией на core i7/8gb ram генерилась в районе полтора часа\ов.
Я ему сочувствую, документация по системе есть, но по компонентам и модулям…
Вообще, это биология человеческой памяти, и у всех она приблизительно одинакова. Запоминание любой информации требует повторения, и если вам в течении пары месяцев не приходилось возвращаться к написанному коду(для рефакторинга/фикса/импрува), то неизбежно память начинает терять детали реалиации.
Через год, даже маститый девелопер скажет: «Да, я когда-то работал над этой фичей, но уже не помню как оно работает, — надо посмотреть код».
Так что умение запоминать код зависит не от опыта работы, а от физиологических способностей к запоминанию и количества повторений.
Анализирую однажды очередной кусок кода и невольно возникает мысль «какой идиот это писал?». Открываю hg annotate — батюшки, да это же я четыре года назад сам наговнокодил )))
Адекватная документация — решение всех проблем!
Если бы
НЛО прилетело и опубликовало эту надпись здесь
А как правильно понимать понятия «быстро» и «долго»?
С каким абстрактным программистом все сравнивают себя?

Долго, это когда начинаем вчитываться в каждую строку что бы понять логику.
В остальных случаях быстро
Код всегда хорошо читается, если он написан по принципам SOLID и без разницы чей он.
Было бы грамотными тестами покрыто, а комменты и документация — дело десятое.
ИМХО, думаю с вами не все согласятся, например если проект огромный то покрывать весь код тестами это как минимум двойная работа.
А тестировать его, по-вашему, не надо?
Товарищ пере читайте мой комментарий еще разок, я там писал про покрытие ВСЕГО кода тестами.
У вас в проекте есть код, который тестировать не надо?
Third-party компоненты?
Их надо тестировать в первую очередь — проверять, что они делают то, что вы думаете. Всё остальное и так под контролем.
Это обычно не код, а компоненты. Но в любом случае это все неплохо бы покрыть интеграционными тестами, чтобы быть уверенным, что оно работает правильно.
Проблема в том что надо не тестировать код, который вы только что написали, а разрабатывать через тестирование, тогда двойной работы не будет, ага ;)
Огромный проект совсем без тестов — это ад, даже с комментариями и документацией. Если же речь про полное покрытие, то это, конечно, не обязательно, но небольшой набор тестов, которые покрывают ключевой функционал и основную схему работы кода, позволяет гораздо быстрее и проще разобраться в коде, чем куча комментариев (в большинстве своем устаревших, т.к. пока писали этот огромный проект и рефакторили его, старые комменты, конечно, никто не правил).
Я это и имел в виду! И не в коем случае не писал что ненужно использовать тесты.
Тесты должны быть в нужных/важных месах проекта!
Вы не правы.
Если это сервер, к какому-то веб приложению, то разрабатывать его в сотни раз удобнее и быстрее через тестирование.
А не постоянно перезапускать, заходить в интерфейс и смотреть. Все ли правильно.

TDD может ускорить разработку в некоторых ситуациях.
Не соглашусь. Тесты только для указания ошибок
Эт точно, для разбора кода «на лету», тесты не годятся. Они больше для выявления тонкостей логики конкретных мест. К примеру, недавно настраивал интегрейшен на Jenkins CI, и сотню раз приходилось лазить в исходники дженкинса и десятка плагинов, написанных разными людьми. И за это время, ни разу не посмотрел в код тестов. Только выполнял их периодически после фикса очередной баги или добавления функциональности.
Правильные названия классов/методов/переменных и енумы позволяют в большинстве случаев вполне себе обойтись без документации.
Досталась как то «Самодокументированная» библиотека. Количество WTF, было больше чем после Sharepoint
в догонку веселые приколы по поводу даже документированного кода:

player.src = «bell.wav»;
player.play();
player.play();

player.src = «bell.wav»;
player.play();
player.src = «bell.wav»;
player.play();

Первый пример проигрывает звук 1 раз, а 2й 2 раза
Странно, что в опросе только один ответ можно выбирать, хотя опрос и про свой код, и про чужой. Я, например, в своем коде разберусь быстро, а в чужом не так быстро, если вижу в первый раз его.
У меня как-то была ситуация когда я вообще не узнал свой собственный код, написанный относительно давно. Так что скорость разбора в своем коде зависит еще и от того, когда он был написан.
Помнится я где-то видел фразу про то, что если вы узнаете код, написанный вами год назад или даже раньше, и вы при его виде не хватаетесь за голову с мыслями «И это я такой бред написал?!», то вам срочно нужно что-то менять в этой жизни. Так что то, что старый код не узнается, — это хорошо)
Чаще бывает «неужели я уже тогда это предусмотрел?»
А может от опытности? код, написанный фиг пойми как 5 лет назад и код, написанный полгода назад одним и тем же человеком, будет отражать уровень развития конкретного разработчика — даже полгода иногда очень большие сроки.

Помню несколько лет назад писал скрипты по администрированию — простыня кода, почти без комментариев, попытка чтения через год — приблизительный функционал ясен исключительно по названию скрипта и обрабатываемым переменным.

А сейчас функции, процедуры, модули, шаблоны, регекспы, классы и куча других страшных слов.
Даже получил сюда инвайт за статью, описывающую комплект bash скриптов, обрабатывающих видео-архив с IP камер в полностью автоматическом режиме, написанную год назад.
Нет, не про меня.
У меня было достаточно просто — IP камеры, распиханные по офисам, пишущие минутное видео на FTP и желание облагородить файловую структуру, ими генерируемую — с 1500 2-3-5 метровых файлов на одну камеру в сутки — до 24 файлов в сутки на камеру плюс 3х и 30 дневный архив по каждой камере на локально ftp и, соотвественно, удалённом, серверах.
Всегда, когда пишу код, витают мысли «достаточно ли быстро я разберусь в этом коде через год». Если ответ нет, пишу комментарии до тех пор, пока не будет ответа да.

Это, конечно, относится к проектам с большим временем жизни. Одноразовых скриптов не касается
Не знаю, кому как, наверное, у меня вот .Net'овая привычка — /// комментарии к каждому классу/методу, которые потом ложатся в XML.
Да и переменные все тоже проще подписывать в комментариях.
Да и вообще, стараюсь достаточно комментировать из принципа «вдруг этот код читает серийный маньяк-убийца».
На написание одной строки коммента уходит не так много времени, а формализация иногда помогает освежить взгляд на саму конструкцию, понять что не так, оптимизировать, улучшить, дописать, отрефакторить…
Как говорится, каждый комментарий — это неудача. Неудачное название функции, неудачная архитектура, etc.
Я запоминаю все классы и код с которым работал, но это не очень радует,
особенно когда через полгода прокручивая в голове код, понимаешь, что это полная лажа, и надо было всё делать по другому.
А скилл прокачал очень просто, раньше отладчики были не так круты как сейчас, и чтобы разобраться в коде, проще было помедитировать ним.
Не очень понял как вяжется заголовок топика и «ЧУЖОМ» в опросе. У меня свой только один большой проект, но работаю с ним частями, то там, то там, в принципе всё в голове есть, хватает нескольких минут что бы вспомнить что к чему (правда это зависит от общей загруженности по работе и самого мозга :)).
На самом деле читать код — ключевая фича для хорошего программиста. Читать код, без разницы свой или чужой, приходиться чаще писать или думать над ним. Так что хороший программист читает любой код. Свой или чужой — зависит от времени, как правильно отметил автор первого же коммента тут
Комментарии на самом деле это фикция в большей своей части — когда комментарии пишет автор, то они либо банальные либо такие же как и код. Лучшие комменты от ревьюера кода.
Документация тоже фикция для понимания кода, разве что архитектуру понять помогает, но это как правило либо вопрос банальный, либо такой что документация мало помогает.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории