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

Другого человека можно легко запутать, ведь он не знает ход ваших мыслей. Гораздо сложнее обыграть самого себя, чтобы уже через несколько дней было невозможно разобраться в том, что реально происходит и откуда все эти баги. В этой игре вы и есть ваш самый главный противник. Поэтому попробовать такой челлендж будет интересно как новичкам, так и опытным разработчикам, ведь у опытных разработчиков могут быть все более комплексные ухищрения.

Время от времени мы пишем статьи в духе "статический анализатор внимательнее C++ программиста". Сегодня мы продолжим эту традицию, разве что заменив "программист" на "хакер".

Для джуна поиск работы похож на полосу препятствий. Тот, кто успешно преодолел ров с крокодилами, катящиеся шары, лаву и дротики с ядом, получает приз — классную работу. 

Всем привет, это Макс Кравец. В 2021 году я написал серию статей о том, почему джуны никому не нужны и куда катится рынок зарплат разработчиков в IT. В них я посмотрел на вопросы со стороны нанимателя. Рассказал, почему джуны — это рисковая инвестиция. Дал общие советы, как новичку не застрять на начальном уровне, прокачать самостоятельно soft- и hard-скиллы и достигнуть желаемого роста в зарплате. Спустя полгода я решил дополнить эти материалы. 

Некоторые предупреждения анализатора или компилятора сложно однозначно классифицировать как ложное срабатывание или указание на настоящую ошибку. Бывает, что формально анализатор/компилятор прав, но и код работает правильно. Что делать? Возможно, это повод упростить код.

Привет! Я QA Automation Engineer в Scalable Solutions. Наша компания, как и многие другие, предлагает после устного собеседования сделать тестовое задание. Как человек, который два года назад делал похожее задание при трудоустройстве, решила разобрать основные ошибки тестировщиков при его выполнении, а также поделиться спецификой наших (и не только) ожиданий в ходе найма. 

Мы продолжаем наш рассказ о причинах повышенного потребления памяти в языке Go. В предыдущей статье мы детально разобрали ошибки бизнес-логики приложения, которые могут привести к утечкам памяти. Сегодня же сосредоточимся на особенностях рантайма языка Go.

Сегодня я расскажу тебе, достойна ли книга Роберта Мартина “Идеальный программист” внимания. Стоит ли её читать, если ты уже опытный программист, прошедший большой путь и многое познавший? А если ты только начинаешь свою нелегкую дорогу в мир разработки? Быть может ты находишься где-то по середине и не знаешь, как дальше развиваться? Может ты вообще до этого не читал никакой технической литературы и боишься к ней подступиться? На все эти вопросы ты найдешь ответ в этой краткой статье.

Все началось с глупой ошибки. В тексте программы вместо оператора x=20; где x – целая переменная со знаком и размером в байт, случайно написали x=200;

И компилятор, что называется не моргнув глазом, сформировал команду записи в переменную x константы 0C8H, что вообще-то соответствовало оператору x=-56; Выяснилось, что за долгие годы эксплуатации этого компилятора ни одна собака ни один пользователь (включая и нас самих) никогда не писал подобных ляпов и поэтому ошибка в компиляторе оставалась незамеченной. А виноваты оказались команды сужения данных.

Однажды Учитель задал Автору следующий вопрос:

Существуют ли иные методы внесения избыточности на уровне информации, кроме тех, которые изучает теория помехоустойчивого кодирования? Подчеркнув, что речь идет об информационной избыточности, Учитель тем самым дал понять, что вопрос не подразумевает различные способы внесения энергетической избыточности, которые хорошо изучены в теории связи. Ведь помехозащищенность передачи  информации традиционно оценивается посредством порогового значения, которое рассчитывается как отношение энергии сигнала к энергии шума. Известно, что методы теории помехоустойчивого кодирования предлагают альтернативное решение, но позволяют сэкономить энергию.

После короткого раздумья Автор ответил утвердительно, следуя скорее интуиции, а не рациональному знанию. Выслушав ответ, Учитель заметил, что это неверное заключение и таких методов не существует.

С течением времени Автор стал подозревать, что непреложность сформулированной выше парадигмы может быть подвергнута сомнению.

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

Но, по сообщениям некоторых пользователей, у программ, написанных на Go, течёт память. Issue-трекер языка Go на github по запросам «high memory usage», «memory leak», «out of memory» выдаёт сотни и тысячи тикетов. А в самом популярном вопросе на stackoverflow по словосочетанию «golang memory» автор пытается разобраться, почему потребление оперативной памяти в рантайме в 4 раза превышает количество реально сделанных аллокаций. Обращения, в которых люди рапортуют о перерасходе оперативной памяти в Go, стали массовым явлением.

Что же это — утечки памяти, вызванные программистскими ошибками, или ожидаемое поведение рантайма языка? Мы попытаемся разобраться в причинах этого явления и сформулировать общие рекомендации, которые помогут в отладке проблем с потреблением памяти.

Почти 30 лет назад в классической книге по шаблонам проектирования Design Patterns: Elements of Reusable Object-Oriented Software, авторы сформулировали один из самых известных, но недопонятых принципов в истории программирования:

Program to an interface, not an implementation.

— Erich Gamma et. al, Design Patterns: Elements of Reusable Object-Oriented Software

Зачем "программировать в интерфейсы"?

Термин «мертвый код» - это, скорее, жаргонное, чем научное название участков программы, на которые не может попасть управление и, таким образом, они никогда не выполняются. Разумеется, в нормальных программах таких участков быть не должно. Но поскольку языки программирования становятся все сложнее и сложнее (а программисты все тупее и тупее, шутка!) в кодах программ может быть все, что угодно.

Введение

Работа с плохим кодом лично у меня вызывает отвращение и — по правде говоря — ещё и неприличные мысли в отношении того, кто его писал. Сейчас я уверен, что кроме программистов проблему плохого написания по-настоящему не понимает никто, хотя эта проблема есть не только у нас. В этой статье я покажу это на примере учебных пособий по математике. Не в них ли рождается склонность к отвратительному коду, ведь математику проходили все?

Статья будет полезна разработчикам, которым пришло распоряжение написать документацию к ПО, а также авторам учебных пособий вузов. Я не питаю иллюзий, что ситуация как-то изменится что у первых, что у вторых, но помечтать всё же хочется.

Важно: пример из статьи не является вымыслом или шуткой!

Ещё важней: статья не является критикой математики, математику я люблю.

Я уже плакался по поводу исключения в x86-64 команд двоично-десятичной арифметики DAA/DAS и плакался по поводу отмены команды проверки целочисленного переполнения INTO. Теперь настала очередь плакаться по поводу выброшенной команды BOUND. Как говорится, леди и джентльмены, подставляйте свои жилетки и декольте. Начинаю плач.

Машины Руба Голдберга «работают». А еще они неэффективные, хрупкие, их сложно изготовить и поддерживать. Поэтому написать код, который «просто работает» — очень низкая планка.

Многие не осознают, что написание кода во многом напоминает написание эссе или книги. Насколько же я был уверен, что умение писать эссе мне «в жизни не пригодится» - но позже я узнал, что писать эссе – значит гораздо больше, чем укладываться в число слов и соответствовать критериям оценки.

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

В первую очередь хочется убрать из языка то, что приводит к частым ошибкам и мешает развитию языка, тут идеальным кандидатом можно назвать

1 - union - сумм тип из 70х, в С идея хранения одного типа из нескольких в одном участке памяти выглядит неплохо и сейчас, ведь там все типы это набор байт с заданным размером.

В С++ же использование union это автоматическое undefined behavior, например:

Если вы уже устали читать статьи о том, как применять модульное тестирование в новых приложениях, в то время как ваша жизнь в основном занята расширением и улучшением унаследованного кода – изложу вам план, который (наконец-то) поможет воспользоваться возможностями автоматизированного тестирования при работе с имеющимися приложениями. Это проще, чем кажется, особенно, если вы переложите на Visual Studio и JustMock всю тяжелую работу.

Люблю читать статьи о том, как приступить к автоматизированному модульному тестированию, потому что они полностью оторваны от реальности. Во всех таких статьях предполагается, что вы выстраиваете некое свежее приложение с чистого листа, но такого – будем честны – практически не бывает. Все мы знаем, что от 70% до 90% времени разработчика тратится на улучшение, расширение, модификацию и (иногда) исправление приложений, которые уже работают в продакшене. А я еще я добавлю, что никто не захочет вам платить за обвязку модульными тестами таких «уже существующих/унаследованных» приложений.

Но, поскольку большая часть вашего времени тратится на внесение изменений в такие унаследованные приложения, вы можете сделать хотя бы две вещи:

time.sleep(300)

Thread.sleep(300)

threadDelay 300