Иногда встречаю понятие энтерпрайз программирование или энтерпрайз код. Какое этому понятию можно дать определение ? И почему часто это употребляется как что-то негативное? P.S. Понимаю что вопрос не зависит от языка, но ответ интересует относительно .Net платформы.
Отслеживать
задан 24 ноя 2016 в 13:50
4,465 3 3 золотых знака 24 24 серебряных знака 40 40 бронзовых знаков
24 ноя 2016 в 13:51
Это решения для большого бизнеса, для тех у кого много денег. Когда денег не хватает, то становится обидно, что попользоваться не удастся. Эта обида иногда перерастает в негативное отношение (зачастую вполне справедливо, поскольку обещанные фичи часто все же не стоят таких денег) к таким решениям.
24 ноя 2016 в 14:23
24 ноя 2016 в 14:26
Далеко не всем программистам суждено участвовать в таких разработках (не в качестве «негров»).
24 ноя 2016 в 14:29
Добавлю свой вопрос с теме. Попытался найти объяснение, что значит «Ъ-программисты», но не смог ничего подходящего найти, дайте пожалуйста определение.
КАК СОЗДАЮТСЯ ENTERPRISE ПРИЛОЖЕНИЯ
9 авг 2019 в 18:27
3 ответа 3
Сортировка: Сброс на вариант по умолчанию
Всякие сервисы, базы данных и их интеграции между собой. Чаще всего это инфраструктура организаций, всякие CRMы, 1Сы и прочее. Нелюбимо творческими программистами за то, что это b2b, которым нельзя похвастаться перед друзьями, а Ъ-программисты ругают «галерных» программистов, что работа эта не творческая, рутинная, а исполнители — бестолковые и неквалифицированные, которые не могут в бородатые стартапы. Ну и так как этими системами клиентов не завлекают, то там гнездятся тонны легаси-кода.
Можно сказать, что зависит от языка. В подавляющем большинстве случаев это Java и .NET.
Отслеживать
ответ дан 24 ноя 2016 в 14:27
8,646 16 16 серебряных знаков 31 31 бронзовый знак
Немного ситация прояснилась. Но кто такие Ъ-программисты? гугл тоже не знает, кажется 🙂 А «галерные программисты» ? P.S. я не местный но русскоговящий, поэтому мне много не ясно 🙂
24 ноя 2016 в 14:36
24 ноя 2016 в 14:41
Постройка дома/дачи-это обычные проекты, хоть и бывают сложные
Строительство МКД на 1000+ квартир по ГОСТу в 70-100+ лет эксплуатации это Энтерпрайз.
По моим наблюдениям, Энтерпрайз решение должно обладать следующими характеристиками:
1) широкий масштаб разработки (международная компания или хотя бы специалисты из разных городов и областей, разные направления специалистов, часто решение находится на стыке научных изысканий)
2) большое количество пользователей (от 1 млн пользователей примерно)
3) решение, которое охватывает целую отрасль и более (т е находится в топе среди подобных решений в рамках мира или хотя бы большой страны/группы стран)
4) решение стабильное, отказоустойчивое, предсказуемое и требующее минимум изменений с течением долгого времени эксплуатации (т е даже спустя десятилетия, данное решение будет оптимальным решением вне зависимости от смены технологий, подходов и прочих как внешних, так и внутренних условий)
Какие бывают реальные задачи в Java Enterprise?
Почему негативное? Это субъективно-код получается неубиваемый, живучий и местами сложно понимаемый. Здесь нужно терпение и быстро результат нельзя получить, равно как и все новомодное встраивается очень медленно в виду сложности решения.
Источник: ru.stackoverflow.com
Enterprise или SaaS: что выбрать бизнесу
Принято считать, что облачное ПО проще и дешевле, поэтому его выбирают небольшие компании. А Enterprise доступен только крупным игрокам. Так ли это на самом деле — разбираемся в этой статье.
Сперва определимся с терминами:
- Software as a Servise: облачная модель размещения ПО. Компания оформляет подписку и подключается через интернет к серверам поставщиков софта. То есть работа осуществляется в облаке и обслуживается провайдером.
В статье будем использовать термины: SaaS и облако.
- Enterprise: корпоративное решение, которое разворачивается на собственных серверах компании, покупающей софт у производителя. Работа осуществляется без участия поставщика ПО. Проще говоря, это облако, помещенное в инфраструктуру компании-клиента.
В статье будем использовать термины: Enterprise, In-House, On-premise.
- CRM-системы: amoCRM, Битрикс24, Salesforse
- Облачные хранилища: ownCloud, Dropbox
- Колл-центры и чат-центры: Chat2Desk, MANGO OFFICE, Intercom
Для того, чтобы понять, какое решение более выгодно для вашего бизнеса, необходимо сравнить SaaS и In-House. Можно провести аналогию с арендой квартиры и покупкой собственного жилья:
Оба варианта предполагают проживание в квартире. Разница в том, что в первом случае это ваша личная квартира, где вы можете самостоятельно сделать ремонт, поставить мебель и вообще делать все, что душе угодно. Во втором случае вы живете на съемной квартире, где действуют свои правила и ограничения согласно договору.
То же работает в отношении облака и On-Premise: вы пользуетесь «арендованным» софтом, находящемся в ответственности провайдера, или приобретаете сервис, где «хозяин» вы сами.
Как это работает с чат-центром
SaaS: сообщения клиентов сперва попадают на серверы WhatsApp, Telegram, Viber и прочих мессенджеров. После этого они попадают на серверы чат-центра. Далее вы подключаетесь через интернет к серверам чат-центра и видите сообщения ваших клиентов. При этом на пути следования данных есть посредники — интернет провайдеры и DNS-сервера.
Enterprise: сообщения клиентов поступают на серверы мессенджеров, откуда попадают напрямую к вам. В этой цепочке отсутствуют посредники, провайдеры и поставщики.
Нужен ли вам In-House?
Существует мнение, что In-House выбирают только крупные государственные и финансовые организации. На самом деле, такой тип подключения пользуется не меньшей популярностью среди сотовых операторов, транспортных и логистических организаций, страховых компаний. Это частные компании с большим числом клиентов и высокой нагрузкой на операторов.
Каждая компания, которая работает с персональными данными клиентов, несет ответственность за личную информацию и попадает под действие закона №152-ФЗ «О персональных данных». Enterprise-решение в таком случае помогает более четко следовать закону, чем SaaS.
Особое значение в пользу корпоративного решения имеют скорость и стабильность. Чем больше сообщений принимает чат-центр, тем больше нагрузка на серверы компании. Отсюда низкая скорость переписки. Для того, чтобы операторы могли общаться с клиентами без задержек, необходимо поддерживать высокую производительность системы. Такую возможность предлагает On-Premise.
Преимущества Enterprise
1. Безопасность информации
Для любой компании важно, чтобы личные данные клиентов и конфиденциальная информация не ушли на сторону. Поэтому большое значение придается цифровой безопасности.
1.1 Персональные данные
Клиент, общаясь с компанией, зачастую передает свою личную информацию: реквизиты банковских карт, паспортные данные, номер телефона — конфиденциальную информацию, которая не должна попасть в руки третьих лиц. In-House решение позволит хранить всю информацию на своих серверах, что исключает утечку личных данных.
1.2 Данные компании
Бухгалтерия, базы данных, документация и сведения о компании тоже являются конфиденциальными данными, требующие повышенной защиты от лишних глаз. On-premise подразумевает, что все это хранится на серверах компании, доступ к которым есть только у сотрудников организации.
Закон 152-ФЗ «О персональных данных» гласит:
«Операторы и иные лица, получившие доступ к персональным данным, обязаны не раскрывать третьим лицам и не распространять персональные данные без согласия субъекта персональных данных, если иное не предусмотрено федеральным законом»
Несоблюдение закона влечет за собой гражданскую, административную и уголовную ответственность. Это значит, что компания, допустившая утечку конфиденциальной информации, оплатит штраф или лишится лицензии на свою деятельность.
Chat2Desk оснащен системой безопасности, которая предоставляет доступ только тем, кто авторизовался в системе. Вся информация зашифрована, а значит, даже если произойдет взлом или утечка, то расшифровать данные смогут только какие-нибудь спецслужбы. В отличие от SaaS, In-House исключает посредника между клиентом и компанией, поэтому безопасность такого решения выше. Поэтому компании со статусом оператора персональных данных будет проще следовать закону. Но тогда владелец Enterprise берет ответственность на себя и самостоятельно внедряет систему мониторинга защиты данных.
2. Стабильность и скорость
Доступ к облаку обеспечивается интернет-провайдерами. Компании обеспечивают постоянную работу сервиса за счет мощностей своих серверов и поставщиков интернета. Но это не исключает возможных сбоев в работе, на которые вы не сможете повлиять.
При подключении In-House вы самостоятельно находите провайдеров и ответственность за работу интернета переходит под ваш личный контроль. Теперь любые возникшие трудности решаете вы сами.
Но если вы используете In-House-решение Chat2Desk для внутренней работы отделов, то никакие сбои и задержки вам не страшны. Внутри одной локальной сети документы и сообщения передаются без проблем.
Например: ваш офис расположен на Кипре, а облако Chat2Desk развернуто на российских и европейских серверах. В таком случае вы можете столкнуться с низкой скоростью доставки сообщений и сбоями в работе сервиса. Размещение On-Premise решает эту проблему: работа сервиса не будет зависеть от сторонних посредников и вы сможете свободно общаться внутри компании.
3. Кастомизация софта
Если речь идет о доработках внутри сервиса, то облако имеет ограничения. Каждый провайдер софта имеет roadmap, где запланированы обновления и доработки. Если ваша идея попадает в область roadmap, то вы поймали удачу за хвост – предложение рано или поздно реализуется. Но если ваше предложение идет вразрез с планами сервиса, то придется доплачивать, чтобы софт сделали под потребности вашего бизнеса.
In-House-решение дает возможность самостоятельно кастомизировать и адаптировать софт под ваши нужды. Открытый API позволяет разработчикам вашей компании вносить изменения, проводить дополнительные интеграции со сторонними облачными сервисами, искусственным интеллектом, системами безопасности и собственными чат-ботами, независимо от создателей софта.
Кроме функциональной части вы можете изменить внешний вид интерфейса, например, разместить в углу экрана логотип компании. Настройте виджет на сайте компании: разработайте свой дизайн, а вместо Chat2Desk укажите название компании.
4. Производительность
При работе с SaaS подключаются две стороны — компания и клиенты. Работа и общение проходят внутри облака, ресурсы и возможности которого достаточно широки, однако имеют свои ограничения. Например, в случае высокой нагрузки возможны сбои и задержки в работе софта. Скорость будет на низком уровне до тех пор, пока владельцы сервиса не повысят мощности.
В случае с In-House ситуация меняется: вы сможете самостоятельно регулировать мощность сервера и увеличивать ее в особых случаях. Представьте себе ситуацию: вы запускаете рекламу с выгодным предложением. Вы сможете спрогнозировать наплыв клиентов и вероятную нагрузку на сервера и вовремя принять необходимые меры.
Требования для Enterprise
Технические требования рассчитываются индивидуально и зависят от ваших целей и ожиданий. Главные критерии — объем сообщений, число операторов и количество подключенных мессенджеров.
Чтобы развернуть On-Premise на своем сервере, необходимо соблюдение следующих условий:
1. Оборудование:
- может быть уже в наличии;
- закупается самостоятельно компанией;
- закупается и устанавливается при помощи Chat2Desk.
2. Отдел разработки: чтобы развернуть In-House на серверах, необходимы специалисты с обеих сторон. Однако, если у вас нет своих разработчиков — это не проблема. Chat2Desk готов полностью настроить Enterprise самостоятельно.
3. ПО: не имеет значения, так как универсальные решения Chat2Desk совместимы с любым программным обеспечением.
4. Виртуальные серверы: для расширения вашей инфраструктуры и снижения нагрузки.
Enterprise проекты: что нужно знать разработчику?
Поговорим о том, что такое enterprise разработка, какие у enterprise проектов могут быть нюансы, и какие навыки нужно обрести для успешной работы в разрезе .NET стека.
Приветствую! Меня зовут Андрей Степанов, я CTO во fuse8. Мне интересно знакомиться с опытом коллег по цеху и делиться своим. В сфере я уже больше 20 лет. В этой статье – наблюдения и рекомендации для интересующихся и тех, кто еще не трогал enterprise, но очень хотел бы.
Предположим, вы изучили язык, фреймворк, инструменты, получили опыт разработки и теперь стоите на распутье:
Путь 1 enterprise разработка: микросервисная архитектура, СУБД, очереди, gRPC и проч.
Путь 2 геймдев: Unity.
Путь 3 CMS (content management system) и DXP (digital experience platform): Kentico, Sitecore, Optimizely.
Предлагаем подробно разобраться в нюансах и узнать, к чему нужно готовиться, если хочется в enterprise.
Что такое enterprise
Приходит бизнес-заказчик и говорит: «Сделайте мне продукт!». Заказчику нужно изобрести «собственный велосипед» для выполнения конкретной бизнес-задачи. Такой «велосипед» – это цельная система, и у нее есть особенности при разработке:
- Написание кода, который будет поддерживаться многие годы (ООП, SOLID, GOF-паттерны, Unit-тесты и т.д.);
- Сложная бизнес-логика, которая часто меняется;
- Использование проверенных фреймворков/библиотек;
- Написание тестов;
- Код, доступный для рефакторинга, и создания документации по продукту на его основе;
- Регулярность code review.
Максимально качественный код нужно писать сразу, используя разные подходы и паттерны, чтобы в дальнейшем можно было расширять проект. Поскольку проект будет решать определенные бизнес-задачи, нужно готовиться к пониманию и реализации сложной бизнес-логики. Она, кстати, по ходу развития проекта обязательно будет меняться и дополняться, поэтому зазубрить на один раз не выйдет. А еще нужно будет погрузиться в доменную область, в которой будет вестись разработка.
Enterprise проект — это всегда вопрос про деньги. Мы не можем использовать непроверенные решения.
Годятся только проверенные годами фреймворки, библиотеки, и инфраструктурные сервисы. Нельзя рисковать бюджетами и бросаться на первый попавшийся, только что вышедший новый сервис, даже если он кажется лучшим решением на планете.
Доработка и развитие проекта неразрывны с постоянным тестированием. Оно дает возможность дорабатывать или рефакторить код на протяжении долгих лет, а еще – смело трогать в дальнейшем старые участки кода, не боясь что-то сломать. Это важно, потому что подход «работает – не трогай» тут не подойдет. Ну и без код-ревью в этой связке никуда. Этот процесс помогает отлавливать несовершенства и баги еще до приемки тестировщиками, а еще – шарить знания о разработанной фиче с командой, которая потом сможет исправлять и дорабатывать фичу вместо тебя.
Из чего состоит типичное энтерпрайз приложение
Вот у нас есть центральное приложение, и нам, конечно же, для него нужна база данных. Если пишем проект с нуля, то сразу выясняем, какая база данных подойдет лучше, исходя из задач проекта.
Логирование. Недостаточно просто настроить его, нужно подобрать сервис, который будет сохранять логи. Без логирования зачастую невозможно разобраться в проблемах на проде, невозможно восстановить какие-то артефакты.
Метрики и хелсчеки. Мы не можем, запустив проект, отправить уже созданную его часть в свободное плавание, пока сидим и разрабатываем следующую. Сервис может и упасть, а мы этого не узнаем. Падения – это всегда финансовые потери для бизнеса, а их быть не должно. Чтобы их избежать, нужно превентивно, на основании бизнес-метрик, понять, что идет не так, и исправить ситуацию.
Стоит запомнить, что о багах и проблемах на проде разработчики должны узнавать быстрее заказчика.
Помимо логирования стоит предусмотреть error tracking или трекинг исключений и сервис, который будет хранить ошибки отдельно. Трекинг-сервис помогает группировать, анализировать и фильтровать ошибки, отслеживать их частоту, предоставляет более детальную информацию, чем логи, и быстро отправляет нотификации об ошибках. Можно интегрировать трекинг ошибок с чатами. А еще можно создать кастомные интеграции, чтобы, например, сервис отправлял сообщения об обнаруженных ошибках на телефоны разработчиков.
Внутри enterprise приложения должно быть настроено эффективное общение между сервисами: задачи должны выполняться своевременно, нагрузка – распределяться равномерно. В этом помогут очередь, шина, или планировщик задач.
Приложение нужно будет подстроить под деплой. Поэтому разработчику нужно знать, как будет развертываться инфраструктура. Например, нужно определиться с контейнеризацией и оркестрацией – выбрать сервисы и правильно их настроить.
На проекте могут быть DevOps-специалисты, но это не значит, что ответственность за процесс деплоя будет лежать только на них.
Если у нас монолит, мы можем кэшировать данные в памяти. Если микросервисы и для каждого отдельного сервиса могут подниматься несколько инстансов – кэшировать в памяти каждого не выйдет. Не понятно как это потом синхронно обновлять. В таких случаях на помощь приходит распределенный кэш: отдельно поднимается сервис, который хранит определенные данные и предоставляет быстрый доступ к ним. Как правило, это key-value хранилище.
Отдельные файловые хранилища. Зачем? За тем, что хранить файлы просто на диске – не удобно. Хранить файлы в базе данных – проблемно. Поэтому зачастую в enterprise проектах используются отдельные файловые хранилища.
Это еще один инфраструктурный сервис.
Для задач, связанных с отображением данных, нужно подключить визуалайзер. Так удобнее следить за метриками, смотреть логи, отслеживать хелс-чеки. Мы, например, используем Grafana, чтобы выводить данные и присылать нотификации. Grafana позволяет все собранные данные отобразить так, чтобы было удобно их совокупно анализировать.
Отдельный блок – code style и анализаторы. Когда команда уже большая или среднего размера, каждый может писать код по-своему. Это порой вызывает споры на код-ревью. Поэтому зачастую на enterprise проектах используются анализаторы, которые помогают автоматически находить проблемы, потенциальные ошибки и проверять единый code style.
Какие навыки нужны для успешного решения задач энтерпрайз-проекта
Базы данных:
- Таблицы, типы данных, связи, ограничения;
- написание запросов, соединений;
- индексы;
- транзакции;
- хранимые процедуры;
- представления.
Более продвинутый уровень:
- План запроса;
- статистика;
- нормальные формы;
- deadlock;
- триггеры;
- внутреннее устройство фильтрации и соединения.
Понятное дело, что нам нужно уметь самим создавать таблички, продумывать их архитектуру, понимать все типы связи, ограничений и так далее. Это must-have.
Еще нужно ориентироваться в разных видах индексов: покрывающих, фильтрующих, кластерных, не кластерных, составных. Так, уже на этапе разработки будет проще закладывать индексы, чтобы увеличить перформанс определенных запросов. Другой пример: когда мы видим, что запросы выполняются медленно, можем предложить, используя знания об индексах, один из вариантов решения.
Транзакции. Многие запросы нужно делать в рамках транзакций, чтобы не получились неконсистентные данные в БД.
Что нужно, чтобы продумать архитектуру enterprise приложения
- DDD;
- SOLID;
- GOF-паттерны;
- REST;
- чистая архитектура (гексагональная архитектура);
- CI/CD;
- паттерны, используемые в микросервисной архитектуре.
Желательно разбираться в DDD-подходе, чтобы сразу правильно спроектировать приложение и сделать архитектуру, которую в дальнейшем можно будет расширять.
Принципы SOLID с точки зрения архитектуры сильно помогают при разработке.
GOF-паттерны нужны, чтобы писать более расширяемое приложение, более универсальное. Его легко можно будет дорабатывать, что нам очень важно.
REST. Придется делать много интеграций со сторонними сервисами, общение между которыми зачастую реализуется через REST. Еще может понадобиться реализация REST API для приложения, чтобы с ним могли общаться другие сервисы, например spa.
Для дальнейшего расширения и развития приложения также разумно применять знания о чистой или гексагональной архитектуре.
Области знаний C# и .Net Framework для enterprise
Инфраструктура enterprise приложения
- Базы данных (MS SQL, PostgreSQL, MongoDB)
- Логирование (ELK stack, Grafana Loki)
- Отслеживание ошибок (Sentry)
- Сбор метрик и хелсчеков (Prometheus)
- CI/CD (Docker, Kubernetes, TeamCity, GitLab CI/CD)
- Очереди, шина данных, планировщик задач (RabbitMQ, Kafka, Hangfire)
- Файловое хранилище (Minio)
- Распределённый кэш (Redis)
- Отображение метрик, логов (Grafana)
Дополнительно к этому всему неплохо бы знать, как работают разные инструменты для поиска проблем в приложении. Например, анализатор памяти (DotMemory), анализатор перфоманса (DotTrace), анализатор запросов в БД (MS SQL Server Profiler).
Микросервисы – модно, молодёжно?
Может показаться, что микросервисы – это классно и круто, что надо каждое новое приложение писать на микросервисах. На самом деле и здесь есть нюансы.
Чтобы реализовать приложения на микросервисной архитектуре, помимо знаний, описанных выше, нужно дополнительно знать паттерны микросервисного взаимодействия.
Возникает куча проблем с распределенными транзакциями. Хорошо, когда у тебя есть монолит, ты можешь сам код обернуть в транзакции. Но с микросервисами это сделать невозможно, потому что в рамках одной транзакции может быть затронуто несколько микросервисов. В этом случае приходится применять паттерн Saga (Повествование).
Профилирование запросов сразу же усложняется несколько раз. Мы не можем взять и посмотреть все его логи у одного сервиса. Весь запрос, начиная от клиента, нужно собрать – воссоздать его «хождение» по разным сервисам. Для этого существуют специальные инструменты.
Сбор логов усложняется. Опять же, у нас нет одного лога у одного предложения, как в монолите. Нужно собирать логи с разных сервисов. Возможно, их придется стандартизировать для удобства отображения и просмотра.
Появляется сильная зависимость от инфраструктуры: очереди, на которые все завязано, например. Кроме интеграции нашего сервиса со сторонними, еще есть интеграция со своими сервисами. Все может упасть. И все эти возможные случаи нужно обрабатывать в коде .
Микросервисы намного сложнее развертывать. Мы не можем поменять API нашего сервиса и залить на прод – сломаются сервисы, взаимодействующие с нашим. Приходится оставлять поддержку предыдущей версии API для плавного перехода. Когда все остальные сервисы перейдут на новую версию API, можно будет удалить поддержку старой версии.
А что с отладкой на компьютере разработчика? Когда один сервис зависит от другого, мы не можем просто поднять через дебаг свой сервис и отдебажить все что хочется. Придется отдельно развернуть другой сервис, от которого мы зависим, и начать дебажить вместе с ним. Либо можно запилить заглушку в своем коде. Словом, добавляется проблема взаимодействия.
За что любят enterprise разработку
- Возможность использовать самый последний стек технологий.
- Возможность совершенствовать свой код на протяжении долгого времени.
- Полное погружение в доменную область бизнеса.
- Работа с разными библиотеками и инфраструктурными сервисами.
- Самостоятельное проектирование БД и архитектуры приложения.
- Хорошая документация по проекту.
- Налаженный процесс полного цикла реализации задач.
Есть потенциальная возможность работать на самом последнем стеке технологий – особенно если вовремя переходить между фреймворками, а не затягивать переход на годы.
С другой стороны, если много микросервисов, и они используют общие библиотеки, то может начаться целая история с обновлением до нового фреймворка всех зависимостей. Зато если у вас средний монолит или несколько сервисов, то переходить между фреймворками достаточно просто.
Просто обновившись, можно оптимизировать использование памяти или увеличить перфоманс. Это удобно.
Вы вольны решать, что будете использовать в проекте: какие именно библиотеки, инфраструктурные сервисы и прочее. Иногда можно их поменять, если совсем не подошло изначально выбранное решение. Получается, что разработчик будет владеть разноплановыми технологиями. Многим как раз нравятся такие проекты за то, что на них можно расширить свой кругозор.
Вы сами проектируете базу данных и архитектуру приложения. Это своего рода вызов. С другой стороны, если спроектировать неправильно, то все тапки в вас.
Зачастую enterprise проекты создаются долгое время. Поэтому невозможно обойтись без хорошей документации. Ведь если команда большая, и есть некоторая текучка сотрудников, то без проектной документации будет невозможно поддерживать и дорабатывать сервис. Поэтому следить за ней обязательно – это и плюс.
Над приложением в enterprise трудится целая команда: разработчики, тестировщики, аналитики, менеджеры, девопс-отдел, отдел баз данных. Они на разных этапах контролируют процессы доведения задачи до продакшна и дальнейшего тестирования, поиска проблем. Когда полный цикл реализации задач налажен, проще будет вводить в команду новых сотрудников.
Но не без трудностей
- Горящие баги на проде, жtсткие сроки реализации фич.
- Нужно обладать хорошими знаниями по C#, .Net, базам данных.
- Сложный выбор подходящей под задачу библиотеки или инфраструктурного сервиса.
- Без своевременного рефакторинга приложение превратится в большой ком грязи.
- Сложный онбординг нового сотрудника.
- Свои «велосипеды».
Горящие баги на проде – правда для всех типов проектов. Пример: нам нужно реализовать фичу к определенному сроку, потому что зависим от регуляторных рисков. Тут либо внедряем функционал в срок, либо мы теряем деньги. Когда что-то сломалось на проде, бывает необходимо подключаться в любое время: утром, днем и ночью, чтобы срочно что-то пофиксить.
По-хорошему, чтобы попасть в энтерпрайс команду, нужно обладать хорошими знаниями по базам данных, фреймворку .Net, языку C#, чтобы не совершать элементарных ошибок. Если допускать ошибки в каких-то базовых вещах – неправильно использовать коллекции, асинхронный код – будут блокеры в разработке и расход бюджета впустую.
Необходимость подбора библиотеки или инфраструктурного сервиса – это и плюс, и минус одновременно. С одной стороны, у вас развязаны руки: вы можете попробовать то, что сами хотите. С другой – если вы выберете что-то не то, потом это будет сложно заменить. Нужно уметь думать превентивно.
Вся ответственность за неправильно выбранный сервис или библиотеку лежит на вас. Это и минус.
Рефакторинг. Нельзя написать проект и потом его только дописывать, не возвращаясь к уже реализованным частям. Постоянно придется рефакторить отдельные участки кода или переписывать их по разным причинам. Требования к продукту по мере его развития могут меняться.
Поэтому если не будет своевременного рефакторинга, через несколько лет придется просто выбросить это приложение и написать его с нуля. А это очень сложная задача, когда у тебя есть текущее работающее приложение на проде.
У каждой компании есть свой велосипед. Это значит, что разные разработчики используют свои библиотеки, свои инфраструктурные решения, работают в своей доменной области. Поэтому нельзя просто взять и сменить компанию: прийти и сразу же влиться в работу после совершенно других проектов.
На то, чтобы вкатываться в новые проекты, всегда будут требоваться время и усилия.
Что почитать по теме
CLR via C#. Программирование на платформе Microsoft .NET Framework 4.5
Паттерны объектно-ориентированного проектирования
Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссиденес
Чистая архитектура. Искусство разработки программного обеспечения
Принципы юнит-тестирования
Микросервисы. Паттерны разработки и рефакторинга
Реализация методов предметно-ориентированного проектирования
За содействие в подготовке материала отдельная благодарность ведущему.NET разработчику Федору Киселеву.
- enterprise
- .net core
- enterprise architecture
- энтерпрайз
- разработка программного обеспечения
- разработка приложений
- чистый код
Источник: habr.com