Франческо Черилло – автор метода помидора из тайм-менеджмента – оказывается опытный программист. В 2007 году он запустил кампанию "Anti-If". Идея компании состоит в распространении знаний наилучших инженерных практик в сфере разработки, повышая осознанность об одной из самых негативных практик – чрезмерном использовании if.

Конечно, в самом if ничего страшного нет, но только тогда, когда он используется очень умеренно. Большое же количество этих инструкций приводит к запутанному коду и его связности, разбираться в нем очень тяжело.

В общем, это интересная кампания, которая заслуживает того, чтобы вы про неё по крайней мере узнали.

https://francescocirillo.com/pages/anti-if-campaign

#programming #softwaredesign

Вчера я рассказал про "Anti-If", но на сайте кампании нет практических примеров про то, каким образом можно избавиться от большого количества ветвлений в коде. Статья "Anti-If: The missing patterns" восполняет этот пробел.

Для того, чтобы уменьшить количество ветвлений разбивайте методы на более мелкие, если их логика зависит от логического параметра. Вместо использования switch, можно использовать полиморфизм. Не делайте явные проверки на null, используйте Optional типы либо альтернативы. Заменяйте if выражениями. Локализуйте проверки на граничные значения в одном месте, не позволяйте им расползаться по коду.

Да, статья использует Java, но, если вы сталкивались с типизацией в JS, разобраться в примерах не составит труда.

#programming #java #softwaredesign

https://code.joejag.com/2016/anti-if-the-missing-patterns.html

В статье, про которую я писал вчера, Аксель говорит о том, что он не фанат опционального чейнинга (`obj?.prop` - пропозал в будущий стандарт JS) и даёт ссылку на статью "Overly defensive programming" Карла Витулло, которая раскрывает идею того, почему чрезмерные проверки по всему коду это не очень хорошая практика.

Если мы пишем в коде слишком много защитных проверок (например, `const p = obj && obj.p;`) и подавляем возможные ошибки, то это может служить признаком того, что мы не знаем, какие гарантии предоставляют используемые сервисы и сторонние библиотеки. В итоге это может приводить к непонятным ошибкам. Лучше всего заблоговременно разобраться в данных и кинуть ошибку как можно ближе к тому месту, где она произошла, не забыв залогировать. В статье есть хороший пример. Какое сообщение вам будет понятнее: Warning: Failed prop type: The prop 'a' is marked as required in 'Thing', but its value is 'undefined'. или Uncaught TypeError: Cannot read property 'b' of undefined? Кажется, что ответ очевиден. Как альтернативу проверкам можно использовать статическую типизацию, которая просто не даст коду собраться, если какие-то контракты были нарушены.

Чрезмерные проверки - это как прикрывание дыр в стене с помощью картин. На первый взгляд может казаться, что всё в порядке, но на самом деле дыры остаются на своём месте точно также как и баги в программе.

#programming #softwaredesign #musings

https://medium.com/@vcarl/overly-defensive-programming-e7a1b3d234c2

Нашёл в твиттере ссылку на интересную статью Франсуа Шолле — "Notes to Myself on Software Engineering".

Статья представляет собой список "напоминалок" про процесс разработки софта, проектирование API и про карьеру. Хочу выделить из неё пять пунктов:

— Хороший софт делает трудные вещи простыми. Если на первый взгляд проблема кажется сложной, это не означает, что решение тоже должно быть сложным.
— При проектировании сценариев взаимодействия с API следует задать самому себе несколько вопросов. Какие это сценарии? Какая оптимальная последовательность действий для их достижения? Какой наиболее простой программный интерфейс может это реализовать?
— API создаётся для пользователей. Проявляйте эмпатию вне зависимости от того, пользуются ли им профессионалы или новички.
— Продуктивность сводится к высокой скорости принятия решений и к действию.
— Прогресс в карьерном росте выражается не количеством людей, которым вы управляете, а в том, какую ценность вы даёте миру.

В статье очень много хороших мыслей, рекомендую почитать.

#list #softwaredesign #career

https://medium.com/s/story/notes-to-myself-on-software-engineering-c890f16f4e4d

Где-то месяц назад в канале был пост про статью "Text Rendering Hates You" Алексис Бинжесснер. Недавно Роберт Лорд как дополнение к статье Алексис поделился своим опытом работы над вводом текста — "Text Editing Hates You Too".

Роберт на протяжении своей карьеры много работал над вводом текста, разрабатывал протокол для ввода текста в Google Fuchsia (новая операционная система Google). Он столкнулся с большим количеством проблем, которые остаются незамеченными для большинства пользователей. Например, позиция курсора не может быть точно определена при переносе текста на новую строку и перемещении курсора ввода текста в место разрыва. Для решения этой проблемы у курсора есть специальный бит "affinity" (близость), который говорит о том, к какой строке он принадлежит. С модификаторами emoji тоже есть проблемы. В статье описывается баг приложения TextEdit в macOS. Если добавить новую строку и первым символом в строке ввести модификатор цвета кожи, то курсор больше не сможет попасть в начало строки, так как модификатор будет применяться к символу переноса строки.

Если интересно заглянуть под капот ввода текста, рекомендую почитать статью.

#internals #softwaredesign

https://lord.io/blog/2019/text-editing-hates-you-too/