Я не люблю писать тесты для чужого кода, когда код написан плохо, использует очень много зависимостей и когда он не объектно-ориентированный. Это скучно, грустно и не интересно.
Много говорят о тестах, но до сих пор почему-то больше говорят, чем делают. А ведь если сразу же писать свой код и тесты, то код получается лучше, красивее и менее бажный.
Есть разные мнения по поводу того, когда нужно писать тесты. Очень часто слышу, кто тесты нужно писать еще до того, как вы начали писать реальный код. В реальности я больше встречаю случаи, когда тесты пишут в самом конце или не пишут вовсе, потому что не хватает времени.
Недавно я написал заметку, в которой описал магическое выполнение запроса, которое поставило меня в ступор http://www.flenov.info/blog/show/Magicheskaya-problema-proizvoditelynosti. В этой заметке я не раскрою все тайны тормозов, потому что я так и не могу понять, почему тогда простое добавление перехода на новую строку меняло план выполнения, а реальное изменение запроса типа добавления and 1=1 или другие модификации оставляли запрос медленным. Даже OPTION (recompile) не влияла. Именно символ новой строки менял план выполнения. Скажу только, что на следующий день этот трюк не работал и запрос оставался медленным даже после добавления новой строки.
Итак, краткая история. Если просто выполнять запрос в SQL Server Management Studio, то он выполняется быстро:
Мне часто приходится решать проблемы с производительностью и последние два дня борюсь с запросом, который мне просто вынес мозг.
Запрос большой и строится динамически, поэтому я запустил сайт, подключился к нему дебагером и выцепил из кода SQL запрос. Запускаю его в SQL Server Management Studio, и он выполняется за 4 секунды максимум. Но когда абсолютно этот же код выполняется в коде сайта, он работает более минуты.
Я потратил целый день на то, что менял запрос в разные стороны, добавлял OPTION (RECOMPILE) на случай, если проблема с планом выполнения, танцевал вокруг компьютера и ничего не помогало.
Я дебагил каждую строчку кода в надежде понять, может там есть какие-то параметры при запуске запроса, которые могут убить производительность, но там ничего не было. Сравнил типы всех переменных, все совпадает. Производительность может падать, если тип параметра не совпадает с типом данных в базе, но нет, все отлично.
Потом я решил запустил профайлер и выцепить запрос оттуда, и его там показали следующим образом:
Очень часто в книгах о хорошем тоне в программировании можно увидеть термин Decoupling в отношении кода. Смысл в том, что ваши классы не должны быть жёстко привязаны к определённой реализации другого класса (внешней зависимости). И я иногда вижу, что народ следует этой рекомендации в своём коде.
Но почему при этом все так жёстко привязываются к определённому фреймворку в представлениях (View)?
Я ненавижу использовать различные хелперы в виде Html.BeginForm в представлениях. От того, что это превращается во время выполнения в <html> выгоды ноль. Проще же сразу написать HTML тэги и отвязаться от абсолютно ненужно помощи фреймворка.
Я люблю Dependency Injection, я считаю этот патерн очень даже удобным, но я стал замечать, что им пренебрегают. Мне не нравится в последних версиях Symfony, что если у класса есть конструктор с параметрами, то он автоматически пытается привязывать все эти параметры.
А я не хочу этого делать. У меня очень часто в моделях есть классы, которые получают жизненно важные данные через параметры. Symfony заставляет указать autowiring или отключить его в конфигурации. И это реально бесит. Простое использование классов с моими личными параметрами – теперь боль. Может кто знает, как просто отключить Dependency Injection на один из параметров, без необходимости лезть в service файл?
Наверно в каждой книге написано про то, что нужно писать код без жёстких зависимостей - использовать интерфейсы и инъекцию зависимостей. Но почему-то мало, кто реально следует этому. И отчасти это проблема документации, на которую смотрят программисты.
Вот взять для примера всеми любимые фреймворки для PHP и посмотреть на код оправки почты - вот возьмем пример отправки E-mail из Symfony. Я специально беру его, потому что фреймворк хороший и в нем можно писать код без записимостей.
Я обожаю .NET для Web и если строить большой сайт с E-Commerce, то я на первом месте бы смотрел на .NET и только потом на LAMP. Да, LAMP хостинг будет дешевле и можно смириться с некоторыми ограничениями PHP и проблемами, но .NET реально проще и удобнее для больших проектов.
И благодаря .NET Core я могу написать на нем сайт и запустить его на Linux. Да это же мечта. Я понимаю, зачем Microsoft делают .NET Core, он быстрее и реально лучше, в нем исправили все недостатки .NET, которые остались после перехода с 1.0 на 2.0 и живы до сих пор.
Вторая причина - Microsoft Azure. Компания хочет, чтобы программисты могли писать для Azure код на любой платформе. Ну люблю я macOS, так почему же не позволить мне писать код под моей любимой ОС, но публиковать его в Azure? Идея логична и понятна, а если я не захочу публиковать его в Azure? С классическим .NET я вынужден был бы купить Windows сервера и хостить их самостоятельно, а теперь я буду хостить самостоятельно, но на Linux серверах.
Я иногда делаю онлайн трансляции с различных событий, когда кто-то ведет конференцию, а я в онлайн режиме пишу заметку и обновляю ее на сайте. В этот раз будет не онлайн режим, а по мере просмотра. Сейчас смотрю Windows Developer Day 2018 и буду одновременно писать свои комментарии относительно того, что вижу.
Я достаточно нормально отношусь к именованиям методов и классов. Имя просто должно быть понятным и отражать суть. Но вот что меня бесит, так это имена типа EnhancedMethod. Был раньше просто Method, а теперь стал EnhancedMethod.
А через год, когда поймут что текущий метод не очень хороший будут создавать EnhancedMethod2 или может EnhancedEnhancedMethod?
Слова паразиты типа Enhanced или New должны быть исключены при именовании. Нужно быть более креативным.
К сожалению автор удалил видео, поэтому статья немного потеряла в информативности.
В этом видео показатель, почему я до сих пор не использую Linq. На 4:26 показана интересная конструкция, которую Linq сгенерировал на простую просьбу найти записи, которые начинаются с определенного слова. Такая задача решается очень просто, достаточно просто LIKE 'СЛОВО%', но Linq зачем-то добавил еще какую-то проверку на длину совпадения. Вот этого я не совсем понял, зачем такое нужно.
Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю
Copyright © 2024 Михаил Флёнов. Тираж 1 штука. Отпечатано на ноутбуке. А за права отвечаю, или постараюсь.
А здесь еще и копирайт поставлю: Professional Web Development.
