Проверяя код проекта TDengine с помощью PVS-Studio, можно встретить код с запахом, канонические ошибки и опечатки. Многое из этого можно избежать, если изначально аккуратно оформлять код, делать логику простой и избегать макросов. Давайте рассмотрим некоторые фрагменты кода и подумаем, как можно провести его рефакторинг так, чтобы багам просто не было там места.
Сергей Каличев, старший разработчик, Angie Software
Однажды, давным-давно, я наткнулся на одну хорошую статью по разработке переносимого кода и решил её перевести. Когда же это было... ё-моё, в 2008 году, 17 лет назад! Обалдеть, как время летит. Статья называлась "Fighting the Lemmings", автор Martin Husemann. Выложил перевод на LOR. С тех пор много воды утекло и, когда я попытался поискать статью в Интернете, то обнаружил, что ни оригинальной статьи, ни перевода, найти практически невозможно. Перевод ещё сохранился в глубоких закромах OpenNet, а оригинал только в архиве Интернета. Ссылки на PDF-ки тоже протухли и больше не работают. Обидно, это ведь такая нетленка для системщиков. Понятно, что переносимость уже сто раз пережёвана в других статьях и книгах, но тут всё было сконцентрировано и написано доходчиво. При этом актуальность до сих пор не потеряна. Ну а что, собственно, кардинально поменялось в разработке переносимого кода на C с тех пор? Если не обращать внимание на упоминания некоторых архитектур и ОС, которые сейчас, да и во времена перевода, звучат, как придания старины глубокой, то в остальном, обо всех особенностях разработки переносимого кода, описанных в статье, надо помнить и сегодня. Выкладываю текст, как он есть, без каких-либо современных правок.
Для тех, кому удобнее читать в PDF, вот ссылки:
А теперь сама статья.
Разработчики любят чистый код, а "Правило бойскаута", по слухам, делает его еще чище. На первый взгляд, подход кажется разумным: исправляешь мелкие недочёты, переименовываешь переменные, удаляешь лишние комментарии — удобно, быстро, безопасно. А главное, можно сказать, что внёс вклад!
Однако если такие правки не решают реальных проблем, это превращается в поверхностный рефакторинг, создающий лишь иллюзию прогресса. Это можно описать метафорой low-hanging fruit — когда разработчики выбирают самые лёгкие и очевидные задачи, избегая более сложных и значимых изменений.
Многие знают, что чистота кода влияет на его поддержку и стабильность, но что насчёт ошибок? В этой статье мы на реальных примерах рассмотрим, как грязный код может стать источником проблем, а также найдём способы их решить.
Привет, Хабр!
Вот варюсь я в этом айти уже долгое время. Почитываю Хабр, ищу работу, работаю, потом снова ищу работу. Посмотрел разные компании изнутри, крупные и не очень. Сходил за свою жизнь на 25+ собеседований, еще до времен удаленки и на на ней.
Я честно, не знаю как в других профессиях, но в программировании, как мне кажется, собеседования — это чистая лотерея. Мое видение этого возможно подтверждает рынок труда — накрути себе опыта побольше, примени нейросеть, расскажи красиво о себе и вот работа (зарплата) мечты уже твоя. Следствием этого — по 300 отзывов на вакансию. Но, к слову, вакансии эти висят месяцами. Ты просто попадаешь в огромную кучу кандидатов, которых работодатель хочет отсеять и выбрать лучшего из вас. По каким критериям (по всем кроме трудовой книжки) вас будут сортировать одному Нео известно. Так‑же имел личный опыт, когда я отвечал полностью на все вопросы в течение часа. Получив оценку своим знаниям на 5+, заветную работу (зарплату) мечты я так и не получил.
Привет, на связи Лука.
Мне всегда было интересно узнать больше о чистой архитектуре и о том, как построить систему, которая будет простой, но при этом выполнять всё, что от неё требуется. Естественно, без ухода в крайности, результат — наше всё, в булочную на такси не поедем.
Со временем вырисовываются какие-то паттерны и принципы, к которым лежит душа. У каждого свои: кто-то горит TDD, кто-то ATDD, FDD, BDD и прочими DD. Я же больше всего прикипел к DDD, причём первая D тут варьируется: угораю как по Domain, так и по Data.
В публикации речь пойдет о подходах в разработке ПО. Речь пойдет о некой компании, которой никогда не существовало и порядки, заведенные в ней – это исключительно собирательный образ. Если вы решили, что в вашей компании очень похожая ситуация, то это совпадение.
Сейчас среди Java/Kotlin команд распространено применение Чистой (ака Гексагональной, ака Луковой — Clean, Hexagonal, Onion) архитектуры для разработки бакэндов прикладных приложений (да и Android‑приложений тоже). Однако это семейство архитектур в контексте прикладной разработки зачастую не даёт никаких преимуществ, а только привносит лишние церемонии и тем самым замедляет её.
В этом посте я подробно разбираю, почему, на мой взгляд Чистая архитектура не является лучшим выбором по умолчанию для прикладных приложений, и кратко рассказываю об альтернативной архитектуре (спойлер: Промышленная функциональная архитектура), которую использую в качестве дефолтной последние 3 года и пока что доволен.
Но перед тем как перейти к Чистой архитектуре, сначала надо разобрать принцип инверсии зависимостей (Dependency Inversion Principle, DIP).
Проверяя код проекта TDengine с помощью PVS-Studio, можно встретить канонические ошибки и опечатки. Многих из них можно избежать, если изначально аккуратно оформлять код, делать логику простой и избегать макросов. Давайте посмотрим на эти ошибки и подумаем, как можно повести рефакторинг кода так, чтобы им просто не было там места.
В этой статье попробуем разобраться, почему ООП — худшее, что было придумано в программировании, как оно стало таким популярным, почему опытные программисты Java (C#, C++ и т.п.) в принципе не могут считаться крутыми инженерами, а код на Java - хорошим.
Чистый код — это не просто стиль программирования, это философия, которая делает ваш код понятным, поддерживаемым и эффективным. В этой статье мы разбираем ключевые принципы написания чистого кода: от правильного использования уровней абстракции и разделения функций до борьбы с глубокой вложенностью и неожиданными побочными эффектами. Вы узнаете, как избегать распространённых ошибок, таких как смешение уровней абстракции, избыточные проверки и сложные управляющие структуры. Мы также рассмотрим, как полиморфизм, фабричные функции и обработка ошибок могут помочь вам писать более чистый и читаемый код. Статья подойдёт как начинающим, так и опытным разработчикам, которые хотят улучшить свои навыки и сделать свой код более профессиональным.
Всем привет! Я Екатерина Васильева, старший инженер по автоматизации тестирования в InfoWatch, и сегодня хочу поделиться своими наработками в области автотестирования веб-сайтов. В процессе работы нужно было работать со сторонними сайтами – в нашем случае это были VK, Telegram, Yandex Messenger, Whatsapp, и попросить разработчиков создать специальные ключи для автотестов было невозможно. Поэтому на данном проекте пригодился мой десятилетний опыт в автотестировании, в частности – составлении локаторов. Так как сайты сторонние была особенно актуальна тема стабильных локаторов. В статье делюсь информацией, необходимой для составления устойчивых локаторов – то есть таких, которые не нужно будет часто менять. Это крайне необходимо для автоматизации, когда локаторы вполне могут поменяться из-за обновления тегов и их атрибутов программистами, например, во время рефакторинга или написания нового функционала.
Здравствуйте! Сегодня мне хотелось бы обсудить с вами один армейский принцип, который может оказаться невероятно полезным при написании и поддержке вашей кодовой базы.
В прошлой части я перечислил советы по развитию качества принятия решений. В этот раз поговорим о практических принципах, которые можно брать и использовать «здесь и сейчас».
Подходов, советов и принципов существует очень много, и их можно отобрать и классифицировать по-разному, в зависимости от того, чему отдать приоритет. В данном случае я отобрал то, что влияет на поддерживаемость кода, надежность и удобство работы с системой.
Я исхожу из того, что по мере развития система должна упрощаться: упрощаться кодовая база, увеличиваться прозрачность работы компонентов и их взаимодействия. Звучит абсурдно, ведь новые фичи добавляются и добавляются. Но в то же время разработчики лучше понимают, с чем имеют дело — проясняется предметная область и сценарии использования. Выявляются похожие по смыслу вещи, они объединяются. Неудачные решения заменяются на более удачные.
Принципы, которые я перечислю дальше, конечно не 100-процентная истина. Как всегда, все хорошо к месту. Например, если сопоставляются два варианта, и обычно, при прочих равных, один вариант лучше, то все-равно найдется ситуация, когда лучше использовать другой вариант. Но даже сама идея о том, что существуют варианты и есть некий критерий выбора, поможет принять осознанное решение.
Когда это все может пригодиться? На стадии дизайна, при реализации и на код-ревью. Другими словами — всегда.
Итак, вот несколько идей, которые можно использовать, когда нужно сделать выбор.
Разберём ключевые принципы именования переменных, проектирования функций и других аспектов, чтобы писать код, который будет понятен вам и вашей команде спустя годы.
Статический анализ важно проводить регулярно, но что делать, если анализ всего проекта занимает много времени? В статье отвечаем на этот вопрос и делимся рецептами для конкретных ситуаций.
В мире видеоигр эмуляторы стали настоящей находкой для поклонников классических проектов. PPSSPP — один из самых популярных эмуляторов для PlayStation Portable (PSP), который позволяет нам вновь окунуться в атмосферу любимых игр, но уже на современных устройствах. Однако чтобы играть без сбоев и лагов, нужно убедиться, что код эмулятора хорошо написан.
Всем привет!
Это перевод статьи Clean Code in Python. В данной статье Nik Tomazic рассказывает о чистом коде, его преимуществах, различных стандартах и принципах, но что самое главное– он дает общие рекомендации по написанию чистого кода. Прочитав данную статью в оригинале, я понял, что это именно то, что я хотел бы прочитать в самом начале своего пути разработки на Python. Именно это и вдохновило меня на создание первого перевода, а вместе с этим, и первой публикации на Хабре.
Роберт Мартин нехило так повлиял на айти‑индустрию. Он придумал принципы SOLID, о которых спрашивают на собесах, пишут статьи на хабре и спорят в комментариях. Он написал книгу «Чистый код» и сделал это словосочетание айтишным мемом. Если зайти на хэдхантер, вбить в поиске слово «чистый», выбрать специализацию «Программист, разработчик» и нажать «Найти», получим больше семисот вакансий. Про чистоту кода и архитектуры спорят на код‑ревью, в комментариях и статьях по всему интернету. Разговоров о чистоте внутри айти‑тусовки бывает так много, словно мы находимся в сообществе клинеров, а не программистов.
Мартин называет себя «дядюшкой Бобом». В своих работах он выступает в образе опытного мудрого и взрослого родственника, который несёт свет и знания таким зелёным и неопытным племянникам. И у него отлично получилось втереться в доверие! Типичный хороший программист‑анальник бессилен перед таким добрым дядей. И я знаю, о чём пишу. Восемь лет назад я сам запоем читал книги дядюшки, а потом до усрачки защищал чистоту кода на код‑ревью. Я на себе почувствовал, насколько Роберт Мартин отличный агитатор и пропагандист. Работая с другими людьми, читая статьи и обсуждения на Хабре и хакерньюс, анализируя требования к вакансиям, я понимаю, что не я один попался на отличную пропаганду от «дядюшки Боба».
В мире разработки программного обеспечения существует множество "священных коров" — принципов и практик, которые принимаются как данность и редко подвергаются критическому анализу. Особенно показательна ситуация с принципами SOLID на русскоязычных ресурсах: достаточно открыть Хабр, чтобы найти 100500 статей о SOLID, и в каждой из них принципы интерпретируются по-разному.
Само существование такого количества "объяснительных" статей говорит о фундаментальной проблеме: если принципы требуют толкования, значит их названия не являются самодостаточными и интуитивно понятными. А если каждый разработчик понимает принципы по-своему, возникает вопрос — зачем вообще нужны принципы, которые не дают однозначного руководства к действию? Принципы SOLID, предложенные Робертом Мартином, давно стали одной из таких "священных коров". Однако пришло время честно признать: то, как мы используем SOLID сегодня, часто противоречит изначальным идеям и в целом иногда может приносить больше вреда, чем пользы. Зависит от контекста.
Самый яркий пример искажения первоначального замысла — это интерпретация принципа единственной ответственности (SRP).
