Что такое API

API (англ. Application Programming Interface — программный интерфейс приложения) — это набор способов и правил, по которым различные программы общаются между собой и обмениваются данными.

Все эти взаимодействия происходят с помощью функций, классов, методов, структур, а иногда констант одной программы, к которой обращаются другие. Это основной принцип работы API.







Допустим, вы покупаете билет в кино с помощью банковской карты. Во время покупки терминал обращается к API банка, который выпустил вашу карту, и отправляет запрос на оплату. А если вы заказываете такси через приложение, оно обращается к платёжной системе тоже через API.



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

API встречается практически везде

Ссылка с оригинального источника, где более подробно вы сможете понять, что такое API: https://skillbox.ru/media/code/chto_takoe_api/

Landing Page

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

Переход на целевые страницы часто осуществляется из социальных сетей, email-рассылок и рекламных кампаний в поисковых системах. Главной задачей таких страниц является конвертация посетителя в покупателя или клиента, побуждение к целевому действию, покупке. Анализ действий пользователей на целевой странице позволяет маркетологам определить успешность рекламы.

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

выдержка из wikipedia

CRM система

Система управления взаимоотношениями с клиентами (CRM, CRM-система, сокращение от англ. Customer Relationship Management) — прикладное программное обеспечение для организаций, предназначенное для автоматизации стратегий взаимодействия с заказчиками (клиентами), в частности для повышения уровня продаж, оптимизации маркетинга и улучшения обслуживания клиентов путём сохранения информации о клиентах и истории взаимоотношений с ними, установления и улучшения бизнес-процессов и последующего анализа результатов.

CRM-система может включать: фронтальную часть, обеспечивающую обслуживание клиентов на точках продаж с автономной, распределенной или централизованной обработкой информации; операционную часть, обеспечивающую авторизацию операций и оперативную отчётность; хранилище данных; аналитическую подсистему; распределенную систему поддержки продаж;

выдержка из wikipedia

Нужен ли рефакторинг работающего приложения ?

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

Цель архитектуры приложения - уменьшить человеческие трудозатраты на создание и сопровождение системы.

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

Так ли это на самом деле ?

В качестве примера рассмотрим результаты исследований из практике. Они основаны на реальных данных, предоставленных реальной компанией, пожелавшей не разглашать своего названия. Сначала рассмотрим график роста численности IT персонала. Вы наверняка согласитесь, что тенденции впечатляют. Рост численности, как показано на первом рисунке, должен служить признаком успешного развития компании!





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



А теперь взгляните на по-настоящему удручающий график:
на этом графике показан рост стоимости строки кода с течением времени. Эта тенденция говорит о нежизнеспособности, Какой бы рентабельной ни была компания в настоящее время, растущие накладные расходы поглотят прибыль и приведут ее к застою, если не к краху. Чем обусловлено такое значительное изменение продуктивности ? Почему строка кода в версии 8 продукта стоит в 40 раз дороже, чем в версии 1?

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



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

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

Если вы думаете, что ситуация скверная, взгляните на нее с точки зрения руководства! Когда была выпущена версия 1, месячный фонд оплаты труда составлял несколько тысяч долларов. К выпуску второй версии фонд увеличился еще на несколько тысяч. К выпуску восьмой версии месячный фонд оплаты труда составил уже приличную сумму и тенденция к увеличению сохраняется.

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

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

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

Ответ прост: рефакторить проект и переходить на новые подходы реализации функционала.

Есть такая притча о Зайце и Черепахе, которую сочинили примерно 2000 лет тому назад, о соревновании между зверями кто первый придёт к финишу. Заяц был настолько уверен в своей скорости, что не отнесся всерьез к состязанию, решил вздремнуть и проспал, когда Черепаха пересекла финишную черту. Мораль той басни подчеркивает глупость и самонадеянность.

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

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

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

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

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

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