Новости России

Когда мы лишь полагаем стать программистом, программирование для нас распределяется на специализации: игры, веб-сайты, приложения для бизнеса, программирование ЧПУ (о нем кто-то полагал, любопытно?).

Представляется, сейчас прочтешь пару книг, попрактикуешься и утрешь нос игроделам, Цукербергу и создателям электронного расписания.

А затем оказывается, что разработчик программного обеспечения — это только часть команды, при этом не то чтобы часть вместе с дизайнерами или тестировщиками, а часть команды разработчиков программного обеспечения, каждый из которых отвечает за тесные и иногда неинтересные задачи. Солидный коммерческий проект распиливается одним человеком в каких-либо эксклюзивных, необыкновенных случаях — и речь в них проходит об весьма опытных создателях с бездонным бэкграундом.

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

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

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

В какой-нибудь момент на заре карьеры поклонник собственного дела прочитывает (и что важно, осознает) «Совершенный код» Стива Макконнелла и постановляет, что всю жизнь будет писать код елочкой, аннотировать, улучшить, проводить постоянный рефакторинг и делать код ясным, действенным и мощным.

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

До первого пылающего багфикса, пятничного релиза и «срочно-важного» заказчика, у которого определенные вещи нужно дописывать разве что не на проде. И тогда выясняется, что изменение в одной строке требует переписывания 10-ти иных, где-то есть щепотка легаси, а продовольственный консультант никак не готов ожидать новых итераций рефакторинга. Фигак-фигак и в продакшен.

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

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

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

«Код — это все, что нужно», — 3-е ложное предложение, сопряженное с кодом. К слову, весьма похожее на ошибку грядущих медицинских работников: они также полагают, что будут исцелять, пока не столкнутся с документами, докладами, нормативами и иной бюрократией.

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

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

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

Для разработки самого лучшего (и в особенности хорошо монетизируемого) проекта необходима хорошая, мощная бригада экспертов, которые в точности понимают, как сделать свою работу хорошо. С течением времени становится ясной вторая идея: собственный самый лучший не равно самый лучший для клиентов.

Почти каждый спринт вы будете наталкиваться на нежданные требования, которые возможно удовлетворяют запросам клиентов, а при этом противоречат вашему вкусу, осознанию UX и представлениям о отличном. Самый лучший проект есть тот, который нравится пользователям, постановляет их задачи и без проблем удерживается. Советуем заглянуть на сайт https://utro.ru/release/2025/01/21/1557313.shtml если нужны форумы программистов.

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