Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 41
В среднем детали реализации помню в течении ~1 месяца.
Системы взаимодействия и связей, близко ~3х месяцев.
Архитектуру проекта, год и более.
В чужом коде разбираюсь быстро, в зависимости от его «говнивости». Хорошие проекты можно понять за час, тупы можно неделю теребить.
Системы взаимодействия и связей, близко ~3х месяцев.
Архитектуру проекта, год и более.
В чужом коде разбираюсь быстро, в зависимости от его «говнивости». Хорошие проекты можно понять за час, тупы можно неделю теребить.
Сроки, приблизительно как у Вас.
Да, от качества кода, понятности переменных зависит читаемость и понимаемость кода.
Сотрудник на бывшей работе уже год сейчас пытается допиливать в одиночку проект, который писался 3 людьми несколько лет без svn, почти без комментов, и весь в печали — карта зависимостей компонентов и карта БД VSтудией на core i7/8gb ram генерилась в районе полтора часа\ов.
Я ему сочувствую, документация по системе есть, но по компонентам и модулям…
Да, от качества кода, понятности переменных зависит читаемость и понимаемость кода.
Сотрудник на бывшей работе уже год сейчас пытается допиливать в одиночку проект, который писался 3 людьми несколько лет без svn, почти без комментов, и весь в печали — карта зависимостей компонентов и карта БД VSтудией на core i7/8gb ram генерилась в районе полтора часа\ов.
Я ему сочувствую, документация по системе есть, но по компонентам и модулям…
Вообще, это биология человеческой памяти, и у всех она приблизительно одинакова. Запоминание любой информации требует повторения, и если вам в течении пары месяцев не приходилось возвращаться к написанному коду(для рефакторинга/фикса/импрува), то неизбежно память начинает терять детали реалиации.
Через год, даже маститый девелопер скажет: «Да, я когда-то работал над этой фичей, но уже не помню как оно работает, — надо посмотреть код».
Так что умение запоминать код зависит не от опыта работы, а от физиологических способностей к запоминанию и количества повторений.
Через год, даже маститый девелопер скажет: «Да, я когда-то работал над этой фичей, но уже не помню как оно работает, — надо посмотреть код».
Так что умение запоминать код зависит не от опыта работы, а от физиологических способностей к запоминанию и количества повторений.
Адекватная документация — решение всех проблем!
А как правильно понимать понятия «быстро» и «долго»?
С каким абстрактным программистом все сравнивают себя?
С каким абстрактным программистом все сравнивают себя?
Код всегда хорошо читается, если он написан по принципам SOLID и без разницы чей он.
Было бы грамотными тестами покрыто, а комменты и документация — дело десятое.
ИМХО, думаю с вами не все согласятся, например если проект огромный то покрывать весь код тестами это как минимум двойная работа.
А тестировать его, по-вашему, не надо?
Огромный проект совсем без тестов — это ад, даже с комментариями и документацией. Если же речь про полное покрытие, то это, конечно, не обязательно, но небольшой набор тестов, которые покрывают ключевой функционал и основную схему работы кода, позволяет гораздо быстрее и проще разобраться в коде, чем куча комментариев (в большинстве своем устаревших, т.к. пока писали этот огромный проект и рефакторили его, старые комменты, конечно, никто не правил).
Вы не правы.
Если это сервер, к какому-то веб приложению, то разрабатывать его в сотни раз удобнее и быстрее через тестирование.
А не постоянно перезапускать, заходить в интерфейс и смотреть. Все ли правильно.
TDD может ускорить разработку в некоторых ситуациях.
Если это сервер, к какому-то веб приложению, то разрабатывать его в сотни раз удобнее и быстрее через тестирование.
А не постоянно перезапускать, заходить в интерфейс и смотреть. Все ли правильно.
TDD может ускорить разработку в некоторых ситуациях.
Не соглашусь. Тесты только для указания ошибок
Эт точно, для разбора кода «на лету», тесты не годятся. Они больше для выявления тонкостей логики конкретных мест. К примеру, недавно настраивал интегрейшен на Jenkins CI, и сотню раз приходилось лазить в исходники дженкинса и десятка плагинов, написанных разными людьми. И за это время, ни разу не посмотрел в код тестов. Только выполнял их периодически после фикса очередной баги или добавления функциональности.
Правильные названия классов/методов/переменных и енумы позволяют в большинстве случаев вполне себе обойтись без документации.
Странно, что в опросе только один ответ можно выбирать, хотя опрос и про свой код, и про чужой. Я, например, в своем коде разберусь быстро, а в чужом не так быстро, если вижу в первый раз его.
У меня как-то была ситуация когда я вообще не узнал свой собственный код, написанный относительно давно. Так что скорость разбора в своем коде зависит еще и от того, когда он был написан.
Помнится я где-то видел фразу про то, что если вы узнаете код, написанный вами год назад или даже раньше, и вы при его виде не хватаетесь за голову с мыслями «И это я такой бред написал?!», то вам срочно нужно что-то менять в этой жизни. Так что то, что старый код не узнается, — это хорошо)
А может от опытности? код, написанный фиг пойми как 5 лет назад и код, написанный полгода назад одним и тем же человеком, будет отражать уровень развития конкретного разработчика — даже полгода иногда очень большие сроки.
Помню несколько лет назад писал скрипты по администрированию — простыня кода, почти без комментариев, попытка чтения через год — приблизительный функционал ясен исключительно по названию скрипта и обрабатываемым переменным.
А сейчас функции, процедуры, модули, шаблоны, регекспы, классы и куча других страшных слов.
Даже получил сюда инвайт за статью, описывающую комплект bash скриптов, обрабатывающих видео-архив с IP камер в полностью автоматическом режиме, написанную год назад.
Помню несколько лет назад писал скрипты по администрированию — простыня кода, почти без комментариев, попытка чтения через год — приблизительный функционал ясен исключительно по названию скрипта и обрабатываемым переменным.
А сейчас функции, процедуры, модули, шаблоны, регекспы, классы и куча других страшных слов.
Даже получил сюда инвайт за статью, описывающую комплект bash скриптов, обрабатывающих видео-архив с IP камер в полностью автоматическом режиме, написанную год назад.
Простите, а это не про вас они пишут? habrahabr.ru/company/ivideon/blog/171031/
Нет, не про меня.
У меня было достаточно просто — IP камеры, распиханные по офисам, пишущие минутное видео на FTP и желание облагородить файловую структуру, ими генерируемую — с 1500 2-3-5 метровых файлов на одну камеру в сутки — до 24 файлов в сутки на камеру плюс 3х и 30 дневный архив по каждой камере на локально ftp и, соотвественно, удалённом, серверах.
У меня было достаточно просто — IP камеры, распиханные по офисам, пишущие минутное видео на FTP и желание облагородить файловую структуру, ими генерируемую — с 1500 2-3-5 метровых файлов на одну камеру в сутки — до 24 файлов в сутки на камеру плюс 3х и 30 дневный архив по каждой камере на локально ftp и, соотвественно, удалённом, серверах.
Всегда, когда пишу код, витают мысли «достаточно ли быстро я разберусь в этом коде через год». Если ответ нет, пишу комментарии до тех пор, пока не будет ответа да.
Это, конечно, относится к проектам с большим временем жизни. Одноразовых скриптов не касается
Это, конечно, относится к проектам с большим временем жизни. Одноразовых скриптов не касается
Не знаю, кому как, наверное, у меня вот .Net'овая привычка — /// комментарии к каждому классу/методу, которые потом ложатся в XML.
Да и переменные все тоже проще подписывать в комментариях.
Да и вообще, стараюсь достаточно комментировать из принципа «вдруг этот код читает серийный маньяк-убийца».
На написание одной строки коммента уходит не так много времени, а формализация иногда помогает освежить взгляд на саму конструкцию, понять что не так, оптимизировать, улучшить, дописать, отрефакторить…
Да и переменные все тоже проще подписывать в комментариях.
Да и вообще, стараюсь достаточно комментировать из принципа «вдруг этот код читает серийный маньяк-убийца».
На написание одной строки коммента уходит не так много времени, а формализация иногда помогает освежить взгляд на саму конструкцию, понять что не так, оптимизировать, улучшить, дописать, отрефакторить…
Как говорится, каждый комментарий — это неудача. Неудачное название функции, неудачная архитектура, etc.
Я запоминаю все классы и код с которым работал, но это не очень радует,
особенно когда через полгода прокручивая в голове код, понимаешь, что это полная лажа, и надо было всё делать по другому.
особенно когда через полгода прокручивая в голове код, понимаешь, что это полная лажа, и надо было всё делать по другому.
Не очень понял как вяжется заголовок топика и «ЧУЖОМ» в опросе. У меня свой только один большой проект, но работаю с ним частями, то там, то там, в принципе всё в голове есть, хватает нескольких минут что бы вспомнить что к чему (правда это зависит от общей загруженности по работе и самого мозга :)).
На самом деле читать код — ключевая фича для хорошего программиста. Читать код, без разницы свой или чужой, приходиться чаще писать или думать над ним. Так что хороший программист читает любой код. Свой или чужой — зависит от времени, как правильно отметил автор первого же коммента тут
Комментарии на самом деле это фикция в большей своей части — когда комментарии пишет автор, то они либо банальные либо такие же как и код. Лучшие комменты от ревьюера кода.
Документация тоже фикция для понимания кода, разве что архитектуру понять помогает, но это как правило либо вопрос банальный, либо такой что документация мало помогает.
Комментарии на самом деле это фикция в большей своей части — когда комментарии пишет автор, то они либо банальные либо такие же как и код. Лучшие комменты от ревьюера кода.
Документация тоже фикция для понимания кода, разве что архитектуру понять помогает, но это как правило либо вопрос банальный, либо такой что документация мало помогает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опрос. Насколько хорошо вы помните свой код?