Рубрика «Совершенный код» - 29

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

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

Читать полностью »

image

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

Читать полностью »

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

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

Читать полностью »

Сервис-ориентированная архитектура (SOA) - 1

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

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

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

Читать полностью »

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

image


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

Code review по-человечески (часть 2) - 1

Это вторая часть статьи о том, как правильно общаться и избежать ошибок в процессе код-ревью. Здесь мы поговорим о том, как довести ревью до конца и избежать неприятных конфликтов.

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

Моё худшее код-ревью

Худшее код-ревью в моей жизни было для бывшей коллеги, назовём её Мэллори. Она начала работать в компании за несколько лет до меня, но только недавно перешла в мой отдел.
Читать полностью »

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

У меня иногда складывается впечатление, что не он служит для нас, а мы служим для этого формата. Поэтому — сэр Markdown.

Читать полностью »

В предыдущей статье речь шла о психологических аспектах описания динамических процессов при помощи диаграммы состояний и переходов (то есть в автоматном стиле) и о том, что диаграмма состояний и переходов даёт лучшее понимание динамического процесса. Сегодня я продолжу рассмотрение диаграммы состояний, олицетворяющей автоматный подход, и способы её воплощения в код. Тема предыдущей статьи органично перетекает в сегодняшний материал, поэтому я рекомендую ознакомится с ней.
Читать полностью »

Каждый разработчик ПО умеет программировать, но не каждый программист может разрабатывать ПО

Не путайте разработку ПО и программирование - 1
Большинство может легко научиться готовить, но когда нужно накормить большое число людей, мы нанимаем повара.

Возможно, кому-то больше нравится говорить не «разработчик», а инженер-программист, ведь инженер — это звучит гордо! Или нет? К счастью, эта статья не о терминах. Если мой термин вам не нравится — подставьте свой: «автор ПО», «мастер ПО»… и даже «творец приложений»!

Говоря «разработчик ПО», я имею в виду человека, для которого написание качественного ПО — профессия. Человека, который использует в своей работе научные подходы и статистику и считает свое занятие чем-то большим, чем просто зарабатывание денег.

Чтобы стать разработчиком, уметь программировать недостаточно.

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

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

Хотите еще аналогий? Пожалуйста:

  • В школе нас обучили математике и письму, но это не сделало нас математиками и писателями.
  • Большинство может легко научиться готовить, но когда нужно накормить большое число людей, мы нанимаем повара.
  • Никто не зовет соседа — мастера на все руки построить дом с нуля.

Главная задача этого текста — донести, что создание простых программ серьезно отличается от разработки ПО.

Переведено в AlconostЧитать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js