Еще на тему
Паранойя и клозапин
Популярные Комиксы
 | Комиксы Cyanide and happinessРейтинг: 80,608.5 |
 | cynic mansionРейтинг: 72,249.7 |
 | JaGoРейтинг: 70,562.7 |
 | ОглафРейтинг: 61,070.0 |
 | pet_fooleryРейтинг: 48,561.0 |
 | countryballsРейтинг: 48,277.0 |
 | BuniРейтинг: 47,754.1 |
 | SMBCРейтинг: 42,661.0 |
 | slack wyrmРейтинг: 39,451.3 |
 | duran artРейтинг: 37,982.9 |
Сейчас на сайте
Всего пользователей на сайте: 575
Многие старые программы и игры до сих пор работают как часы - без ошибок и зависаний.
Сейчас обмазываются юнит-тестами - а на выходе забагованная хуйня.
Не нужно "повышать качество приложения" как пишет автор комикса, потому что говно-код уже не исправить, хоть сколько не подпирай его костылями.
И всё таки не уверен, сильно ты не любишь юнит-тесты или нет, но в крупных проектах - они маст-хэв - мелкие модули можно тестировать без запуска всей программы. Да что там, даже если ещё половина проекта в стадии "В голове того кодера".
не в том окружении, не в том порядке инитится, в котором думали, и т.п
статьи тоже обычно не помогают, сколько их читал, все рассматривают тестирование хелловорлда, а потом всё, конец. как тестировать ебический распределенный кластер - думай сам.
у коллег, которые пишут тесты, тоже чота ничего почерпнуть не получается. как увижу, что на тестирование класса с 3мя полями внутри (rgb цвет) тратится 2 страницы кода - так впадаю в уныние :(
А вот уже при багах, можно смотреть требования, и выяснять, чего да как произошло.
Вообще, рекомендую кинуть взор на компанию СКБ Контур и их обучающие материалы. Очень хорошо излагают суть и основные принципы разработки ПО и его тестирования. Есть стажировки и обучающие материалы.
Увы, только если юнит-тест правильно написан. Да, это ещё один уровень контроля, в какой-то мере это тебя дисциплинирует, и в целом имхо хорошо, но это не гарантирует качества кода, точно так же как код без тестов не обязательно забагован.
Приведу гипертрофированный пример. Пишешь метод, принимающий инт, отдающий булеан. По всей логике выходит, что если твой инт менее 101, то возвращаем тру, если более - то фэлз. А в проде все падает один раз на 10000, но зато очень громко, и вообще в другом модуле и с совершенно непонятной ошибкой. Потому что ты забыл учесть фазу луны, варианты валентности хлора и долбоеизм Трампа, потому при значении -14762 метод должен возвращать фэлз.
При этом твой простейший класс создается ебанной фабрикой из конфига размером с войну и мир, весь код покрыт тестами и все типа збс, кроме размера проекта, из-за которого этот ебанный баг искали два месяца, а не два дня.
Понимаешь, механические ошибки кода обычно не сильно страшны, и их ловят QA на раз два. А вот логические пиздец как важны. Но из-за относительно небольшого проекта, какаим бы он был без тестов и других тараканов, проект становится неебическим монстром со 100500 уровней абстракций, и в нем реальную работу выполняет отсилы 20% кода, остальное занимается обслуживанием всей этой хуеты.
Я как-то переписывал такой пиздец с жабы со всей этой поебенью на простецкий код на скалке. Бляяяяяя. 150 классов в один? Да легко! Никаких блядских фабрик, никаких ограничений типа "мы так не делаем потому что Архитектура/написано в умной книжке". Был Очень Большой Проект, стал аккуратненький маленький. Без изменения функционала.
Понимаешь, ловить ошибки в проде - охуеть как важно. И тут тесты не просто допизды, они своим существованием конкретно усложняют дело.
Теперь, если что-то надо будет поменять в проекте - они будут искать тебя, а ты искать что-то в одном огромном куске кода или другой кодер будет материться и плеваться.
В то же время, 100500 классов разбиты по модулям, и сидят там, где они нужны, не перегружая всю картину. Не надо листать 1000 строк кода, чтобы узнать, что этот класс делает, не надо смотреть, что там да куда уходит, откуда возвращается.
Паттерны, методы проектирования и прочее придумали не от скуки. Они нужны, чтобы "творческие личности" с криками - "А вот здесь можно ебануть вот такой финт ушами" горели в аду. Строгий код, всё читаемо и понятно, легко проследить что куда уходит, где что чем занимается. Простые методы - меньше удивлений, когда в далёком месте вылетает баг.
Опять же. Если говно-тесты - смысла от них не будет, и даже только вред. Так же и паттерны - пихать их куда попало - не признак большого ума.
катышкиклассы в другие места. А баги-то есть. Модулей тоже 100500, и я в душе́ не ебу, что из них каждый делает, доков нет, по названиям они все безликие. Спросить не у кого. И вот начинаешь отслеживать путь данных от какой-то точки, пытаясь понять, где же они таки портятся в этом всем месиве. Причем каждый раз нужно рыскать по всем злоебучим реализациям и инициализациям, потому что баринам-с-тестами писать new MyClass конкретно западло. Это все густо перемешано с постоянными уходами исполнения в развесистый фреймворк, и не факт, что ошибка не там(спринг внутрях весьма кривой, и я там баги находил нередко - один парсинг некоторый вещей через регекспы крови мне попортил литров несколько), и хуй ведь понятно, где оно выныривает и почему так.Как раз это говно и писали творческие личности, у которых вместо мозгов паттерны. Разбираться в коде, который не реализует паттерны, а выполняет задачу, на тех же условиях(есть только исходники) в РАЗЫ легче.
>"искать что-то в одном огромном куске кода или другой кодер будет материться и плеваться. "
Это твоя отсебятина, про огромные куски кода.
>Не надо листать 1000 строк кода, чтобы узнать, что этот класс делает,
Как раз в таких злоебучих проектах приходится рыскать по 1000 строк кода в 100 классах, потому что логики в них на 50 строк. потому остальные 950 можно выкинуть нахуй, а эти 50 сделать одним актором с несложным паттерн-матчингом(это не хуже методов), и с учетом скалки, ужать до 30.
Можешь глянуть, вроде в версиях 2.х это есть еще. Мне лень снова в этом говне копаться. Ребятки там про RFC вообще не слыхали, у них тоже только паттерны в мозгах.
Тесты отдельных модулей как черных ящиков по вполне определенным спекам взаимодействия между модулями - ок. Эти спеки меняются не часто, и можно переписать. Не проходит модуль - баг летит тем, кто за него в ответе, а там у себя разберутся.
Можно и отдельные функционально-важные части тестами покрывать. Но не до маразма.
Блядь, совсем недавно была(уже чуть пошла на спад) мода на УВЕЛИЧЕНИЕ числа классов и методов. Код от этого становился действительно простым, даже слишком, ибо большинство методов и куча классов, по сути, нихуя не делали. А вот проект становился неебически сложным, ибо понять, где в этом ебанном месиве из 100500 классов делается то, что тебе нужно, а не проксируется очередной бессмысленной хуете, поднятой в виде интерфейса через фабрику - это полный пездец. Это в джаве, и мода эта пошла со Спрингом и засильем тестов. Сейчас народ массово валит от этого бреда на скалку или другие технологии, потому что за эти годы наваяли монстров с огромным количеством кода, конфигов, которые нихуя не конфигурируют, тестов, которые нихуя не тестируют, библиотек, которые используются три раза и на 0.0001% от их возможности и все в этом духе. Исходник проекта после подтягивания зависимостей весит гиг, а это всего-лишь очередная блядская система отчетов и ведения записей очередной затрапезной буржуйской больнички.
Ага, после тонны патчей, включая неофициальные.