Мертвый код Откуда взялся этот мертвый код? Это, друг мой, вопрос вопросов CowmitStrip.com / программирование :: commitstrip :: программист :: it :: Смешные комиксы (веб-комиксы с юмором и их переводы)
Подробнее
Мертвый код
Откуда взялся этот мертвый код?
Это, друг мой, вопрос вопросов
CowmitStrip.com
commitstrip,Смешные комиксы,веб-комиксы с юмором и их переводы,программирование,it,программист,песочница
Все знают, как бороться с этим, но один хер с этим всё время встречаешься.
Хотя, кстати, я не понимаю, чем контроль версий и комментарии поможет от кусков мёртвого кода, который даже не всегда сразу понятно, что мёртвый. И в итоге ты сидишь и просто построчно разбираешь сраный код. От этого могут помочь только постоянные ревизии кода тимлидом с последующим раздаванием пиздюлей.
ну я имел в виду не только мертвый код. Просто такая помощь поможет другому человек быстрее разобраться в твоем коде если ты наплевав на свою лень возьмешь за дело заливать на репозиторий новые фрагменты кода попутно комментируя непонятные участки и записывая что ты сделал/нового добавил.
В том-то и проблема, что мёртвый код может свести на нет пользу от комментариев. Вроде бы всё прокомментировано, всё понятно, но на первый взгляд ты видишь одну логику, а на самом деле всё идёт совершенно по другому сценарию. И пока ты это выяснишь, и доберёшься до сути, будет потрачено много времени и сил. Порой в разы больше, чем занимает сам задача.
А так ты, безусловно, прав - говнокодера из себя надо выдавливать по капле, как и жлоба. Только далеко не все так поступают, не всем хватает ответственности и силы воли. Да что уж говорить, все мы нет-нет да и грешим этим. Но вот в текущем проекте я с чистой совестью могу сказать, что за полгода у меня таких кусков не было ни одного, или я их исправлял потом в течение нескольких дней.
sadt dfd диаграммы не вопрос (очень помогает понять как все должно работать) Но блок схемы!? ты дунул? какими средствами(есть проги но все равно все ручками) ты будишь код от пятисот(как пример) функциональных элементов зарисовывать(не спорю что можно но ты найди того человека кто это согласится делать(и найди того человека кто будет пытаться эту паутину понять))
Блок-схемы пользуют, но только в сложной бизнес математике. Лично, за последние полгода, писал алгоритмы по блок схемам, которые аналитики сделали. Еще немного блок-схем при разработке архитектуры приложения, сам делаю иногда. Но, конечно же, как ответили выше, весь код блок схемами никто уже не покрывает. Не выгодно. Вместо этого мутят юнит-тесты, чтобы работало все так, как надо.
Я пользуюсь чем-то типа блок-схем, когда совсем какой-то сложный кусок, логика которого целиком в голову не умещается. Недавно вот надо было замутить автозвонилку сотрудникам по заказам, и дело осложнялось кучей условий у сотрудников - эти работают день через два, эти неделя через неделю, эти только днём, эти днём и ночью, но только по чётным неделям, а по нечётным только днём, но в выходные всё равно и днём и ночью, и т.д. и т.п. Плюс заказы бывают разные, и в зависимости от срочности, даты исполнения заказа и его типа надо было вносить коррективы. И всё это без чёткого ТЗ, с постоянно выясняющимися подробностями, которые ломали буквально всё.
Без бумажки у меня голова кипеть начинала, особенно учитывая, что пропустить нужный звонок чревато нехилой неустойкой, а в случае критической проблемы надо было звонить самому главному директору, а если ему посыпятся лишние звонки в 3 часа ночи, за это тоже можно отхватить пиздюлей. А на бумажке нарисовал, и как-то за вечерок всё сделалось.
Много комментариев != читаемость. Читал на хабре статью-мнение, что написание комментария к коду можно считать своим проиграшом, ибо твой код нельзя понять просто из названий методов/переменных.
Лично я на практике встречал много TODO, которые жили... много. Да чего уж там, сам их леплю, дабы не забыть зачем этот участок существует.
Насчет мертвого кода: очень часто он появляется после десятков рефакторингов. Т.е. был метод сортировки, его постепенно вытеснил другой, но старый не убирали т.к. он использовался. И вот этот момент пропажи всех референсов сложно уловить. Особенно когда в проекте часто сменяемые кодеры.
Да, не до конца выполненный рефакторинг - порой хуже, чем вообще никакого.
А мёртвый код появляется даже просто когда понимаешь, что текущее решение не соответствует требованиям, или возникают новые требования, и вот программист смотрит на метод в пару сотен строк и ему во-первых лень, а во-вторых страшно трогать её целиком, особенно, если писал её не он или давно. Да и времени на задачу не всегда хватает, сроки горят, и нет никакой возможности писать с нуля и всё везде тестить и подгонять.
>>Да, не до конца выполненный рефакторинг - порой хуже, чем вообще никакого.
Не уверен. Скорее просто убивает дальнейшую сопровождаемость т.к. рефекторинг на скорую как правило убивает дальнейшую сопровождаемость. Ну или еще не сталкивался с примером, когда так лучше не делать.
>>лень
>>страшно трогать
>>сроки горят
можно добавить "первый раз вижу этот код и хз как работает"
>рефекторинг на скорую как правило убивает дальнейшую сопровождаемость
Ну так о том и речь, рефакторинг вроде выполнен, но у тебя есть куски, дублирующие функционал, и, когда кому-то потом нужно будет внести в этот функционал изменения, ему придется править в двух местах, а ещё надо выяснить - в каких местах это используется, потестить, наткнуться на новые косяки... А когда в это место полезут в третий раз, проще будет просто застрелиться или уже тупо взять и довести рефактор до конца - вычленить все обращения к старому методу, переписать их под новый метод, опять-таки всё протестить. Но ведь никто так не будет делать, у тебя времени и так в обрез, а фронтэндщик тебя нахер пошлёт, когда ты ему скажешь, сколько всего править придется, да и не доплачивают тебе за сверхурочные, и потому ты опять просто кое-как подправишь то, что уже есть и пойдешь пилить дальше.
>можно добавить "первый раз вижу этот код и хз как работает"
Ну это и имело в виду под "страшно трогать". И порой это относится и к своему коду, написанному год назад.
Работаю над проектом, который активно изменяется уже 20 лет. В коде есть места, которые были закомментированы еще в 1999 году. До сих пор не пригодилось.
У нас ежедневно используется модуль на фортране, который дописывается и поддерживается со времён перфокарт (некоторые части до сих пор остались с тех времён). Шарит в исходниках этого приложения у нас только один человек уже сильно пенсионного возраста и что мы будем делать после того как он нас покинет - хз. Там не бутылка и не ящик нужны, чтобы разобраться во всех этих коммон блоках и миллионе go to, а целая цистерна спирта по-моему.
з.ы. тут у меня родилась идея программы, которая выпиливает кусок кода и проверяет прохождение тестов. Хотя да, для этого нужны очень (я бы сказал - слишком) всесторонние тесты.
Хотя, кстати, я не понимаю, чем контроль версий и комментарии поможет от кусков мёртвого кода, который даже не всегда сразу понятно, что мёртвый. И в итоге ты сидишь и просто построчно разбираешь сраный код. От этого могут помочь только постоянные ревизии кода тимлидом с последующим раздаванием пиздюлей.
А так ты, безусловно, прав - говнокодера из себя надо выдавливать по капле, как и жлоба. Только далеко не все так поступают, не всем хватает ответственности и силы воли. Да что уж говорить, все мы нет-нет да и грешим этим. Но вот в текущем проекте я с чистой совестью могу сказать, что за полгода у меня таких кусков не было ни одного, или я их исправлял потом в течение нескольких дней.
Без бумажки у меня голова кипеть начинала, особенно учитывая, что пропустить нужный звонок чревато нехилой неустойкой, а в случае критической проблемы надо было звонить самому главному директору, а если ему посыпятся лишние звонки в 3 часа ночи, за это тоже можно отхватить пиздюлей. А на бумажке нарисовал, и как-то за вечерок всё сделалось.
Лично я на практике встречал много TODO, которые жили... много. Да чего уж там, сам их леплю, дабы не забыть зачем этот участок существует.
Насчет мертвого кода: очень часто он появляется после десятков рефакторингов. Т.е. был метод сортировки, его постепенно вытеснил другой, но старый не убирали т.к. он использовался. И вот этот момент пропажи всех референсов сложно уловить. Особенно когда в проекте часто сменяемые кодеры.
А мёртвый код появляется даже просто когда понимаешь, что текущее решение не соответствует требованиям, или возникают новые требования, и вот программист смотрит на метод в пару сотен строк и ему во-первых лень, а во-вторых страшно трогать её целиком, особенно, если писал её не он или давно. Да и времени на задачу не всегда хватает, сроки горят, и нет никакой возможности писать с нуля и всё везде тестить и подгонять.
Не уверен. Скорее просто убивает дальнейшую сопровождаемость т.к. рефекторинг на скорую как правило убивает дальнейшую сопровождаемость. Ну или еще не сталкивался с примером, когда так лучше не делать.
>>лень
>>страшно трогать
>>сроки горят
можно добавить "первый раз вижу этот код и хз как работает"
Ну так о том и речь, рефакторинг вроде выполнен, но у тебя есть куски, дублирующие функционал, и, когда кому-то потом нужно будет внести в этот функционал изменения, ему придется править в двух местах, а ещё надо выяснить - в каких местах это используется, потестить, наткнуться на новые косяки... А когда в это место полезут в третий раз, проще будет просто застрелиться или уже тупо взять и довести рефактор до конца - вычленить все обращения к старому методу, переписать их под новый метод, опять-таки всё протестить. Но ведь никто так не будет делать, у тебя времени и так в обрез, а фронтэндщик тебя нахер пошлёт, когда ты ему скажешь, сколько всего править придется, да и не доплачивают тебе за сверхурочные, и потому ты опять просто кое-как подправишь то, что уже есть и пойдешь пилить дальше.
>можно добавить "первый раз вижу этот код и хз как работает"
Ну это и имело в виду под "страшно трогать". И порой это относится и к своему коду, написанному год назад.
з.ы. тут у меня родилась идея программы, которая выпиливает кусок кода и проверяет прохождение тестов. Хотя да, для этого нужны очень (я бы сказал - слишком) всесторонние тесты.