Comments 57
Варианты ответов подобраны неудачно, «Да, копание в чужом коде — это нормально.» не имеет отношения к говнокоду
Да, копание в чужом коде полезно. Если, конечно, к этому не сводиться вся работа программиста.
У каждого программиста свой стиль написания программного кода. Копаясь в чужом коде можно найти свои ошибки или новые приёмы.
Например, вчера я закончил переписывать под себя jQuery — узнал около десятка новых приёмов и методов программирования и нашел пару ошибок в своём.
Но как я сказал, если вся работа сводиться к разбору чужого кода, то это работа «печатной машинки», а не программиста.
У каждого программиста свой стиль написания программного кода. Копаясь в чужом коде можно найти свои ошибки или новые приёмы.
Например, вчера я закончил переписывать под себя jQuery — узнал около десятка новых приёмов и методов программирования и нашел пару ошибок в своём.
Но как я сказал, если вся работа сводиться к разбору чужого кода, то это работа «печатной машинки», а не программиста.
Следует разделить понятия «ковыряние в ХОРОШЕМ чужом коде» и «ковыряние в чужом ГОВНОКОДЕ». Это совершенно разные вещи.
Поднатаскает в рефакторинге.
Копаясь в чужом говнокоде программист начнёт только ненавидеть программирование, может потерять мотивацию не только к проекту с говнокодом но и вообще к копанию в коде, написанию программ и дальнейшему развитию. Вредно влияет однозначно.
Исключением может быть разве что масштабный рефакторинг проекта с плохим кодом
Исключением может быть разве что масштабный рефакторинг проекта с плохим кодом
при условии, что уровень знаний «копальщика» выше, чем говнокодера
Тут важно понимать, что при этом делает разработчик.
Если у него есть время для рефакторинга — однозначно полезно (проанализировать код, выделить суть, выделить кривые решения, переписать без «ошибок»).
Если времени на рефакторинг нет — значит остается писать в том же стиле, т.е. обучаться говнокоду, что однозначно вредно.
Если у него есть время для рефакторинга — однозначно полезно (проанализировать код, выделить суть, выделить кривые решения, переписать без «ошибок»).
Если времени на рефакторинг нет — значит остается писать в том же стиле, т.е. обучаться говнокоду, что однозначно вредно.
Говнокод в 99% обуславливает отсутствие юнит-тестов. В рабочей системе без юнит-тестов (и изоляции модулей как следствия) модульный рефакторинг невозможен в принципе!
Переписывание кусков кода возможно, но вы этим обрекаете себя на анальные муки в случайные моменты времени, когда из-за вашего свежего, «правильного» решения будут ломаться все новые и новые «неправильные» куски системы, абсолютно не связанные, на первый взгляд, с переписанным кодом.
Посему, копание в работающем говнокоде почти всегда требует от разработчика одного и только одного — писать новый говнокод, вставляя костыли и распорки для существующей системы.
И дело тут вовсе не во времени. Если бы времени было достаточно — вопрос о копании в говнокоде просто не стоял бы, но его почти всегда нет.
Переписывание кусков кода возможно, но вы этим обрекаете себя на анальные муки в случайные моменты времени, когда из-за вашего свежего, «правильного» решения будут ломаться все новые и новые «неправильные» куски системы, абсолютно не связанные, на первый взгляд, с переписанным кодом.
Посему, копание в работающем говнокоде почти всегда требует от разработчика одного и только одного — писать новый говнокод, вставляя костыли и распорки для существующей системы.
И дело тут вовсе не во времени. Если бы времени было достаточно — вопрос о копании в говнокоде просто не стоял бы, но его почти всегда нет.
То есть по вашему, люди которые не пользуються Юнит-тестом в 99% пишут гавнокод?
Нет, без юнит-тестов писать изолированный код в 100 раз сложнее, а говнокод — в 1000 раз легче.
Я лишь говорю о том, что если у вас на руках есть говнокод — он в 99% случаев будет без юнит-тестов ;-)
Я лишь говорю о том, что если у вас на руках есть говнокод — он в 99% случаев будет без юнит-тестов ;-)
Очень спорно ваше замечание. Юнит тесты контролируют работоспособность кода, а не его качество.
Я не говорю, что невозможно писать качественный код без юнит-тестов. Я лишь говорю, что юнит-тесты позволяют устранять огрехи в изоляции модулей еще на этапе тестирования или проектирования (для TDD). Вот и все. И да, если мы говорим о говнокоде — он не покрыт тестами. Покрытый тестами говнокод — это очень редкий случай. При чем здесь качество?
говоря о гавнокоде говорят о качестве кода, а не о том, хорошо или плохо он выполняется.
Ну и я думаю само собой разумеется, что глупо делать рефакторинг неизолированного модуля. Рефакторинг модуля, изоляция которого недоказана (не оттестирована) — тоже глупая затея, ибо вы играете в русскую рулетку с продакшен кодом. Т.е. безтестовый говнокод (99% случаев) не поддается рефакторингу — вот все что я хотел сказать. Качество кода тут не особо важно.
Юнит тесты молодая метадология. Как же до нее люди программировали?
Молодая методология? Вы о чем вообще???
Я если что о программировании.
Сколько лет программированию и сколько лет юнит тестам?
Сколько лет программированию и сколько лет юнит тестам?
Так сколько лет юнит-тестам? На чём основано утверждение что это молодая технология?
На том, что юнит тесты получили популярность после книги Кента Бека в 1999 году
citforum.ru/SE/testing/mod_test/
«Модульное тестирование имеет довольно длинную по компьютерным меркам историю. Впервые о нем заговорили в 1975 году (именно тогда оно упоминается в знаменитом „Мифическом человеко-месяце“ Брукса), затем в 1979-м его подробно описал в книге „The Art of Software Testing“ Гленфорд Майерс. А через 12 лет, в 1987-м, IEEE приняла специальный стандарт модульного тестирования ПО.»
Модульное тестирование появилось как только появились модули = как только сложность софта этого потребовала
«Модульное тестирование имеет довольно длинную по компьютерным меркам историю. Впервые о нем заговорили в 1975 году (именно тогда оно упоминается в знаменитом „Мифическом человеко-месяце“ Брукса), затем в 1979-м его подробно описал в книге „The Art of Software Testing“ Гленфорд Майерс. А через 12 лет, в 1987-м, IEEE приняла специальный стандарт модульного тестирования ПО.»
Модульное тестирование появилось как только появились модули = как только сложность софта этого потребовала
Буквально следующее предложение по вашей ссылке
«Тем не менее наблюдаемый в последние годы рост популярности модульных тестов связан почти исключительно с распространением так называемых „легких“ методологий, и особенно с экстремальным программированием. Начало этой тенденции положил Кент Бек своей книгой „Extreme Programming Explained“, увидевшей свет в 1999 году»
«Тем не менее наблюдаемый в последние годы рост популярности модульных тестов связан почти исключительно с распространением так называемых „легких“ методологий, и особенно с экстремальным программированием. Начало этой тенденции положил Кент Бек своей книгой „Extreme Programming Explained“, увидевшей свет в 1999 году»
Ну я бы сказал, что юнит-тесты не то что бы устраняют огрехи в изоляции модулей, скорее указывают на них. Хотя если найдено проблемное место, решить проблему можно лишь только иногда. Чтение мантры «вот сейчас я выделю интерфейс и опа, модули не зависимы» — не работает. Выход — там где ни в какую не получается писать юнит-тест, лучше написать интеграционный.
Там, где не выходит писать юнит-тест — изоляции нет!
Я это не отрицаю. Только говорю, что во многих случаях изоляцию нельзя достичь. Попробуйте-ка протестировать слой БЛ в изоляции от БД. Моки не предлагать. А я не буду мучится, а запущу in memory базу и протестирую БЛ вместе с БД интеграционно. Изоляции не будет, да и не нужна она тут особо.
Вы хотите протестировать слой БД или слой бизнесс-объектов? Первое — да, никак. Но это опять же — проблема архитектуры. БД — это всего-лишь persistence layer для ваших бизнесс-объектов, которые и нужно тестировать ;-)
Я все прекрасно понимаю. Но как мне протестировать бизнес-объекты без БД, если в их коде есть обращения к persistent-layer-у, пусть даже через интерфейс? Все, что можно сделать, это подменить persistent-layer. Изолироваться от него никак нельзя. Тут несуществует не кривой архитектуры — слой БЛ зависит от persistent-layer, как ни крути.
Мой тезис таков: невозможно избавиться от прямых зависимостей в коде, можно их только ослабить.
Мой тезис таков: невозможно избавиться от прямых зависимостей в коде, можно их только ослабить.
Изоляция — это не избавление от зависимостей. Это возможность изоляции модуля от остальных частей системы. Возможность инъекции зависимости и далее, подмена зависимостей стабами или моками. Да, в вашем случае следует изолировать путем инъекции стаба или мока персистенс-лэйера.
Покрытый подобными тестами код будет 100% изолирован и вы в любом случае сможете рефакторить отдельный кусок персистенс-лэйера или бизнесс-объекта в дальнейшем без страха поломать систему в целом. Я говорю именно об этом. Интеграционные тесты тоже позволяют выполнить задачу, но несколько иными путями. Они гарантируют, что система после рефакторинга будет работать так же, но отнюдь не то, что она будет работать верно ;-)
Покрытый подобными тестами код будет 100% изолирован и вы в любом случае сможете рефакторить отдельный кусок персистенс-лэйера или бизнесс-объекта в дальнейшем без страха поломать систему в целом. Я говорю именно об этом. Интеграционные тесты тоже позволяют выполнить задачу, но несколько иными путями. Они гарантируют, что система после рефакторинга будет работать так же, но отнюдь не то, что она будет работать верно ;-)
>Покрытый подобными тестами код будет 100% изолирован и вы в любом случае сможете рефакторить отдельный кусок персистенс-лэйера или бизнесс-объекта в дальнейшем без страха поломать систему в целом.
Как раз получается наоборот, что у вас система работоспособна по частям в вашем тестовом окружении, но будучи собраной воедино вполне может не заработать.
>Интеграционные тесты тоже позволяют выполнить задачу, но несколько иными путями. Они гарантируют, что система после рефакторинга будет работать так же, но отнюдь не то, что она будет работать верно ;-)
Вот это вообще не понятно. Интеграционные тесты гарантируют, что система работает корректно в ситуациях, описанных в тестах. Полный набор тестов как правило составить не сложно. Если все они проходя — система корректна. Мучиться с юнит-тестами будет оверхед.
Получается для тестирование системы из связаных компонентов юнит-тестов не достаточно, нужны интеграционные. А имея интеграционные тесты отпадает необходимость в юнит-тестах.
И да, автономные компоненты можно и нужно тестировать юнит-тестами, с этим я не спорю.
Как раз получается наоборот, что у вас система работоспособна по частям в вашем тестовом окружении, но будучи собраной воедино вполне может не заработать.
>Интеграционные тесты тоже позволяют выполнить задачу, но несколько иными путями. Они гарантируют, что система после рефакторинга будет работать так же, но отнюдь не то, что она будет работать верно ;-)
Вот это вообще не понятно. Интеграционные тесты гарантируют, что система работает корректно в ситуациях, описанных в тестах. Полный набор тестов как правило составить не сложно. Если все они проходя — система корректна. Мучиться с юнит-тестами будет оверхед.
Получается для тестирование системы из связаных компонентов юнит-тестов не достаточно, нужны интеграционные. А имея интеграционные тесты отпадает необходимость в юнит-тестах.
И да, автономные компоненты можно и нужно тестировать юнит-тестами, с этим я не спорю.
Ну везде нужно искать где это рационально выгодно, а где нет. В случае с БД, я согласен с коллегой, проще гонять тесты на in-memory database, при этом вариант моков никак не спасает. Ведь тогда, допустим, при изменении методов модели, придется также менять моки, чтобы код выполнялся одинаково. Таким образом мы приходим к тому, что мы или пишем код дважды, или в лучшем случае, нам приходится править больше файлов, чтобы актуализировать тесты.
Юнит-тесты отличная штука там где классы более-менее изолированы, это факт. Там где добавляется persistance или view, лучше перебдеть и написать все возможные команды в функциональных тестах, на что и времени потратиться меньше, и уверенности в работоспособности системы вцелом будет больше.
Юнит-тесты отличная штука там где классы более-менее изолированы, это факт. Там где добавляется persistance или view, лучше перебдеть и написать все возможные команды в функциональных тестах, на что и времени потратиться меньше, и уверенности в работоспособности системы вцелом будет больше.
Автоматизированный контроль за качеством позволяет делать рефакторинги, которые в итоге приводят к хорошему качеству :) Нету автоматики — нету рефакторингов. Нету рефакторингов — любой код без оного протухает рано или поздно и привращяется в говнокод.
Кстати, очень серьезная предпосылка к говгокоду на ряду с отсутствием юнит-тестов — это отсутсвтие ревью кода.
Если писать тесты и ревьюить код (ну и рефакторить по результатам), то качество кода почти гарантировано.
Если писать тесты и ревьюить код (ну и рефакторить по результатам), то качество кода почти гарантировано.
Программист увидит ошибки, заменит не оптимальный код более верным.
Любой навык полезен, главное что-бы это не превратилось в постоянную работу.
Любой навык полезен, главное что-бы это не превратилось в постоянную работу.
Я вот, если честно, не понимаю как вы можете говорить про «заменит неоптимальный код более верным»! Говнокод почти всегда подразумевает отсутствие тестов как класса. Это не просто заменить железную шестеренку на золотую в часах. В этом случае правильная, отлаженная шестеренка, вставленная в правильное место вместо неправильной может привести к неверной работы системы в целом в случайный момент времени. Потому что другая деталь в системе в случайный момент может попытаться дернуть вашу шестеренку, ожидая на выходе заложенное изначально неверное поведение.
Если есть запущенный проект с говнокодом, но без тестов — он в 99% случаев не поддается модульному рефакторину, ибо для рефакторинга нужна оттестированная изоляция модулей! Если же проект имеет юниты — проект в принципе уже не говнокодный.
Если есть запущенный проект с говнокодом, но без тестов — он в 99% случаев не поддается модульному рефакторину, ибо для рефакторинга нужна оттестированная изоляция модулей! Если же проект имеет юниты — проект в принципе уже не говнокодный.
Как говорил один товаришь, «Изучая как ко-то другой сделал неправильно довольно трудно научться сделать правильно. Потому как в большинстве случаев множество неправильных решений намного больше, чем множество правильных».
UFO just landed and posted this here
Опыт копания в говнокоде. Он может пригодиться лишь для копания в другом говнокоде, что в общем-то, тоже квалификация.
Прям читаете мои мысли =) Я когда-то для себя придумал фразу: «Копаясь в говне, можно научиться только копаться в говне».
Зря ты так, очень многим вещам можно научиться в гавнокоде. Было бы желание.
Привет =)
Если честно, у меня всё, чему я научился вылилось примерно в:
+5 к упорству
+7 к умению писать костыли и «внедряться» в чужой код своими заплатками
+10 к мысли, что работа во всех крупных компаниях в той или иной мере предполагает работу с чужим, старым, за частую не комментируемым и не задокументированным кодом
Ну и стал больше ценить комментарии к коду =) Чего уж там.
Если честно, у меня всё, чему я научился вылилось примерно в:
+5 к упорству
+7 к умению писать костыли и «внедряться» в чужой код своими заплатками
+10 к мысли, что работа во всех крупных компаниях в той или иной мере предполагает работу с чужим, старым, за частую не комментируемым и не задокументированным кодом
Ну и стал больше ценить комментарии к коду =) Чего уж там.
Хотя, я наверно утрирую, но суть, всё равно, примерно такая же.
Самое главное, гавнокод учит писать хороший код. Это как раз тот случай, когда учишься на чужих ошибках.
Гавнокод надо править и с ним надо работать, только не надо это делать постоянно. Понятно, что хочеться это делать как можно реже, но так или иначи в своих проэктах зачастую мы используем чужой код, который, кстати, не всегда хороший
Гавнокод надо править и с ним надо работать, только не надо это делать постоянно. Понятно, что хочеться это делать как можно реже, но так или иначи в своих проэктах зачастую мы используем чужой код, который, кстати, не всегда хороший
Говнокод в принципе не может научить писать хороший код. Чтобы писать хороший код — вы должны знать как его писать. Если вы знаете, что это говнокод, значит вы УЖЕ знаете как надо писать правильно. А вот если вы не знаете — тогда да, говнокод может чему-то научить, но отнюдь не «правильному» написанию кода.
Например? Чтобы чему-то научиться, нужно знать как НУЖНО делать, а не как НЕ НУЖНО. Если вы знаете как нужно, но видите перед собой говнокод, в котором сделано через одно место — вы не получаете новые знания, вы лишь понимаете, что тут сделано неправильно. Вот и все. Учиться чему-то можно только постоянно поднимая планку качества своего кода, а не понижая ее!
Если это гавнокод, то есть толко два варианта:
— мучаться и дописывать в чужой гавнокод свой, и тут иначе никак, ты не получится менять чужие конструкции, без риска завалить весь проект. А потому и свой код будешь делать максимально изолированым от чужого, чтобы ни в коем случае не повредить ничего, и в итоге пишешь гавнокод.
— покрыть всё функциональными тестами и переписать всё. Но на это обычно нет ни времени, ни возможности, и вообще это крайне редкое явление.
— мучаться и дописывать в чужой гавнокод свой, и тут иначе никак, ты не получится менять чужие конструкции, без риска завалить весь проект. А потому и свой код будешь делать максимально изолированым от чужого, чтобы ни в коем случае не повредить ничего, и в итоге пишешь гавнокод.
— покрыть всё функциональными тестами и переписать всё. Но на это обычно нет ни времени, ни возможности, и вообще это крайне редкое явление.
Говнокод вообще вреден для здоровья
Sign up to leave a comment.
Способствует ли работа над проектами с «запущенным» кодом повышению квалификации разработчика?