Ну, поехали!

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

Эта статья будет полезна тем, кто хочет вырваться из цепких лап экосистемы 1С или, наоборот, сэкономить своё драгоценное время.

О себе: 15+ лет в IT, из них 10 лет — 1С, 5 лет — Java.

1. С чего все началось? 2020 период изобилия в ИТ

2020 год. COVID-19, самоизоляция, маски. Работодатели сходят с ума, придумывая, как уберечь офис от пандемии.

Пока компании, работающие с 1С, мучительно решали — разрешать удалёнку или нет, как контролировать сотрудников, — в мире «серьёзной» разработки начинался настоящий пир.

Увидеть это было несложно: стоило лишь открыть HeadHunter, почитать новости или Хабр. С каждым днём крепло ощущение, будто за соседним столиком гремит вечеринка, куда зовут всех подряд.

Зарплата

Зарплаты Java-разработчиков значительно превышали доходы специалистов по 1С. Опытный Senior Java-разработчик спокойно мог зарабатывать от 400 тысяч рублей и больше — такие цифры уже никого не удивляли.

Конечно, найдутся те, кто скажет: «Но и в 1С платили столько же!» Да, единичные случаи были. Однако открытых вакансий с такими условиями — раз-два и обчёлся. Чаще это были «закрытые» предложения для «своих». Да и требования там предъявляли такие, что через полгода работы можно было всерьёз задуматься о состоянии здоровья.

Типичная картина была такая: Java-специалист получает свои 400 тысяч, работая с одним заказчиком, попутно потягивая смузи на пляже с MacBook в руках.

Условия работы

• Удалёнка. Практически все работодатели перешли на удалённый формат. Компании, настаивающие на офисной работе во время пандемии, автоматически попадали в чёрный список у специалистов, ценящих своё здоровье и безопасность.

• Офисы класса А. До удалёнки стандартом для Java-разработчиков стали офисы класса А с полным набором «плюшек»:

  • Современные спортзалы и массажные кресла,

  • Бесплатные кофе и снеки,

  • Эргономичная мебель и лаунж-зоны,

  • Музыкальные комнаты и игровые пространства,

  • Караоке и другие развлекательные зоны.
    (Но работать из дома всё равно было лучше.)

• Техника. За исключением госпроектов, стандартом стала выдача сотрудникам нового MacBook Pro (или аналогичного топового оборудования).

• Соцпакет. Полный ДМС, включая стоматологию, с возможностью подключения семьи. 3+ дня дополнительного отпуска, компенсация спортзала, обучения, питания, бензина и т. д.

Легкость трудоустройства

COVID-19 стал мощным драйвером цифровизации во всех секторах экономики: образовании, корпоративной среде, ритейле и здравоохранении. Это вызвало беспрецедентный спрос на IT-специалистов всех мастей — от разработчиков и тестировщиков до аналитиков и DevOps-инженеров.

Рынок труда отреагировал следующим образом:

• Компании массово нанимали junior-специалистов без опыта,

• На фоне взрывного роста проектов образовался острый кадровый голод,

• Бизнес был готов брать «людей с улицы», обеспечивая им последующее обучение.

Этим незамедлительно воспользовались многочисленные «инфоцыганские» школы, обещавшие за 3–9 месяцев сделать из новичка востребованного специалиста. И что удивительно — их обещания часто сбывались. Даже слабые кандидаты находили работу благодаря тому, что школы помогали им пройти собеседование и сопровождали на испытательном сроке.

Но! Зачем платить за курсы, если большинство крупных компаний предлагали аналогичное обучение бесплатно — да ещё и с гарантированным трудоустройством?

Особенно выделялся OZON, набиравший всех, кто хоть как-то разбирался в IT. К нему присоединились многие банки и крупные корпорации, запустившие собственные образовательные программы.

2. Шаг в неизвестность

Вера в прекрасную жизнь за пределами 1С пересилила здравый смысл.

В качестве нового языка была выбрана Java — язык с богатой экосистемой, корпоративными проектами и относительно простым синтаксисом. Код на Java казался мне куда более читаемым (а читать код приходится часто), чем решения на Python, Go или PHP. О «читаемости» Go-приложений — это вообще отдельная история...

Мне понадобилось примерно полгода, чтобы хоть как-то войти в новую среду и почувствовать себя уверенно на уровне джуна. Это был адский период, когда каждый день на меня обрушивался огромный объем информации. В голове мелькали мысли: "Зачем я сюда влез? Как это все запомнить? У меня ничего не получится, раньше было лучше, надо сдаваться…"  
  
Каждый вечер я опускал руки от усталости, но каждое утро вставал с новыми силами, решив, что надо пробовать и не сдаваться. 
  
Что касается теории, то ее пришлось зубрить о-о-оочень много. Для меня, после 1С, парадигма ООП казалась настоящим кошмаром. Я старался проводить параллели между двумя языками, но все равно было больно:  
- Типы объектов метаданных в 1С — это интерфейсы в Java.  
- Объекты метаданных — это классы.  
- Модуль объекта — это место для описания нестатических переменных и методов.  
- Модуль менеджера — для статических переменных и методов.  
- Модуль формы — это наш фронтенд.  
  
Чтобы быстро разобраться, каждую минуту свободного времени (поездка на работу, прогулка, перед сном) слушал лекции про ООП и паттерны. Записывал себе все непонятные моменты, коротко, тезисно, чтобы потом возвращаться к ним и повторять. 
  
Важным моментом для разработки было окружить себя практикой. Просто берешь любую идею — да хоть самую глупую — и начинаешь реализовывать. Пусть криво, косо, с кучей говнокода, но главное делать, чтобы привыкать к языку.  
  
Следующим этапом было создание пет-проектов. Нужно было придумать как набраться опыта серьезной коммерческой разработки, калькуляторы и туду листы, это конечно все очень интересно, но требовалось что-то более серьезное, написать подобие e-commerce, Instagram и подобного. Тут на помощь пришли китайские братья, которые щедро делятся примерами своих сервисов на GitHub. Главное — научиться фильтровать нужную информацию, ведь они могут использовать свой уникальный стек технологий.  
  

Берешь проект, пишешь свой аналог, и важно начинать с монолита, иначе можно поехать кукухой реализуя все сразу на микросервисах. Переписываешь, сохраняешь на GitHub, и этот проект становится основой и служит примером для следующих проектов.  
  
В этом пути мне помогали репозитории опытных ребят. Вот несколько ссылок, которые были для меня очень полезны:  
- https://github.com/ZHENFENG13/My-Blog - Сервис «Блог» с админкой  
- https://github.com/newbee-ltd/newbee-mall – Сервис e-commerce  
- https://github.com/macrozheng/mall - Микросервисы e-commerce
- https://github.com/mkyong/spring-boot - большое кол-во примеров работы со Spring boot
- https://github.com/mkyong/core-java - Большое кол-во примеров работы с core-java
- https://github.com/berndruecker/flowing-retail - Прекрасный пример построения микросервисного retail с использованием camunda в качестве оркестратора.

Так же советую отличный курс который можно найти бесплатно на просторах интернета - Alexander Gol | Full-Stack разработка веб приложений с Java Spring и Angular (2021)
  
Этап junior — он действительно самый сложный, но, пройдя его, становится намного легче. Дальше идет только оттачивание навыков и изучение нового, но уже не в таких огромных объемах.  

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

Знакомство с новой парадигмой и паттернами

Паттерны, паттерны, паттерны... Можно в совершенстве освоить язык и его инструменты, но без понимания паттернов ваше приложение превратится в груду неструктурированного кода. Это всё равно что быть экспертом по кирпичам, но не знать, как построить дом.

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

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

Знакомство с паттернами проектирования

Парадигма ООП тесно связана с 23 классическими паттернами GoF (Gang of Four). Изначально созданные для объектно-ориентированного программирования, эти паттерны со временем вышли за его рамки и теперь применяются в других парадигмах. Даже в 1С появились курсы, посвященные их использованию.

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

Однако на практике часто встречаются две крайности:

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

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

Можно ли работать без знания этих паттернов? Конечно. Многие так и делают, заучивая пару шаблонов разве что для собеседований. Интересно, что их обычно спрашивают только у junior-разработчиков, а на уровне middle — гораздо реже.

Знакомство с архитектурными паттернами

А вот без понимания этих паттернов нормальная работа в разработке уже невозможна!

Архитектурные паттерны описывают как в вашем приложении должны быть структурированы ваши файлики (классы), по каким папочкам (пакетам) их надо класть. Как классы должны между собой взаимодействовать

Архитектурные паттерны:

• 3-tier architecture / Horizontal design / MVC (Model-View-Controller) / 3-х слойка
• Onion Architecture (Jeffrey Palermo 2008 год)
• Hexagonal Architecture (netflix, 2021)
• Clean architecture (Robert Martin, 2012)
• Domain driven design - это целый отдельный набор из принципов и паттернов

Из личного опыта: чаще всего встречается трёхслойная архитектура (MVC) как самая простая для понимания, хотя она и уступает другим подходам в гибкости и масштабируемости.

В реальных проектах каждый эксперт разработки трактует архитектурный паттерн на свой лад, бывают смешивают сразу несколько различных паттернов делая из проекта франкенштейна - "А давайте возьмём Clean Architecture, добавим пару слоёв из Onion, и... ой, а где тут у нас бизнес-логика?". Оправдывается такой франкенштейн тем, что "Наш проект уникальный, поэтому мы взяли лучшее из всех практик"

Если вам и доведется столкнуться с полетом фантазии эксперта на каком-либо из проектов, то не нужно пугаться. В таких у проекта всегда есть документация, в которой подробно описано как нужно работать с этой архитектурой.

Так же в книге Мартина Фаулера Patterns of Enterprise Application Architecture описано около 40+ паттернов, связанных с разработкой корпоративных приложений, учить их не обязательно, но в своей работы вы обязательно с ними познакомитесь:

• Active Record
• Repository
• Unit of Work
• Service Layer
• и т. д.

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

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

• Junior может думать, что микросервисы — это просто "много маленьких монолитов".

• Middle уже знает, что Saga — это не только скандинавский эпос, а Circuit Breaker — не рок-группа.

• Senior уже отлично знаком с паттернами и понимает: хорошая микросервисная архитектура — это когда после полуночи не звонят из-за упавшего сервиса.

Сложно ли освоить все эти паттерны? Однозначного ответа нет - всё зависит от конкретного человека. Однако если взять, к примеру, 1С-разработчика, сумевшего разобраться в предметной области 1С:ЗУП со всеми её нюансами, то изучение этих паттернов для него окажется не сложнее неспешной вечерней прогулки по парку в тёплую летнюю погоду.

Знакомство с API

Для интеграции сервиса с внешними системами необходимо реализовать API-интерфейс. Современные приложения поддерживают различные протоколы взаимодействия: REST, Kafka, gRPC и другие.

Наибольшей популярностью пользуется REST API. С современными фреймворками типа Spring Boot создание базового REST-интерфейса становится элементарной задачей - достаточно добавить несколько аннотаций.

Так выглядит стандартный пример REST API из учебных материалов и документации:

@RestController
@RequestMapping("/books")
public class BookController {

    @GetMapping
    public Map<String, String> getAllBooks() {
        Map<String, String> books = new HashMap<>();
        books.put("1", "The Great Gatsby");
        books.put("2", "To Kill a Mockingbird");
        books.put("3", "1984");

        return books;
    }
}

При запуске приложения, и проходим по пути http://localhost:8080/books мы получаем наш ответ в виде JSON.

А теперь барабанная дробь, Вот так может выглядеть рабочий пример в приложении на реальном проекте

@RestController
@RequestMapping("/api/users")
@Validated
@CrossOrigin(origins = {"https://example.com", "https://api.example.com"})
@PreAuthorize("hasRole('ADMIN')")
@CacheConfig(cacheNames = "usersCache")
@RequiredArgsConstructor
@Tag(name = "User Management", description = "Operations pertaining to user management")
@SecurityRequirement(name = "bearerAuth")
public class UserController {

    @Autowired
    private final UserService userService;

    @Value("${app.default.page.size:10}")
    private int defaultPageSize;

    @Operation(summary = "Get all users", description = "Returns a paginated list of all users")
    @ApiResponses(value = {
        @ApiResponse(responseCode = "200", description = "Successfully retrieved list",
                     content = @Content(array = @ArraySchema(schema = @Schema(implementation = User.class)))),
        @ApiResponse(responseCode = "401", description = "Unauthorized"),
        @ApiResponse(responseCode = "403", description = "Forbidden")
    })
    @GetMapping
    @ResponseStatus(HttpStatus.OK)
    @Cacheable
    @PreAuthorize("hasAnyRole('ADMIN', 'USER')")
    public List<User> getAllUsers(
            @Parameter(description = "Page number to retrieve", example = "0") 
            @RequestParam(defaultValue = "0") @Min(0) int page,
            @Parameter(description = "Number of items per page", example = "10") 
            @RequestParam(required = false) @Max(100) Integer size) {
        return userService.getAllUsers(page, size != null ? size : defaultPageSize);
    }
}

Это называется метапрограммированием - вместо написания шаблонного кода вручную, мы помечаем его аннотациями. Аннотации это своего рода как самописная директива компиляции, мы просто указываем их, а весь вспомогательный код генерируется автоматически "за кулисами".

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

Знакомство с ORM

В большинстве случаев работа с базой данных в Spring Boot упрощена до минимума. Вместо написания SQL-запросов разработчик может использовать JPA - достаточно описать класс-сущность (entity), представляющий запись в таблице, и создать интерфейс-репозиторий. Фреймворк автоматически сгенерирует все необходимые CRUD-операции (создание, чтение, обновление, удаление) без единого SQL-запроса.

Если в 1С для создания справочника "Номенклатура" достаточно нескольких кликов в конфигураторе, то здесь потребуется ручное описание структуры. Хотя Spring Boot может автоматически создавать таблицы при запуске приложения (используя свойство spring.jpa.hibernate.ddl-auto), в production-среде это недопустимо. Вместо этого используются системы миграций, такие как Liquibase или Flyway, где изменения БД описываются в специальных скриптах.

Рассмотрим пример: мы создаем класс Product (аналог номенклатуры) с полями id, name и description. При правильной аннотации (@Entity, @Table) этот класс будет автоматически отображен на соответствующую таблицу в базе данных.

@Entity
@Table(name = "products")
@Getter
@Setter
public class Product {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "id", nullable = false)
    private Integer id;

    @Size(max = 300)
    @NotNull
    @Column(name = "name", nullable = false, length = 300)
    private String name;

    @Size(max = 500)
    @NotNull
    @Column(name = "description", nullable = false, length = 500)
    private String description;
}

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

@Repository
public interface ProductRepository extends JpaRepository<Product, Integer> {
    // Здесь нет методов, но мы можем их добавить
}

Cервисный слой, который является прослойкой между БД и API и в котором мы описываем бизнес-логику (пример специально упрощен и DTO не используется)

@Service
@Transactional
public class ProductServiceImpl implements ProductService {

    private final ProductRepository productRepository;

    @Transactional(readOnly = true)
    public List<Product> findAll() {
        return productRepository.findAll();
    }

    public Product save(Product product) {
        // Здесь можно добавить валидацию или бизнес-логику перед сохранением
        return productRepository.save(product);
    }

    public Product update(Integer id, Product product) {
        // Проверяем существование продукта
        Product existingProduct = findById(id);
        
        // Обновляем поля (можно использовать ModelMapper или MapStruct)
        existingProduct.setName(product.getName());
        existingProduct.setDescription(product.getDescription());
        
        return productRepository.save(existingProduct);
    }
}

Знакомство с Security

Ролевую модель в Java не любят. На практике во многих проектах авторизация реализуется по принципу "всё или ничего": пользователи либо получают полный доступ к API, либо блокируются полностью. Дополнительные ограничения обычно выносятся на уровень фронтенда или настраиваются DevOps-инженерами через Active Directory.

Даже если вы попадёте на крупный проект, скорее всего, окажется, что у всех пользователей одинаковые права.

А ведь на самом деле реализовать ролевую модель в Java-приложениях довольно просто! Для этого достаточно воспользоваться Spring Security из экосистемы Spring Boot — она предоставляет готовое решение "из коробки".

В самом простом варианте это выглядит так:

1. Получаем пользователя из БД (или из сервиса аутентификации).
2. Определяем, какие роли у него есть.
3. Настраиваем доступ к методам в зависимости от ролей.

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

@Service
public class UserService {

    @PreAuthorize("hasRole('ADMIN')")
    public void createUser() {
        // Logic to create user
    }

    @PreAuthorize("hasRole('USER') or hasRole('ADMIN')")
    public void viewUser() {
        // Logic to view user
    }
}

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

Знакомство с микросервисами

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

Есть одна моя любимая рекомендация от экспертов, которую все благополучно игнорируют:

«Если нет чёткого понимания предметной области и структуры проекта, сначала стоит сделать монолит, а уже потом — разбивать его на микросервисы».

Но кто же её слушает? В корпоративных системах даже простая операция может пройти через десяток сервисов. А если что-то упадёт посередине? Например, товар зарезервировали, а сервис оплаты — недоступен. Вот тут и начинается distributed hell. На помощь приходят паттерны для микросервисов, но они не всегда спасают.

Если мы приняли решение что нам нужны микросервисы, потому что слово монолит вызывает у нас животный ужас, то надо позаботиться о следующем:

• Отказоустойчивости — падение одного сервиса не должно валить всю систему.
• Трассировке и логировании — 1 операция проходит множество сервисов, как нас отследить цепочку вызовов, чтобы понять в какой момент произошла ошибка в рамках конкретной операции.
• Распределённых транзакциях — как гарантировать, что операция, прошедшая через 10 сервисов, либо выполнится целиком, либо откатится?
• Консистентных бэкапах — Бекап БД сервисов должен быть консистентными, т.е. не должно быть ситуаций, что пока вы бэкапите БД «Остатки Товаров», в БД «Резервировании Товаров» уже что-то поменялось.
• Гарантии доставки сообщений — Обязательно отправленный запрос должен доходить до получателя. Недопустима ситуация что отправили запрос, а он… потерялся.

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

• Распределённый монолит (сервисы жёстко связаны, изменение одного ломает три других).
• Распределённый комок грязи (всё зависит ото всего, и никто не знает, как это работает).

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

Для любого программиста может показаться дикостью, когда один сервис создают только для того, чтобы она выполнял только одну функцию, например "резервирование товара"

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

Распределенный монолит включает в себя одновременно все проблемы монолита, и все проблемы микросервисов:

1. Микросервисы становятся сильно связанными между собой
2. Изменение в одном сервисе приводит к отказу в других сервисах
3. Постоянное толкание плечами с другими разработчиками. Я изменил сервис А, Б и В, другой программист сервисы Б, В и Г. При раскатке на стенд нужно следить чтобы изменения между разными сервисам не конфликтовали друг с другом и не мешали работе
4. Как сделать консистентный бекап. Пока мы делали бекап сервиса "ОстаткиТоваров" в сервисе "РезервированиеТоваров" произошли изменения, которых нет в бекапе сервиса "ОстаткиТоваров"
5. Анализ ошибок превращается в настоящий АД, в который можно погружаться на полдня. И это еще не считая времени которое уходит на исправление ошибки в распределенной системе

P.S. По-настоящему любовь к монолиту происходит только после того, как поработаешь с микросервисной архитектурой.

Знакомство с инфраструктурой и технологиями

Научились писать и запускать приложения на java, отлично, теперь начинаем подтягивать инфраструктуру для нашего приложения.

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

Какие технологии нам обязательно встретятся почти на любом проекте:

• Postgresql. Сейчас почти не встретить сервисы работающие с другими СУБД
• Redis. Наш кэш, если мы работаем на высоконагруженном проекте
• Liquibase, flyway. Обязательные инструменты для работы с миграциями
• Kafka. Мы же работаем с микросервисами. Использование kafka это уже почти стандарт для межсервисного взаимодействия.
• Zipkin, Jaeger, OpenTelemetry - Если мы хотим знать по каким сервисам шлялся наш запрос во время выполнения операции, то без них никуда.
• Sentry. Отлавливаем все информацию об ошибках в системе
• ELK. Читаем логи сервисов. Это наш журнал регистрации.
• Prometheus. Получаем информацию по жизнеспособности и нагружености сервисов
• Argocd. Смотрим на работу подов в кубере, и перезапускаем их
• Docker kuberbetes, openshift. Это наша платформа на которой мы в контейнерах запускаем наши приложения
• Testcontainers. Если мы хотим выполнить интеграционное тестирование, нам нужны контейнеры с базой, кешем, кафкой и т.п. Тут приходит на помощь эта технология
• Nexus. Наш сервис для хранения готовых артефактов (версий приложений)
• Maven, Gradle. Наши инструменты для подтягивания зависимостей, сборки, деплоя приложения.
• Jenkins, gitlab. Инструменты CI/CD для прогонки приложения по конвееру и разворачиванию их на стенд
• Git. Контроль версий
• Keycloak. Авторизация, аутентификация
• Vault. хранение паролей и секретов
• Minio. Файлопомойка. Не будем же мы файлы и документы хранить в БД

3. Что стало с разработкой сейчас? Перегрев рынка. Экономический кризис. Пузырь лопнул

Развитие ИИ инструментов

Будущее наступило. ИИ стремительно развивается, появляются ИИ-агенты, а теперь ещё и вайб-кодинг — когда программируешь силой голоса!

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

Пример задачи:
Добавить новую таблицу в БД, написать CRUD-операции и REST API. Просто передаём описание таблицы ИИ — и он делает всё сам, включая тесты и документацию. Красота!

Раньше, если в инфраструктуре случалась проблема (например, Кафка глючила и теряла сообщения), приходилось нырять в документацию на полдня. Теперь же просто спрашиваешь ИИ — и он объясняет, что, почему и как починить. Остаётся только проверить его выводы и применить решение.

Как упростил работу ИИ:

1. Рефакторинг сложного кода. Сделает все в лучших традициях clean code. Важно только проверить за ним, потому что он всегда оставляет ошибки. Но сильно упрощает все остальное
2. Написание документации
3. Автоматизация любых рутиных действий (маппинги, конвертация, CRUD операции и т.п.)
4. Разбор и анализ проблем
5. Подсказки и написание алгоритмов.

Перегрев рынка и кризис

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

Крупнейшие компании США (MAANG (Meta, Amazon, Apple, Netflix и Google)) Начали сокращать своих сотрудников еще в начале 2023:

• Meta : более 20 тысяч человек уволено в 2022–2023 гг.
• Amazon : около 18 тысяч работников.
• Google (Alphabet) : около 12 тысяч.
• Microsoft : около 10 тысяч.
• Salesforce, Intel, Twitter/X, Snap, Lyft и другие тоже проводили масштабные сокращения.

До ИТ в России массовые сокращения пришли значительно позже, и были сильно заметны в конце 2024. Высокая процентная ставка, большое количество стартапов. Крупные компании начали ужиматься, в тяжелой экономической ситуации уже не время экспериментировать. Компании перешли в режим выживания. Сами компании описывали это как оптимизацию.

Количество вакансий на всем направлениям разработки сократилось чуть ли не вдвое. Зацепило всех, программистов, аналитиков, devops, и даже немножко 1С

Что сейчас на рынке труда в РФ:

• Войтишники продолжают увеличивать очередь за забором, хотя всякие инфоцыганские школы уже угомонились и не так активно продвигают свою рекламу "Войти в айти"
• Родители пытаются пропихнуть своих детей в ВУЗы по направлению разработки, потому что в голове установка "ИТ это сейчас перспективно". Часто знакомые интересуются у меня по этой теме.
• Много сокращенных программистов (в том числе сеньоров) вышли на рынок
• Большая часть уехавших на запад программистов, возвращается назад.

Я слышал от коллег 1С-ников, что у них никакого дефицита кадров нет, на многие вакансии аж по целых 100 откликов, от кандидатов полно

Чтобы было понимание, в java в 2022 году можно было увидеть 1000 откликов на позицию Junior специалиста, а в 2025 можно увидеть 1000 откликов, но уже на позицию Senior.

Но если посмотреть резюме тех, кто откликается, то 80% из этих резюме просто не пройдут базовые фильтры

• Многие не имеют отношения к ИТ, но при этом прикручивают себе опыт
• Откликаются не глядя. Пустышки, которые спамят все вакансии.
• Не заполнен опыт работы
• Вчерашние выпускники курсов, которые с накрученным опытом пытаются попасть хотя бы на собес.
• Не подтвержденные навыки
• Люди со странностями которые неадекватно оценивают оплату труда Java разработчика и готовы работать за 40к-100к.

Если у вас будет хорошо заполненное резюме, с подтвержденными навыками (ИТ аттестация госуслуги+hh.ru), то у вас появляется крайне высокий шанс что ваш отклик будет рассмотрен.

5. И какого это работать с Java?

На момент написании статьи 2025 год. Я попал на волну IT и от души прокатился на ней. Последние пять лет были наполнены приключениями, радостью, погружением во что-то новое… и в итоге — разочарованием. С последующим желанием вернуться обратно в 1С.

В чем заключалось разочарование:

1. Эйджизм

Тут я впервые познакомился с термином Эйджизм. Программисты старше 45 лет куда-то пропадают. Везде, где я работал, самому старому программисту что я видел было ~40 лет. Часто видел статьи, где обсуждалось что после 45 лет HR начинают игнорировать кандидатов, в результате чего кандидатам приходится прибегать к хитростям, прятать возраст, скручивать опыт менять дату окончания вуза. Команда состоит преимущественно из молодых специалистов. Могут возникать сложности коммуникации из-за разницы в возрасте и HR это понимают, поэтому в молодой коллектив при прочих равных, стараются набирают специалистов одного возраста.

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

2. Бюрократия

Java — это крупные компании. Крупные компании — это огромное количество бюрократии. Если раньше результат моей работы измерялся «улыбкой заказчика», то теперь — «вовремя согласованной заявкой». Всё тонет во встречах, согласованиях и спорах со всеми инстанциями. Нужно чтобы ТЗ прошло все стадии обсуждений и согласований, споров и правок, затем прокатывать свою доработку по 5 различным стендам, согласовывать выкатку на каждый стенд, проходить ревью от СБ, нужно иметь доступ ко всей инфраструктуре каждого стенда для проверки работы своего приложения.

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

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

3. Технологическая перегрузка

Технологическое безумие. В it огромное количество разных сервисов, приложений и инструментов, облегчающих жизнь. Они приходят, уходят, меняются и знания о них нужно постоянно актуализировать, чтобы оставаться на плаву.

Утомляет:

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

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

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

4. Постоянная нестабильность

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

За последние 5 лет IT пережило:

• Надувание пузыря и нехватку кадров.
• Сдувание пузыря и массовые сокращения.
• Постоянную смену технологий.
• Нашествие ИИ и моду на «вайб-кодинг».

5. Дефицит дофамина

По больше части все перечисленные ниже пункты являются разницей между крупными и небольшими компаниями.

Чтобы мозг получал больше удовольствия от работы, в ней должны присутствовать следующие ключевые вещи способствующие выбросу дофамина:

• Быстрое достижение результата. В 1С очень часто присутствуют задачи, которые буквально можно решить за 2-4 часа. За это время можно получить задачу, реализовать решение, протестировать и вылить в прод. И вычеркнуть эту задачу из своего мозга. Можно ли сделать подобное в java? В крупной компании нет, но там можно самостоятельно декомпозировать свою задачу на отдельные шаги и пытаться радоваться решению каждого шага, но все равно это немного не то.

• Получение фидбека. В компаниях, где работа происходит без аналитика, происходит больше коммуникаций программиста с заказчиком напрямую. Как следствие, ты сам предоставляешь свое решение заказчику напрямую и получаешь фидбек (как правило положительный, если заказчик и вы хорошие люди) Похвала повышает не только ощущение значимости того, что ты делаешь, но и помогает дополнительному выбросу дофамина В java ты отдаешь свою задачу аналитику, и если по ней проблем нет, больше ты о ней нечего не услышишь.

• Коммуникации с коллегами. Люди, работающие в 1С более общительные, и не только на рабочие темы. В других языках программирования ситуация обратная, люди больше сидят погруженные в код, негласное правило "Чем меньше коммуникаций, тем лучше. Потому что ничто не отвлекает от написания кода". Если и поболтать, то только на рабочие темы. Конечно, везде ситуация бывает разная, но чаще всего мне встречалась именно такая картина.

Где же я нахожу тогда дофамин?

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

Приехали!

Стоит ли изучать другой стек технологий? Однозначно стоит для саморазвития и самореализации. Писать свои игры, сервисы, инструменты которые могут помочь в работе вам и коллегам.

Другой же вопрос, стоит ли менять для этого работу? Только если вас не беспокоят те проблемы, которые я описал выше. Если уж прям очень хочется поработать, я бы рекомендовал попробовать фриланс или найти знакомых которым требуется какая-то помощь в автоматизации, интеграции и проверить там свои силы.

Наша страна каждые 2-5 лет переживает кризисы. Рынок каждые 5 лет переживает пузыри, которые лопаются. Мы уже пережили моду на бухгалтеров, экономистов, юристов. В 2020 - мода на айти, 2025 - мода на сварщиков и ЧПУшников.

1С находится в своем отдельном мире, в которой все тренды в ИТ если и доходят, то обычно с отсрочкой в 4-5 лет

1. Весь мир ИТ в 2020 году ушел на удаленку... В 1С к этому пришли только к началу 2022, и даже до сих пор многие продолжают сопротивляться, а другие решили, что время удаленки уже прошло.
2. ИИ. Copilot выкатились в 2021 году... В 1С только в 2025 году смогли поймать волну и создать 1С напарника. Хотя многие энтузиасты задолго до этого использовали западный Cursor IDE для разработки на 1С с ИИ
3. Доисторический 1С конфигуратор, до сих пор является незаменимым инструментов для разработки.
4. Agile в 1С. Я наконец-то начал слышать слова - спринт, дейлик, ретро, беклог и прочие слова в окружении 1С разработчиков.

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

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

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