Сообщество - IT-юмор
Добавить пост

IT-юмор

5 678 постов 52 564 подписчика

Популярные теги в сообществе:

Осторожнее с советами биохакеров

Осторожнее с советами биохакеров, потому что вы можете нарваться на биоламеров

Не обижайте разработчиков!

Не обижайте разработчиков! Приложение, Баг, Обида, IT юмор, Картинка с текстом, Кот, Скриншот, Повтор
Показать полностью 1

Это что за покемон?

Это что за покемон? IT юмор, Картинка с текстом, Мемы, Программирование, Рефакторинг, Утконосы

Пещера Айтишника

Техподдержка

Техподдержка Скриншот, IT юмор, 1С, Повтор, Анекдот
Показать полностью 1

Say my name!

Say my name!

Карьерный рост в it

Карьерный рост в it

Ответ на пост «На конкурс ужасов от программирования»

Сейчас будет много мата. Кодревью, конечно, полезная вещь, но при единственном условии - если кодревьюер адекватен. На моем предыдущем месте работы было не так. Начать с того, что тимлид с искренним убеждением доказывал, что SQL слишком сложен и трудночитаем. Поэтому нужно обязательно использовать ОРМ. То, что ОРМ передает в запроcе полную хуйню - не ебет. Раз мы этого не видим - значит, этого не существует. Совершенно нормальная ситуация, когда надо обновить запись в базе: отправляем запрос на чтение записи. Создаем объект. Обновляем свойство объекта. Пишем объект в базу. Снова читаем из базы и смотрим, что получилось. Если нужно обновить два поля или больше в одной записи - повторяем столько раз, сколько потребуется. Это нормально. Ачетакова? Подумаешь, лишняя пара миллисекунд на запрос. Зато код красивый и читаемый, без сложного SQL. То, что таких нахуй ненужных запросов набираются тысячи и десятки тысяч - не, код не может тормозить из-за этого! Давайте добавим еще пару сотен запросов. Да, и у каждой сущности должен быть объект. Универсальный, всеобъемлющий. Надо обратиться к конкретной записи в конкретной таблице? Не, такнизя. Мы должны работать с объектом! Прочитаем 100500 связанных и не очень таблиц, построим объект, дамп которого будет занимать 300 экранов текста, и меняем свойство объекта. То, что методы этого объекта при записи будут переписывать и все 100500 связанных таблиц - не ебет. Зато красиво и удобно. Объектно!

Отдельная история про функции. Если в функции больше 20 строчек кода - все, это уже слишком сложно и нечитаемо. Вот вообще никак, не читаемо и все тут. Нужно разбить на 200 функций по паре-тройке строчек, раскидав их по разным модулям. Чтобы многократно вызывали друг друга перекрестно, рекурсивно и через жопу. 600 строчек кода в паре десятков файлов - это намного лучше, чем 20 строк в одной функции. То, что операция, которая может быть выполнена за один проход цикла, в результате крутится в 20 циклах (еще и каждый раз обращаясь к базе) - не ебет. Зато красиво.

О, еще бонус. Хочешь написать новую функцию? Не-не. Сперва посмотри, нет ли такой в уже готовых библиотеках. Есть, да не такая? Не ебет, натягивай сову на глобус. Вместо того, чтобы написать 5 строчек кода, делающих то, что нужно - мы подтянем библиотеку на пару сотен метров, которая делает не совсем то, что нам нужно, и понастроим к ней костылей.

Короче, я устаревший программист. Ебал я в рот эти новомодные тенденции. Зато я больше не удивляюсь тому, что сейчас любая софтинка, по функциональности не намного больше, чем hello world, непременно будет весить полтора гига, требовать 16 гигов памяти и тормозить на топовом компе.

Показать полностью

На конкурс ужасов от программирования

Размещаю в айти юморе, хотя это на самом деле программистские ужасы. Это реально чисто для программистов пост. Мы тут договорились, что мы померяемся с другими программерами у кого легаси страшней. Сейчас это не заявка, но чисто чтобы прочувствовали. Это не самое страшное, но это то, что я нашел только за один день:

В одном действии импорта в разных местах ошибочно сделали два раза импорт одной таблицы. Не знаю это был один человек или два разных. Потом кто-то из них (или кто-то третий) таки нашел проблему. Но он не исправил или закомментил один раз, он написал процедуру чистки дублей. Написал криво. Вкупе с ошибками в процедурах импорта это давало настолько рандомные результаты, что я тоже еле разобрался в этом.

База данных импортируется больше пяти часов. Ну… логично. База большая. Лезу внутрь. Там сразу два сюрприза. Самая большая таблица всего 25к. База большая из-за того, что внутрь посохраняли картинки в 444 мегабайт. А медленно из-за того, что это уникум мало того, что для копирования каждой записи создает объект, создает запрос, выполняет запрос, закрывает запрос, уничтожает объект, так он еще для каждой записи открывает запрос select все без условий. Соответственно база в 25к записей возводится по нагрузке в квадрат. И это похоже только для того, чтобы получить доступ к списку полей, так как потом он читает и вставляет уже нормально. То есть, еще действия на ту же запись.

На каком-то этапе этот монстр программирования утомился от ошибок и предположительно пиздюлей от начальства и клиентов и стал ошибки и исключения перехватывать и подавлять. Причем таких мест много. Там ушло в отвал пару тысяч нескопированных записей, там еще пару сотен. Ошибок нет, но на выходе записей намного меньше, чем на входе. В одном месте комментарий, что в этом нужно потом разобраться. Комментарий от двенадцатого года. А возможностей для ошибок там море: Буквально на пару страниц кода – Преобразование в дату текста от клиента, веря, что клиент всегда напишет дату в строковое поле правильно и не оставит пустым. Поиск и сразу чтение без проверки нашлось ли что-то. Запись без проверки, что может же там уже есть этот уникальный идентификатор.

Вишенка на торте и самое бредовое концептуально - базам данных он похоже просто не доверяет и перегоняет данные для обработки в свои объекты и массивы. Мало того, что это вообще ничем не оправданно, так еще от процедуры к процедуре это другие объекты с разными названиями полей в стиле bpid для одного и того же. Разобраться трудно. Ему тоже. В одном месте перепутал названия куда он сохраняет объем и площадь. Сохранил накрест. Но это не исправлено и просто при передаче в следующий объект передает опять накрест и тем выравнивает.  Чтобы обработать таблицу в пять тысяч записей, он насоздает объектов в количестве пять тысяч, загрузит туда пять тысяч записей. Но потом будет открывать для каждой записи отдельный запрос, как описано во втором абзаце. Посмотрел бы я как бы он обрабатывал базу в сотни тысяч записей

Конечно, программисты всегда ругают предыдущего программиста. Но я уверен, что мне точно попался просто редкий по своей природе долбоеб, даже если я не так часто работал с чужим кодом

Показать полностью
Отличная работа, все прочитано!