Перед вами обновлённая коллекция вредных советов для C++ программистов, которая превратилась в целую электронную книгу. Всего их 60, и каждый сопровождается пояснением, почему на самом деле ему не стоит следовать. Всё будет одновременно и в шутку, и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования.
Совершенный код *
Как Макконнелл завещал
Книга «Роберт Мартин рекомендует. Код, который умещается в голове: эвристики для разработчиков»
Незаменимые практические советы по написанию кода в устойчивом темпе и по управлению сложностью, из-за которой проекты часто выходят из-под контроля. В книге описываются методы и процессы, позволяющие решать ключевые вопросы: от создания чек-листов до организации командной работы, от инкапсуляции до декомпозиции, от проектирования API до модульного тестирования. Автор иллюстрирует свои выводы фрагментами кода, взятыми из готового проекта. Написанные на языке C#, они будут понятны всем, кто использует любой объектно-ориентированный язык, включая Java, C++ и TypeScript. Для более глубокого изучения материала вы можете загрузить весь код и подробные комментарии к коммитам.
Как проводить кодревью?
На работе предложили прочитать доклад. Вуаля! Далее расскажу:
✓ Что такое кодревью?
✓ Зачем нужен?
✓ Что проверяем?
✓ Типовые проблемы & решения
✓ БОНУС!!! Результаты опроса: «Как вы делаете кодревью?»
60 антипаттернов для С++ программиста, часть 4 (совет 16 — 20)
Перед вами обновлённая коллекция вредных советов для C++ программистов, которая превратилась в целую электронную книгу. Всего их 60, и каждый сопровождается пояснением, почему на самом деле ему не стоит следовать. Всё будет одновременно и в шутку, и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования.
Истории
60 антипаттернов для С++ программиста, часть 3 (совет 11 — 15)
Перед вами обновлённая коллекция вредных советов для C++ программистов, которая превратилась в целую электронную книгу. Всего их 60, и каждый сопровождается пояснением, почему на самом деле ему не стоит следовать. Всё будет одновременно и в шутку, и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования.
60 антипаттернов для С++ программиста, часть 2 (совет 6 — 10)
Перед вами обновлённая коллекция вредных советов для C++ программистов, которая превратилась в целую электронную книгу. Всего их 60, и каждый сопровождается пояснением, почему на самом деле ему не стоит следовать. Всё будет одновременно и в шутку, и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования.
По горячим следам: как обходили PT Application Inspector на Standoff 11
Недавно завершилась одиннадцатая кибербитва Standoff, проходившая в рамках Positive Hack Days 12 в московском Парке Горького. C 17 по 20 мая 22 команды белых хакеров атаковали государство F — виртуальный город с собственной железнодорожной инфраструктурой, атомной станцией, заводом по обогащению урана, солнечной электростанцией и другими объектами. В одном из его сегментов располагалась сеть IT-отдела авиакомпании, принадлежащей Heavy Logistics. По легенде у отдела разработки был выстроен процесс безопасной разработки: код проверялся с помощью PT Application Inspector.
Сразу обратим ваше внимание, что эта ситуация была смоделирована специально для кибербитвы Standoff для того, чтобы PT Application Inspector, задача которого искать уязвимости, мог еще и обнаруживать зловредный код. Поэтому «обошли» его только в рамках кибербитвы и заложенных в нее сценариев возможных атак.
Красным требовалось внедрить «закладку» в исходный код разрабатываемого приложения и сделать так, чтобы для SAST-анализатора она выглядела безопасной. В случае успеха они могли бы выполнить произвольный код на удаленном сервере компании.
Что рассмотрим в статье:
· особенности внедрения SAST-анализатор в кибербитву Standoff,
· попытки хакеров обойти анализатор,
· итоги и планы.
60 антипаттернов для С++ программиста, часть 1 (совет 1 — 5)
Перед вами обновлённая коллекция вредных советов для C++ программистов, которая превратилась в целую электронную книгу. Всего их 60, и каждый сопровождается пояснением, почему на самом деле ему не стоит следовать. Всё будет одновременно и в шутку, и серьёзно. Как бы глупо ни смотрелся вредный совет, он не выдуман, а подсмотрен в реальном мире программирования.
Принцип подстановки Барбары Лисков
Принципы проектирования SOLID были представлены Робертом Мартином в его книге “Design Principles and Design Patterns” в 2000 году. Эти принципы помогают нам создавать более гибкое программное обеспечение, которое легко понимать и обслуживать.
В этой статье мы обсудим “Принцип подстановки Барбары Лискофф”, который соответствует букве L в акрониме SOLID.
Что в имени тебе моём? Часть 2
Как известно, интерпретируемые и компилируемые языки имеют преимущества и недостатки относительно друг друга. Одним из таких преимуществ/недостатков является сохранение связи имени переменной из исходного текста с соответствующим объектом программы во время выполнения.
Для интерпретируемых языков эта связь естественным образом сохраняется, так как интерпретатор собственно и «выполняет» исходный текст программы, т.е. имеет к нему непосредственный доступ.
В случае же компилируемых языков, имена переменных из исходного текста уже были использованы на этапе компиляции и обычно на этапе выполнения недоступны и кажутся ненужными.
Я уже писал заметку об этом и вот решил продолжить тему второй частью. Для тех, кто не любит ходить по ссылкам, кратко напомню, о чем шла речь в первой части.
Что такое абстрактные классы и методы в Java
В Java абстрактные классы и методы – это основные инструменты для реализации абстракций. Абстрактные классы служат шаблонами для создания субклассов, а абстрактные методы можно сравнить с чертежами, описывающими поведение этих субклассов.
Если вы новичок в Java или хотите освежить знания о том, чем отличаются абстрактные классы или интерфейсы, то можете почитать руководство и на эту тему: Difference Between Interface and Abstract class in Java.
Пишем на Python, как будто это Rust
Я начал программировать Rust несколько лет назад, и эта работа постепенно позволила мне изменить подход к проектированию программ и на других языках. В особенности заметен этот эффект был на Python. Прежде, чем я приступил к использованию Rust, я обычно писал код Python в очень динамичном стиле со свободной типизацией, без подсказок типов. Я повсюду передавал и возвращал словари, от случая к случаю прибегая к интерфейсам со «строковой типизацией». Правда, ощутив на себе всю строгость системы типов Rust и познакомившись со всеми теми проблемами, которые Rust решает «по природе», я вдруг сильно разволновался, когда пришлось вернуться к Python, и оказалось, что там и близко нет таких гарантий, как в Rust.
Код-ревью: cookbook от Google
Страницы этого документа содержат рекомендации по лучшим практикам код-ревью, основанные на многолетнем опыте компании Google. Это один законченный документ, разбитый на разделы. Необязательно читать их все, но многие прочитали документ целиком и нашли это полезным.
От автора перевода: в Google вместо PR (Pull Request) принято использовать аббревиатуру CL (ChangeList — список изменений). Остальные термины, на мой взгляд, понятны и без пояснений. Чтобы разбавить кучу текста, в качестве разделителей разделов использованы генерации на тему "код-ревью от разных мультипликаторов" от нейросети Kandinsky.
Ближайшие события
Пишем на Python как на Rust
Я начал программировать на Rust несколько лет назад, и это постепенно изменило мой подход к разработке программ на других языках программирования, особенно на Python. До того, как я начал использовать Rust, я обычно писал код на Python очень динамично, без подсказок типов, повсюду передавая и возвращая словари и время от времени возвращаясь к интерфейсам со «строковой типизацией». Однако, испытав на себе строгость системы типов Rust и заметив все проблемы, которые она предотвращает, я внезапно стал сильно беспокоиться всякий раз, когда возвращался к Python и не получал тех же гарантий.
Как дебажить код на JavaScript: примеры ошибок и советы новичкам
Привет, Хабр! Меня зовут Алексей Гмитрон, я наставник на курсе «Веб-разработчик» Практикума, а также работаю фулстек-разработчиком.
Я начал программировать шесть лет назад, и обучение не сразу давалось легко. Одна из главных проблем — не умел выяснять, почему мой код не работает. Это долго тормозило развитие, но когда я начал понимать принцип, как думать при поиске ошибок — процесс сдвинулся с мертвой точки.
Сейчас я преподаю в Практикуме, и ко мне на индивидуальные консультации часто приходят студенты с той же проблемой. Мы дебажим их код вместе, и за десятки подобных сессий я заметил общие трудности новичков в процессе отладки собственного кода. В этой статье расскажу о привычках, которые нужны самостоятельному разработчику для дебага.
Эта статья предназначена для тех, кто только недавно научился писать свои первые программы на JavaScript и испытывает трудности при поиске багов. Статья не столько, не про конкретные инструменты и вкладки в DevTools, сколько про то, о чём думать и куда смотреть при отладке.
Чистый код. Часть 3
Привет! Этим постом я завершаю цикл из конспектов видеолекция Дяди Боба про чистый код.
Сегодня обсудим обработку исключений, комментарии к коду, форматирование, размеры файлов и дата-классы.
Обработка исключений
Не раскрывайте реализацию
Майкл Физерс (Working effectively with legacy code) сказал: «Если обработка ошибок раскрывает реализацию — то это неправильная обработка ошибок». Не раскрывать реализацию можно, если написать исключения перед тем, как написать реализацию функции (привет TDD — по-другому и не получится).
Рассмотрим классCommissionCalculator
, который обменивает сумму в разных валютах.
Код-ревью: зачем нужен и как его правильно готовить
QA Lead из международной компании рассказал о важности код-ревью, необходимых компетенциях ревьюеров, а также об искусстве правильно составлять фидбэк и реагировать на него.
Меня зовут Андрей Ходырев, и в профессии я достаточно давно — с 2011 года. Сейчас моя должность — ведущий инженер по тестированию. В последнее время занимаюсь не только тестированием и автоматизацией, но и разработкой. Я наставник в Практикуме на курсе автоматизатор тестирования на Java с августа прошлого года и занимаюсь там процессом улучшения код-ревью.
Blink: супербыстрый эмулятор x86_64 размером 119 КБ
На Хабре когда-то писали про талантливую программистку Джастин Танни, автора маленьких и очень быстрых приложений. Приятно знать, что она не останавливает свою неординарную деятельность. Например, одна из её последних разработок — крошечный эмулятор под названием Blink размером всего 116 КБ, который очень быстро компилирует WASM и выполняет Linux-программы x86_64 под разными платформами и даже в браузере.
Облегчаем жизнь разработчиков на Go: полезные советы и лайфхаки для начинающих
В #CloudMTS мы активно используем Go. Например, Go основной язык в балансировщике нагрузки (GSLB), в сервисах создания и управления кластерами PostgreSQL и Redis.
Благодаря производительности, скорости, встроенной поддержке параллелизма, упрощенному синтаксису, Go становится естественным выбором при написании облачных сервисов.
Сегодня поговорим об инструментарии и подходах, которые помогают получить читаемый и поддерживаемый код, а вместо с ним — производительные и надежные сервисы. Backend-разработчик в подразделении DBaaS Герман Лепин (german_lepin) выступил экспертом для нашей статьи.
Проектируем flutter-приложение «чистым» способом используя bloc
Спроектировать и построить приложение не так-то просто. Как правило, всё упирается в продуманную архитектуру, которая должна быть масштабируемой и легко поддерживаемой. Данный материал предлагает вполне элегантный способ, в некотором роде основанный на чистой архитектуре (Clean Architecture).
Рассмотрены:
• взаимодействия слоёв
• структура папок
• основные характеристики каждого уровня
Предлагаю определить сильные и слабые стороны данного предложения.
Вклад авторов
fillpackart 976.6Andrey2008 947.6PsyHaSTe 619.4AloneCoder 567.2valemak 474.0kesn 393.0spiff 370.0Tomcat 356.0alizar 316.8Delka 301.0