Подробнее
Мертвый код Откуда взялся этот мертвый код? Это, друг мой, вопрос вопросов CowmitStrip.com
commitstrip,Смешные комиксы,веб-комиксы с юмором и их переводы,программирование,it,программист,песочница
Еще на тему
commitstrip Комиксы программирование it программист песочница
Подробнее
Мертвый код Откуда взялся этот мертвый код? Это, друг мой, вопрос вопросов CowmitStrip.com
commitstrip,Смешные комиксы,веб-комиксы с юмором и их переводы,программирование,it,программист,песочница
Подробнее
Мертвый код Откуда взялся этот мертвый код? Это, друг мой, вопрос вопросов CowmitStrip.com
commitstrip,Смешные комиксы,веб-комиксы с юмором и их переводы,программирование,it,программист,песочница
Хотя, кстати, я не понимаю, чем контроль версий и комментарии поможет от кусков мёртвого кода, который даже не всегда сразу понятно, что мёртвый. И в итоге ты сидишь и просто построчно разбираешь сраный код. От этого могут помочь только постоянные ревизии кода тимлидом с последующим раздаванием пиздюлей.
А так ты, безусловно, прав - говнокодера из себя надо выдавливать по капле, как и жлоба. Только далеко не все так поступают, не всем хватает ответственности и силы воли. Да что уж говорить, все мы нет-нет да и грешим этим. Но вот в текущем проекте я с чистой совестью могу сказать, что за полгода у меня таких кусков не было ни одного, или я их исправлял потом в течение нескольких дней.
Без бумажки у меня голова кипеть начинала, особенно учитывая, что пропустить нужный звонок чревато нехилой неустойкой, а в случае критической проблемы надо было звонить самому главному директору, а если ему посыпятся лишние звонки в 3 часа ночи, за это тоже можно отхватить пиздюлей. А на бумажке нарисовал, и как-то за вечерок всё сделалось.
Лично я на практике встречал много TODO, которые жили... много. Да чего уж там, сам их леплю, дабы не забыть зачем этот участок существует.
Насчет мертвого кода: очень часто он появляется после десятков рефакторингов. Т.е. был метод сортировки, его постепенно вытеснил другой, но старый не убирали т.к. он использовался. И вот этот момент пропажи всех референсов сложно уловить. Особенно когда в проекте часто сменяемые кодеры.
А мёртвый код появляется даже просто когда понимаешь, что текущее решение не соответствует требованиям, или возникают новые требования, и вот программист смотрит на метод в пару сотен строк и ему во-первых лень, а во-вторых страшно трогать её целиком, особенно, если писал её не он или давно. Да и времени на задачу не всегда хватает, сроки горят, и нет никакой возможности писать с нуля и всё везде тестить и подгонять.
Не уверен. Скорее просто убивает дальнейшую сопровождаемость т.к. рефекторинг на скорую как правило убивает дальнейшую сопровождаемость. Ну или еще не сталкивался с примером, когда так лучше не делать.
>>лень
>>страшно трогать
>>сроки горят
можно добавить "первый раз вижу этот код и хз как работает"
Ну так о том и речь, рефакторинг вроде выполнен, но у тебя есть куски, дублирующие функционал, и, когда кому-то потом нужно будет внести в этот функционал изменения, ему придется править в двух местах, а ещё надо выяснить - в каких местах это используется, потестить, наткнуться на новые косяки... А когда в это место полезут в третий раз, проще будет просто застрелиться или уже тупо взять и довести рефактор до конца - вычленить все обращения к старому методу, переписать их под новый метод, опять-таки всё протестить. Но ведь никто так не будет делать, у тебя времени и так в обрез, а фронтэндщик тебя нахер пошлёт, когда ты ему скажешь, сколько всего править придется, да и не доплачивают тебе за сверхурочные, и потому ты опять просто кое-как подправишь то, что уже есть и пойдешь пилить дальше.
>можно добавить "первый раз вижу этот код и хз как работает"
Ну это и имело в виду под "страшно трогать". И порой это относится и к своему коду, написанному год назад.
з.ы. тут у меня родилась идея программы, которая выпиливает кусок кода и проверяет прохождение тестов. Хотя да, для этого нужны очень (я бы сказал - слишком) всесторонние тесты.