Posts

Существует определённый тип разработчиков, которых я вижу на конференциях: они с абсолютной уверенностью говорят об единственно правильном способе структурирования кода. Они цитируют «Банду четырёх», как священное писание, строят свою архитектуру с точностью швейцарского часовщика и смотрят на ваше прагматичное операторское выражение if-else так, будто вы попросили их отладить COBOL в 1980-х годах. Они не совсем неправы. Просто они забыли одну важную вещь: шаблоны проектирования — это инструменты, а не заповеди....

Представьте: 1969 год, и Кен Томпсон сидит перед практически неиспользуемым компьютером PDP-7 в Bell Labs. Большинство людей увидели бы просто неработающую машину, собирающую пыль. Томпсон увидел возможность. Он только что наблюдал, как огромный, раздутый проект операционной системы под названием Multics рухнул под тяжестью собственной сложности, и подумал: «Должен быть лучший способ». Спойлер: он был. И это коренным образом изменило наше представление об операционных системах. История UNIX — это не только о технологиях, это о группе блестящих людей, которые были настолько разочарованы, что создали нечто элегантное вместо чего-то огромного....

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

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

Давайте поговорим о том, что обычно относят к категории «было бы неплохо» в большинстве компаний, занимающихся разработкой: об accessibility (доступности). И я говорю не о том неловком моменте, когда кто-то упоминает соответствие требованиям WCAG, и все вдруг находят свои туфли очень интересными. Я говорю о чём-то более фундаментальном: должны ли наши языки программирования сами контролировать стандарты доступности? Вот мой смелый взгляд на ситуацию: мы подходили к этой проблеме неправильно. Мы создали множество руководств, систем соответствия и нормативных требований, но по-прежнему относимся к доступности как к функции, которую можно добавить в конце, прямо перед запуском, когда кто-то вспоминает: «Ах да, существуют скринридеры»....