В предыдущих статьях мы пришли к выводу, что для того, чтобы код не превращался в легаси, необходимо получать оперативный фидбек о его правильности, а также использовать хорошие шаблоны программирования. При соблюдении этих двух условий у нас появится возможность легко вносить изменения.
Однако, есть проблемы с текущими подходами к созданию пользовательского интерфейса, которые затрудняют достижение этих двух условий.
Бунтарём себя можно считать только тогда, когда люди на самом деле защищают противоположную вашей позицию. Я не согласен с одной из best practices, недавно представленной в Google Testing Blog . Обычно это очень хороший ресурс, ведь этот пост не случайно попал в мою читалку новостей!
Авторы представили две версии функции и спросили, какая из них более читаема.
Рассмотрим разницу между популярными ошибками при работе с многопоточностью, такими как Data Race и Race Condition, а также способами борьбы с ними.
Перечисления в Swift представляют собой мощный инструмент для создания собственных типов данных, которые ограничивают возможные значения. Они могут использоваться для улучшения читаемости кода, предотвращения ошибок и структурирования данных. Есть много замечательных статей по этой теме, но мне хочется рассмотреть эту тему более детально.
На код-ревью зачастую тратят слишком много времени и энергии. Перфекционизм часто заставляет размениваться на мелочи вместо сути, а холивары разрушают команды. Хотя есть специальные инструменты, задача которых автоматизировать процесс и убрать лишние споры, это часто не работает. Ведь всё взаимодействие с ESLint сводится к extend’у от популярных конфигурации типа airbnb. Проблема в том, что эти конфигурации не покрывают даже малую часть того, что на самом деле может ESLint.
Чтобы исправить ситуацию, нужно собрать мощный, оптимизированный, а главное, реюзабельный ESLint.
Это статья написана на основе доклада Дениса Красновского для FronendConf 2022. Денис, руководитель направления разработки и фронтэнд-лид в компании Домклик.
Некоторые оптимальные алгоритмы, оказывается, можно вывести из неоптимальных, пользуясь эквивалентными преобразованиями алгоритма. Бёрд и Меертенс разработали формализм, который устанавливает свойства функций высшего порядка map, fold, scan, позволяющие преобразовывать алгоритмы в эквивалентные. (См. также на Вики). Ниже представлен вольный перевод статьи Бёрда.
Рассмотрим задачу поиска максимальной суммы сегмента массива. Эту задачу можно переформулировать в виде математически точного ответа:
Для всех сегментов, которые можно получить из массива, необходимо посчитать сумму чисел, а затем среди всех таких сумм найти максимальную.
Написание кода похоже на соединение двух точек. Ожидаемо, что самым простым путем будет нарисовать прямую линию между точками А и Б.
Для большинства простых случаев это работает, но вот в реальной жизни, кроме соединения точек, вам придется еще и обходить различные препятствия. Но в целом — тут тоже никакой проблемы, кроме необходимости немного поманеврировать.
Давайте увеличим количество препятствий на порядок. Линия становится все более извилистой.
Теперь давайте заставим эти препятствия двигаться. Медленно, но достаточно для того, чтобы вызвать проблемы с необходимостью переподключения точек. Это уже не такая простая прямая линия, и начинает выглядеть куда серьезнее.
А если мы заставим двигаться не только препятствия, но и сами точки? Вдобавок убедимся, что эти точки не приклеены к линиям, и вам придется следить за ними, чтобы они оставались соединенными. Начинает немного бесить?
Привет, Хаброжители!
В программировании, чтобы создать надежные, безопасные и удобные в обслуживании приложения, крайне важно уметь контролировать, что становится видимым и как можно получить к этому доступ. И вот здесь на сцену выходят уровни доступа, подобно страховому полису для нашего кода: мы сами определяем, кто получает доступ к «игре», а кому вход закрыт.
Давай разберёмся подробнее, что это такое и как применять.
"Идеальный программист" Роберта Мартина давно стал руководством по профессионализму в сфере IT и одним из основополагающих трудов в современной разработке, наравне с "Чистым кодом", "Чистой архитектурой" и "Чистым эджайлом".
В посте ниже собраны наиболее значимые тезисы из "Идеального программиста".
В интернете невероятное количество статей о том "как написать свой генератор на С++20", но почти все они сводятся к новичковым хело вордам и почти ни одной статьи о том как написать хороший генератор. Что ж, это нужно исправлять!
Привет, Хаброжители!
Вас приветствует ваш зануда!
Если вы следите за моей ленивой активностью, то заметили бы, что у меня много от чего пригорает. Вот, например:
- У меня пригорает от низкосортных статей на потоке: Питон против Безумного Макса, или как я посты на Хабре замораживал
- У меня пригорает от Django: Окей, Джанго, у меня к тебе несколько вопросов
- И от Яндекса тоже: Собеседование в Яндекс: театр абсурда :/
- И от рекрутеров: Я единственный из 1400, или самый крутой рекрутинг, что я проходил
Посмотришь так - я уже давно должен был сгореть. Но я, аки феникс, возрождаюсь, и сегодня у меня горит от, внезапно, Питона, на котором я пишу больше десяти лет. Если вам интересно, что же, по моему мнению, с ним не так - то прошу под кат.
Вам когда-нибудь говорили, что вы пишете плохой код?
Здесь стыдиться нечего. Мы все пишем несовершенный код, когда только учимся. Хорошая новость в том, что улучшить его — довольно просто, главное — желание.
Один из лучших способов улучшить свой код — освоить принципы проектирования в объектно-ориентированном программировании. Можно сказать, что принципы программирования — это философия кода или руководство, как стать более крутым программистом.
Существует целый ряд принципов в программировании (я бы даже сказал, что их слишком много), но я расскажу о пяти основных, которые складываются в аббревиатуру SOLID.
Здравствуйте, всем! Хотя это моя первая публикация на Хабре, тему я хочу затронуть важную и далеко не всегда понятную новичкам. Не обращайте внимание на странный заголовок. Считайте, что это – ружье на стене, которое по ходу пьесы обязательно выстрелит.
Материал по этой теме здесь уже имеется, но на мой взгляд, информация там подана не совсем удачно и полно. Рискну внести свою лепту в дело понимания и запоминания такого фундаментального принципа.
В данной статье я постараюсь по максимуму избежать кода. Сделано это в целях повышения универсальности материала, он должен быть интересен всем читателям независимо от их языка программирования. В тех местах, где код неизбежно понадобится, он будет оформлен в синтаксисе Java. Не пугайтесь, все объясню, сложно не будет (во всяком случае, по моим расчетам). Итак, поехали!
Feature-Sliced Design — это архитектурная методология, активно набирающая популярность в последнее время. И не зря: организация разработки по её правилам позволяет упростить процессы, сделать их быстрее и гибче. Больше не нужно будет переживать из-за совместной работы в одном домене и конфликтов кода, долго искать ответ на вопрос «А куда же впилить новую фичу, тут и так намешано…»
О том, как устроена Feature-sliced Design, чем она отличается от «классической» организации кода, плюсах и минусах от её внедрения — в этой статье.
Для броского заголовка здесь надо было бы употребить термин «супер-оптимизация» или даже «гипер-оптимизация». Но приставки «супер» ко всему на свете настолько затасканы, что, например, вполне нормальный и даже научный термин «супер-программирование», стал больше ассоциироваться с достижениями каких-то неведомых «супер-программистов», а не с методами преобразования программ. С другой стороны, народное творчество определяет «супер-программирование» как программирование во время варки супа. Поэтому буду использовать не хвастливую «супер», а всего лишь скромную «мета».
Мета-оптимизация (или, еще проще, над-оптимизация) - это оптимизация, примененная к другим методам оптимизации. Мне очень нравится придумывать в компиляторе, который я сопровождаю, всякие оптимизации. Но применить мета-оптимизацию как-то не приходило в голову. Натолкнул случай.
Есть много метрик, которыми можно попытаться измерить качество нашего кода. И во времена первых компьютеров: дорогого железа, огромного потребления электричества, да даже дорогих перфокарт, ценились краткость и скорость выполнения.
Сейчас же, бывает, код меняется чаще, чем запускается. Компиляторы научились оптимизировать почти любые конструкции, а сервера стоят дешевле работы программистов. Поэтому на первое место выходит такое качество, как простота внесения изменений в проект. И немаловажный фактор — это легкость чтения и понимания кода.
Для меня хороший код читается также легко, как хорошая книга. И можно даже провести параллели между подходом к изложению своих мыслей в книге и спосбом выразить бизнес‑логику в коде.
Здесь собрано несколько советов, которые позволяют мне делать свой код человекочитаемым и простым для понимая коллегам. Ведь компилятор сможет прочитать любой синтаксически правильный код, а человек — нет.
Всем нам предстоит поддерживать уже существующий код, а также проводить ревью кода коллег.
Иногда становится очень тяжело видеть некоторые паттерны, которые кажутся безобидными, но при некорректном использовании или после неосторожного рефакторинга могут привести к различным проблемам: утечке горутин и каналов, повреждению целостности структур данных, паникам, трудноуловимым багам в бизнес-логике, самому страшному - неутолимому желанию порефакторить код, который выглядит как то, что вы бы написали в первый день работы с Go.
В своей статье я хочу дать рекомендации, которые, по моему мнению, могут помочь избежать перечисленных выше проблем.
