Comments 14
При написании хорошего кода, говнят по края. Что же можно придумать, если намеренно юзать советы из статьи? Статья полезна, как не надо делать.
Вот хуже, когда приходишь на фирму, а там код именно как в этой статье написан, по всем канонам. Да ещё и главные писатели уволились, а продукт расширять надо. А переписать заново "долго и некому, ну может в новом году" (с) шеф.
Можно гордиться "плохим кодом", потому, что он "хороший код" для конкретных реализаций.
Абсурд? Но вы же сами написали:
Самый банальный пример: попробовать использовать не реляционные базы данных как реляционные. Например MongoDB вместо PostgreSQL для хранения табличных данных.
Использовать "что-то" вместо "чего-то", как пример и с утверждением:
И по этой таблице реализовать пагинацию, сортировку, фильтры. При малом количестве записей все будет работать замечательно.
А вам не пришло в голову, что некоторые "методы" работают быстрее если они, с точки зрения логики и даже рекомендаций, неоптимальны?
Типичный пример это TMTPascal, где такого - вагон. Он быстрый, он удобный и, что самое главное, актуальный. Структуры вроде IF/FOR там работают медленнее чем простые переходы при определенном порядке значений. Профит до офигенных значений. Код в итоге превращается в полное говно, но работает и главное - работает очень быстро.
Слыхал историю от коллег, когда нашим разрабам достался проект (интернет магазин) от толи китайцев, толи индусов и там клиент был просто в панике, когда количество заказов перевалило за 15 тыс. и они перестали формироваться. Как потом выяснилось, для id использовались пробелы, первый заказ - один пробел, второй заказ - два пробела...
"Для утечки памяти в C# достаточно переменные объявить статическими"
Слишком явно. Статическое поле памяте- затратного типа не пройдет код ревью.
"Для утечки памяти достаточно забыть использовать using"
Это не приведет к утечке, все подчистится попозже сборщиком мусора. Другие процессы не получат доступ к занятому ресурсу - это да.
Слишком явно. Статическое поле памяте- затратного типа не пройдет код ревью.
Специально взял очевидные примеры. Но в теории код ревью может и пройти.
Это не приведет к утечке, все подчистится попозже сборщиком мусора.
Полезное замечание. Строго говоря, наверное это действительно нельзя называть утечкой памяти. Подразумевалось, что если есть много свободной памяти сборщик мусора может вообще ни разу не отработать во время работы приложения в силу своей "ленивости". Внес правки.
Возможно тупой вопрос, но все таки. На работах ещё не работал, поэтому задаю. Так ли статик плох, как о нем кличут? Где его уместно использовать? Нет, ну очевидно что он удобен для вечных переменных) Но что будет правильнее, вынести его без статики куда нибудь в хранилище, или оставить статиком? Или им лусше пользоваться тогда, когда уже никак?
Для всяких бизнес логик, он требуется чуть чаще чем никогда:)
Если вы как и я богобоязненный С# разработчик, он вам не понадобится. Обычно есть класс работающий с базой, другие классы обрабатывающие логику, по данным записанным в dto. Вы просто создаёте эти классы, передаёте зависимость через конструктор и юзаете. Для меньшего дергания new, переиспользуете, учитывая многопоточность и т.д
Пример Статик класса, это OpenGL, вы управляете глобальным состоянием.
Более простой пример. Вы написали Статик класс чтения файла. Вы его используете. Но в другом потоке читаете другой файл. Что будет? Ещё упростить. Вы открываете два файла, и вам нужно по описанию первого файла содержащего метаданные, открыть другой файл и хитро его распарить. И вам нужно поочередно это делать, строкой за строкой. Задача для Статик класса нерешаема. Так как у класса свое состояние.
количество идеальных кодеров конечно и малО и они находятся в вечном состоянии разорванных п....в когда говорят о говнокоде, при этом подавляющее большинство из них сами постоянно делают что-то, для чего бы следовало нанять специалиста, но у них, как и у например профессуры или академиков, всегда профдеформация, ибо "если я могу закодировать что-то лучше всех, так как я Бог кодинга, так не ужели я не смогу" - вкрутить лампочку, заменить розетку, сварить суп, забить гвоздь, уложить плитку и т.д. То есть дилетантизм в кодинге порицается, а во всём остальном или приветствуется или как минимум не осуждается.
Очень простой пример - сколько мега-кодеров открывают проводник нажатием Win+E? А сколько мышкой? Для кодера оба действия - однофигственны, для сисадмина использование мышки - дилетантизм, так делать просто непрофессионально. Это же касается вызова Панели управления или открытия RDP соединения, да даже банальный вызов калькулятора (я уже молчу про то чтобы узнать например IP адрес сетевой карты).
Ну и чтобы это всё осознать, нужно понимать что кодинг как таковой для многих людей - вообще не их профессиональная среда, это только инструмент, как например нож для повара - будьте уверены что ножом вообще нормально мало кто умеет пользоваться и почему-то мы не видим поварских статей о том, как же им тяжело жить в мире где все неправильно пользуются ножом.
Поэтому нужно быть проще, это раз и два - для начала разберитесь в своей профессиональной среде, ибо говнокодеры-выпускники кодер-специальностей - частое явление.
То есть дилетантизм в кодинге порицается, а во всём остальном или приветствуется или как минимум не осуждается.
Основное свойство личности любого программиста это любопытство. И разумеется, в среде это поощряется. И с чего бы возникнуть осуждению. Сложно увидеть плохое в том, чтобы попробовать починить детскую игрушку или поменять злополучную лампочку.
почему-то мы не видим поварских статей о том, как же им тяжело жить в мире где все неправильно пользуются ножом
Если бы повара готовили какое-то большое блюдо, например торт, и к готовке этого блюда подключались все больше и больше поваров в течение 5 лет эта ситуация, возможно, была бы другой. Представьте, все готовят, вкладывают свой труд, а через год выясняется, что кто-то в самом начале блюда своим ножом нарезал туда огурцов, и даже в небольшом месте вместо торта сделал винегрет и спагетти, а потом уволился. Как думаете, будут ли повара писать статьи как им тяжело от того что кто-то неправильно пользуется ножом? Думаю, это риторический вопрос.
Писать плохой код и гордиться. Зачем?