Software-Development

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

Давайте будем честны: технологический ландшафт меняется быстрее, чем ваша любимая IDE выпускает новое обновление. Сегодня вы эксперт по REST API, а завтра все говорят о GraphQL, микросервисах и квантовых вычислениях (ладно, может быть, последнее пока нет). Если вы не учитесь постоянно, вы, по сути, наблюдаете, как ваша рыночная стоимость падает, как у трёхлетнего смартфона. Хорошая новость? Вам не нужно становиться обучающей машиной, чтобы оставаться актуальным. Вам нужна стратегия — осознанный, систематический подход к приобретению навыков, которые важны прямо сейчас и будут важны завтра....

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

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

Посмотрите, я собираюсь сказать кое-что, что может привести к тому, что меня не пригласят на следующую конференцию по Agile: истории пользователей не всегда являются решением. Вот, я это сказал. Прежде чем вы закроете эту вкладку и напишете гневный комментарий о том, что я «не понимаю Agile», выслушайте меня. Я годами наблюдал, как команды религиозно превращают каждое требование в священный формат «Как… Я хочу… Чтобы…», даже когда это было абсолютно неуместно....