• Читабельность кода

    • Перевод


    С помощью кода создаются интерфейсы. Но и сам код — это интерфейс.


    Несмотря на то, что читабельность кода очень важна, понятие это определено плохо — и часто в виде просто набора правил: использовать осмысленные имена переменных, большие функции разбивать на меньшие, применять стандартные шаблоны проектирования.

    При этом наверняка всем приходилось иметь дело с кодом, который соответствует этим правилам, но почему-то представляет собой какую-то кашу.

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

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

    Таким образом, набор инструкций — не выход. Поэтому нам придется сформировать более широкое представление о читабельности кода.

    Для чего нужна читабельность


    На практике под хорошей читабельностью обычно понимают, что код приятно читать. Однако на таком определении далеко не уедешь: во-первых, оно субъективно, во-вторых — привязывает нас к чтению обычного текста.

    Нечитабельный код воспринимается как роман, который притворяется кодом: множество раскрывающих суть происходящего комментариев, простыни текста, которые нужно читать последовательно, умные формулировки, единственный смысл которых — быть «умными», боязнь повторного использования слов. Разработчик пытается сделать код читабельным, но нацеливается не на тот тип читателей.

    Читабельность текста и читабельность кода — не одно и то же.

    Переведено в Alconost
    Читать дальше →
  • Дзен Эрланга [и Эликсира — прим. переводчика]

    • Перевод

    Введение от переводчика


    В данной статье речь идёт об Erlang, но всё сказанное в равной степени применимо и к Elixir — функциональному языку, работающему поверх той же виртуальной машины BEAM. Он появился в 2012 году и сейчас активно развивается. Elixir получил более привычный большинству синтаксис плюс обширные возможности метапрограммирования, сохранив преимущества Erlang.


    Ещё от переводчика

    Статья от 2016 года, но речь в ней идёт о базовых концепциях, которые не устаревают.


    Ссылки на понятия и комментарии от меня (переводчика) расположены в квадратных скобках [] и снабжены указателем "прим. переводчика".


    Если вы найдёте какие-то части перевода недостаточно корректными, особенно в плане терминов, или столкнётесь с любыми другими ошибками — дайте мне, пожалуйста, знать, с удовольствием исправлю.


    Отдельное спасибо Яну Гравшину за помощь в вычитке и редактуре текста.


    Это свободная расшифровка (или долгий парафраз?) моей презентации на организованной Genetec конференции ConnectDev'16.


    001


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

    Читать дальше →
    • +26
    • 3,5k
    • 8
  • Новые языки программирования незаметно убивают нашу связь с реальностью



      Однажды настанет день, когда команды в программировании будут выглядеть вроде «эй, компьютер, сделай-ка мне вот эту хреновину».

      Что там будет под капотом, ни одна живая душа уже не поймет. Команда «хреновина» интерпретируется в абзац с описанием, который интерпретируется в ключевые слова, который интерпретируется в набор векторных обозначений, который интерпретируется в какой-нибудь С, который скомпилируется в…

      и где-то там внизу превратится в электрические импульсы на железяках.

      Программистами станут лощеные гуманитарии с «высокими вербальными способностями, коммуникативными навыками и умением быть няшей в команде». Слава богу до этого дня, как до Аляски на упряжке, но каждый раз изобретая очередной Kotlin, мы этот день приближаем.

      Просто я задумался — а не стали ли наши ЯПы уже чем-то таким? Чуть более умным эквивалентом фразы «компьютер, сделай хреновину». Кучей формализованных протоколов для электричества, про которое мы уже забыть забыли. Штукой, которая все сильнее рвет нашу связь с механической реальностью.

      Я часто слышу фразу: «Фил, отступись, хватит думать обо всякой чепухе». Но блин, будь проклят тот день, когда на Хабре напишут «хватит думать».
      Читать дальше →
    • Качество кода

        Качество кода — тема, которая родилась вместе с программированием. Для оценки и контроля качества менеджмента предприятий применяется ISO 9000, для продуктов — ГОСТ и тот же ISO, а вот для оценки качества кода ГОСТа нет. Точного определения и стандарта для качества кода тоже нет.



        Каждый разработчик понимает качество по-своему, исходя из опыта. Представления джунов и лидов различаются, и это приводит к разногласиям. Каждая команда для отдельных проектов оценивает код по-своему. Команда обновляется, разработчики уходят, тимлиды сменяются — определение качества меняется. Эту проблему попробует помочь решить Иван Ботанов (StressoID) из Tinkoff.ru — Frontend-developer, преподаватель онлайн-курса по Angular, спикер на митапах и конференциях, ведущий уроков на YouTube и, иногда, тренер команд в компаниях.

        В расшифровке доклада Ивана на Frontend Conf поговорим о читаемости, нейминге, декларативности, Code style, и косвенно коснемся отношений джунов и лидов: ошибки, грабли и «сгорание» тимлидов.

        Disclaimer: Подготовьтесь морально, в тексте будет много плохого кода, взятого с «особенного» сайта.

        Читать дальше →
      • О статическом анализе начистоту

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


          Читать дальше →
          • +32
          • 5,2k
          • 2
        • KISS Architecture. От микросервиса до монолита

          Андрей Копылов, наш технический директор, рассказывает, какой подход к проектированию архитектуры приложений использует команда веб-разработчиков AREALIDEA, и, чем KISS Architecture, его собственная разработка, так хороша.


          Читать дальше →
        • Холиварный рассказ про линтеры 

            Все мы пишем код. Много кода. Само собой, бывают ошибки. Иногда это просто кривой код, а иногда цена ошибки — взорванный космический корабль. Конечно, никто не делает намеренных косяков, все в меру возможностей стараются следить за качеством, но без инструментов статического анализа вряд ли можно быть уверенным, что всё идеально.

            Линтеры помогают приводить код к единому стилю и избегать ошибок. Правда, только в том случае, если вы готовы к страданиям, а не отмахиваетесь в конце концов «pylint: disable», только чтобы оно отстало. Какой должен быть линтер, и почему таки не обойтись Pylint, знает Никита Соболев (sobolevn), который понимает и любит линтеры настолько, что даже свою компанию назвал так, чтобы их не расстраивать — wemake.services.

            image

            Ниже текстовая версия доклада на Moscow Python Conf++ про линтеры, как их делать правильно и как не нужно. В выступлении было много интерактива, онлайна и общения с аудиторией. Спикер по ходу дела проводил опросы и старался переубедить слушателей: смотрел на тренд, и как в дебатах, пытался выровнять соотношение и поменять общественное мнение. Какая-то часть с опросами попала в расшифровку, но не вся, поэтому для полноты картины прилагается видео.
            Читать дальше →
          • В разработке — каждый сам за себя. Но иногда это приводит в тупик



              Я чёртовы сутки просидел над таской. Нужно было спроектировать самостоятельный модуль, а людям с тяжелой формой перфекционизма нельзя давать задачи на проектирование.

              У меня была неделя — целая бесконечность, которой мне не хватило. Снова и снова я перебирал в голове варианты использования того, что должен сделать, но картинка идеального модуля не клеилась. Всегда находился кейс, который хорошо показывал: такой дизайн — говно. Я думал, играл на гитаре, пробовал писать, тупил в монитор, гуглил, играл с детьми, снова думал — голова всегда была занята дурацким модулем.

              В последний день я был на пределе, потратил двадцать часов на работу не вылезая. И вот — вечер воскресенья, я безумно хочу спать, но всё ещё сижу и пытаюсь придумать подходящее название для какого-то класса в своём псевдокоде, чей дизайн, конечно же, отправиться на помойку сразу, как только я его закончу, потому что он слишком неидеальный. За несколько часов до дьюдейта у меня не было ничего, кроме убитой поисками недели.

              В понедельник утром я отправил пулл реквест. Его приняли с восторгом. Но способ, на который я пошел… вот уж никогда не думал, что отважусь на такое.
              Читать дальше →
            • Lazarus — простая анимация при помощи компонента TImageFragment

              • Tutorial
              Вместо предисловия

              В моей недавней статье Lazarus — пишем компонент для анимации спрайтов я описал процесс создания простого компонента TImageFragment, позволяющего отображать заданный фрагмент изображения.

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

              При таком подходе отдельные кадры анимации в разных проекциях размещаются на одном изображении, а компонент для отображения спрайта показывает только один выбранный фрагмент этого изображения, используя свойства OffsetX и OffsetY (смещение левого верхнего угла фрагмента изображения по горизонтали и по вертикали).

              Множество таких готовых изображений можно найти в Сети — например, вот на этом сайте.
              Читать дальше →
            • Lazarus — пишем компонент для анимации спрайтов

              • Tutorial
              Вместо предисловия

              В одесской школе ученики 8-го класса на уроках информатики используют бесплатную кроссплатформенную среду разработки Lazarus (официальный сайт), внешне и внутренне очень напоминающую любимый многими Delphi, использующую версию Object Pascal под названием Free Pascal и в действительности сильно упрощающую процесс вхождения в программирование.

              Но детям неинтересно писать программу для вычисления силы тяжести по непонятной им пока формуле F=mg. Практически все дети, которых я пытался учить программированию, с первого занятия хотят написать игру. К счастью, Lazarus прекрасно подходит и для написания несложных игр.

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

            Самое читаемое