• Почему дизайн Go плох для умных программистов

    • Перевод

    На протяжении последних месяцев я использую Go для имплементаций Proof of Concept (прим.пер.: код для проверки работоспособности идеи) в свободное время, отчасти для изучения самого языка программирования. Программы сами по себе очень просты и не являются целью написания статьи, но сам опыт использования Go заслуживает того, чтобы сказать о нем пару слов. Go обещает быть (прим.пер.: статья написана в 2015) массовым языком для серьезного масштабируемого кода. Язык создан в Google, в котором активно им пользуются. Подведя черту, я искренне считаю, что дизайн языка Go плох для умных программистов.

    Читать дальше →
  • Автоматное проектирование. Практикум. Задача «Переправа»

      Велосипед изобрести — не речку переплыть. Задача «Переправа» поднималась дважды за пару месяцев, но я хочу отметить вот это решение, поскольку именно оно иллюстрирует удачный предметный взгляд, и даёт модель удачного ОА, которую остаётся только логически развить, что в итоге даст более совершенное решение, чем при иных взглядах на проблему.
      Читать дальше →
    • Повторное использование кода — как это бывает на практике

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

      Но когда дело доходит до этого на практике — чаще всего что-то идёт не так. Есть одна очень умная мысль на этот счёт: «Не пытайтесь делать код переиспользуемым, пока вы не видите как минимум три разных места, где его можно будет применить». Я считаю этот совет очень хорошим — я видел немало ситуаций, когда он помог (или помог бы) избежать одержимости попытками написания переиспользуемого кода там, где проблему можно было решить для одного конкретного случая «здесь и сейчас».

      Это указывает нам на изъяны в теории о том, что переиспользование всегда является желанной и благородной целью.
      Читать дальше →
    • Как мы контролируем качество кода в Браузере для Android. Лекция Яндекса

        Автор этой лекции — Константин Заикин kzaikin, руководитель группы разработки Яндекс.Браузера для Android в Санкт-Петербурге. Он рассказал об инструментах Android-разработчика и всей команды, а также о том, как справляться с legacy-кодом, публиковать большой проект вовремя и улучшать качество кода.


        — Друзья, привет. Я очень рад, что вас так много сегодня пришло. Я приехал из Питера, в Яндексе работаю около шести лет. Успел засветиться в Картах, Такси, Метрике и Поиске. Уже два года я работаю над Яндекс.Браузером для Android.

        Читать дальше →
      • Как написать свой сваггер и не пожалеть об этом

          image

          Как-то раз моему коллеге в беклог упала задача «хотим организовать взаимодействие с внутренним REST-api так, чтобы любое изменение контракта сразу приводило к ошибке компиляции». Что может быть проще? – подумал я, однако работа с получившимся кактусом вынудила заняться многочасовым курениям документации, спуску от привычных концепций оверинжинеринга «налепим побольше интерфейсов, добавим максимум косвенности, и приправим всё это DI» до переезда на .Net Core, ручной кодогенерации промежуточного ассемблера и изучения нового компилятора C#. Лично я для себя открыл много интересного как в рантайме, так и в структуре самого компилятора. Думаю, некоторые вещи хабровчане уже знают, а некоторые станут полезной пищей для размышления.
          Читать дальше →
        • Автоматная разработка, практикум. Пример «Дисплей». Часть 1

            Тесты в предыдущей статье убедительно показали высокую эффективность «автоматной» реализации примера «Дисплей» по сравнению с условно названной «неавтоматной» версией. Вкратце итог: обе реализации автоматные, но разница в эффективности многократна и глубинная причина видится в том, что вариант А1 («автоматный») изначально проектировался как автомат, а вариант А2 («неавтоматный») нет. Не столько автоматная реализация, сколько автоматное проектирование является основой высокой эффективности. Для простых алгоритмов автоматные реализации получаются сами собой. Есть смысл говорить о том, что автоматное программирование, это не столько реализация программы в виде конечного автомата, сколько автоматное проектирование, фундаментом которого является конструктивная декомпозиция. Я несколько раз касался темы автоматного проектирования и конструктивной декомпозиции, но чтобы раскрыть эту тему нужны практические примеры. В этой и следующих нескольких статьях я проведу практикум, покажу процесс автоматного проектирования, пытаясь по возможности приводить ход рассуждений присущих автоматному проектированию.
            Читать дальше →
          • AdBlock похитил этот баннер, но баннеры не зубы — отрастут

            Подробнее
            Реклама
          • Автоматное программирование. Часть 4. Эффективность автоматно-спроектированных программ

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

              Я бы сформулировал вопрос иначе: насколько эффективны автоматно-спроектированные программы? Такая формулировка вопроса намекает, что автоматное проектирование — источник высокой эффективности программ. Я ещё практически не касался столь важной темы как эффективность, и пример «Дисплей» идеально подходит для иллюстрации эффективности автоматного проектирования. В первой статье я познакомил читателей с «лабораторной» версией этого модуля, но тестировать я буду «боевой» вариант, процесс проектирования которого я приведу в следующей статье. Исследование эффективности будет выполнено для платформ msp430 и CortexM3.

              Чтобы не быть субъективным, оценивая эффективность, нужно с чем-то сравнивать результаты. Поэтому я проведу тот же комплекс испытаний для неавтоматной реализации примера «Дисплей» любезно предоставленной michael_vostrikov, за что ему огромная благодарность и плюсы в карму.

              Читать дальше →
            • Сервис-ориентированная архитектура (SOA)

              • Перевод


              Сервис-ориентированная архитектура (service-oriented architecture, SOA) придумана в конце 1980-х. Она берёт своё начало в идеях, изложенных в CORBA, DCOM, DCE и других документах. О SOA написано много, есть несколько её реализаций. Но, по сути, SOA можно свести к нескольким идеям, причём архитектура не диктует способы их реализации:


              • Сочетаемость приложений, ориентированных на пользователей.
              • Многократное использование бизнес-сервисов.
              • Независимость от набора технологий.
              • Автономность (независимые эволюция, масштабируемость и развёртываемость).

              SOA — это набор архитектурных принципов, не зависящих от технологий и продуктов, совсем как полиморфизм или инкапсуляция.

              Читать дальше →
              • +26
              • 12,2k
              • 2
            • JavaScript: путь к ясности кода

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

              image

              Программирование с учётом ясности того, что получается, это то, что отделяет великих разработчиков от разработчиков обычных. В этом материале мы хотим привести несколько базовых принципов, которые позволят вам сделать первые шаги на пути к ясному коду.
              Читать дальше →
            • Шаблон проектирования “минисценарий с проверкой противоречий”

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

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

                image

                В организации, где я работаю, автоматизируют бизнес процессы, и обычно это связано с ведением базы данных. У нас принято работать по канонам, — сначала проводить бизнес анализ, составлять умное ТЗ, писать код, проводить тестирование и много всякой деятельности при дефиците времени. Первичная мотивация, вроде разумная, — “давайте будем разделять обязанности”, “давайте будем делать так, чтобы было безопасно” и тд и тп. Все эти приемы менеджмента с восторгом преподают на различных курсах, обещая много хайпа и охмурянта. Надеюсь, что читатель уже знаком с некоторыми модными словами, которые зачастую ни потрогать, ни налить нельзя. Но вопрос не об них, а о том, как программисту жить с ними.

                Далее постараюсь объяснить, в чем разница между “бизнес логикой” и “строгой логикой”, на которую почему-то многие не обращают достаточного внимания. В результате оголтелого использования бизнес логики страдает просто логика, за которую боролись и математики и философы сотни лет. А когда страдает настоящая логика, то вместе с этим страдают сначала исполнители-технари, которые от безысходности могут начать лепить несуразное, чтобы лишь бы начальники отвязались. А потом бумерангом страдания возвращаются на источник “ярких супер бизнес идей”, заставляя их придумывать другие еще более “яркие супер бизнес идеи” или в конце концов надевать накладную бороду и темные очки, чтобы больше никто не узнавал на улице и не показывал пальцем.
                Читать дальше →
              Самое читаемое