--- title: insta2amo --- Разговор о рефакторинге я бы разбил на две части. Первая касается целесообразности: в ней я расскажу, что я хочу изменить и какая выгода из этого может быть получена. Далее мне нужно прикинуть архитектуру хотя бы на бумажке и после этого мы можем говорить уже более предметно: сроки, стоимость, функционал. # Часть 1: целесообразность Чтобы быть более честным, плюсы того или иного предложения я разобью на две части: плюсы для меня как разразботчика (и для вас, как человека заинтересованного в моём профессиональном росте), и плюсы для бизнеса. 1. **Повышение качества кодовой базы** Наверное, самый абстрактный и не конкретный пункт, но при этом — один из самых важных. Текущее состояние проекта хорошо характеризует фраза «начали за здравие, кончили за упокой». Git фактически не используется уже давно, в коде присутствуют какие-то закомментированные куски и дублирование функционала. Я бы провёл здесь аналогию с чисткой зубов. Что вы от этого выигрываете? В сущности — ничего. Но это необходимо делать, чтобы не проиграть. Здесь ситуация довольно похожа. За кодом тоже нужно ухаживать время от времени. С течением времени «мера хаоса» и технический долг возврастают всё больше, каждая правка начинает требовать всё больших дополнительных усилий, обусловленных тем, что даже бутылка не поможет разобраться. *Плюсы для нас/плюсы для бизнеса:* это просто необходимо сделать, иначе каждая малейшая правка будет требовать в N раз больше времени. 2. **Переосмысление лога** Я не могу сказать, что реализация собственного костыля для этих целей была пустой тратой времени. Тем не менее, факт в том, что сейчас лог организован довольно плохо. Мне сложно объяснить, что не так, но сам подход ошибочен. Как минимум: - Нужно использовать несколько разных логов. Сейчас их всего два, один из которых — псевдолог (запись ответов инстаграм как есть). Это весьма неудобно, каждый «модуль», по-хорошему, должен иметь свой лог. Не обязательно свой лог-файл, но свою «категорию». - Нужна возможность на лету сделать лог куда более/менее подробным. Debug-mode. - Как я уже говорил, сейчас он слишком размазан. Нет какой-то единой системы того, согласно которой определяется, где лог будет писаться *Плюсы для нас:* опыт в организации лога, проблемы в коде будет искать куда проще. *Плюсы для бизнеса:* баги будут чиниться быстрее и с меньшими трудозатратами, да и в целом их будет проще выявить на этапе разработки. 3. **Настройка сервера** Как я уже говорил, целенаправленно я системное администрирование не изучал и вряд ли в ближайшее время буду, но всё-таки — что-то, да умею. Сейчас на все правила администрирования наплёвано с высокой колокольни, потому что сейчас мы исходим из того, что моя задача — написать код и как-то его запустить. Мне хочется немного отойти от этой практики и исходить из того, что я должен также следить за минимальным порядком на сервере. Сейчас всё довольно плохо: - Я работаю из под рута. Это огромная дыра в безопасности. - Сервер никак не защищён от брутфорса. При этом, пароль у рута не особо то и длинный. - Помимо проблем с безопасностью, в целом, опять же, нет какой-то логики и структуры. Код раскидан по системе. *Плюсы для нас:* у меня нет планов особо сильно погружаться в эту тему, но всё же, это далеко не первый раз, когда сисадмина в проекте нет (даже частичного в лице меня), а потому сервер — лёгкая мишень для взлома. Поэтому мне хотелось бы овладеть хотя бы минимальным набором знаний (или, вернее, оживить их в своей голове): настройка пользователей, OpenSSH, Apache, Fail2Ban. *Плюсы для бизнеса:* вопрос философский. Как показывает практика фриланса, 99% российского бизнеса плевать на покупателей с высокой колокольни, абсолютно безответственное отношение к ПД пользователей. Не один раз видел логин и пароль прямо в описании задания на WZ (то есть, зайти на сайт может кто угодно). Волнует ли пионов ситуация, в которой сервер взломают и, например, сольют базу с амо? Я не знаю. Но по-уму — должна волновать. Я не предлагаю носить шапочку из фольги, к тому же я далеко не эксперт по ИБ, но минимальный набор правил мы морально-должны исполнить. 4. **Более вдумчивое изучение amoCRM и его API** У меня есть желание изучить amo. Не досконально, но хотя бы на том уровне, на котором его знают менеджеры. Сейчас я немного как обезьяна, которая полуслучайно тыкается и имеет в голове кашу из того, что есть сделка, что есть контакт, что такое воронка, какие есть типы примечаний и т. д. *Плюсы для нас:* можно будет получить более глубокий опыт и уверенно предлагать услуги по допиливанию чего-либо для амо. *Плюсы для бизнеса:* думаю, что гораздо более продуктивно работается, когда программист понимает сервис, с API которого он работает с точки зрения пользователя. Может, какие-то вещи можно реализовать гораздо более просто и удобно? Какие возможности в амо вообще есть из коробки? Я не особо знаю. Ставят задачу - выполняю её, но в моём понимании амо всё еще много белых пятен. 5. **Написание документации** Я бы написал к проекту минимальную документацию, а именно: - Как запускать/включать - Из каких модулей состоит - Какие команды (с какими аргументами) принимает внешний интерфейс *Плюсы для нас:* для меня плюс в том, что у меня будет пусть и минимальный (обещаю, я не буду сильно углубляться в эту тему, сейчас мой главный исследовательский интерес в коде), но всё же какой-то шаблон документации. Для вас — в том, что если к проекту нужно будет подключить какого-то другого программиста, такая даже убого-минимальная документация ему сильно поможет. *Плюсы для бизнеса:* поскольку бизнес с кодом в данном случае абсолютно никак не взамодействует — можно сказать, что их нет и это наши внутренние дела. 6. **Внедрение тестов** Думаю, вы понимаете, что это must have. Одна из самых противных вещей в программировании — это то, что ты вносишь вроде бы безопасное и небольшое исправление, а оно, оказывается, создаёт в каком-то неожиданном месте ошибку. Тестирование позволяет избежать очень многих таких проблем. Наверное, SCV + тесты это самые важные инструменты в разработке. *Плюсы для нас:* сейчас у меня очень мало опыта в написании тестов: очевидно, что нужно больше. Это хорошая возможность получить его. Еще это поможет находить баги до того, как код не пойдет непосредственно в production. *Плюсы для бизнеса:* в production будет всплывать меньше багов. Скажем, такой ситуации, как "восприятие ссылок как номеров" скорее всего не произошло бы, если бы мы писали тесты. 7. **Challenge** Как я уже сказал, функционал, с одной стороны, довольно нестабилен. Но с другой — это лучше, чем ничего. Сейчас мы ходим по тонкому льду: если instagram вдруг чем-то обидется на сервер и решит выдать нам challenge — мы абсолютно беззащитны. Всё, что мы можем - сменить сервер и понадеяться, что это поможет. Конечно, внедрение функционала прохождения Challenge не даст 100% гарантии, но и слишком низкой её не назвать. 50:50 где-то. *Плюсы для нас/плюсы для бизнеса:* если вдруг попадём на challenge, работа бота невозможна. 8. **Не прямые запросы к API** Возможно, потеряшки действительно связаны с какой-то другой ошибкой. Но это не отменяет того, что у нас потенциальная дыра (в надёжности): если API amo/instagram на пару секунд подключит и мы кинем в это время запрос, он уйдёт в никуда. Сейчас я пришёл к такому золотому правилу: если речь о взаимодействии по сети с другими сервисами и взаимодействие это важно, его необходимо делать через очередь заданий. *Плюсы для нас:* я получу практический опыт реализации очереди задач. *Плюсы дял бизнеса:* не будет столь явной потенциальной дыры в надёжности. 9. **Развить идею с перепроверкой** Этот пункт я пишу как TODO для себя. Поскольку это самая важная и критичная часть проекта, я думаю, что даже после рефакторинга стоит оставить эту дополнительную проверку того, ответил ли бот человеку. 10. **Продумать архитектуру:** Как и первый, этот пункт довольно абстраткный. Сейчас я куда лучше понимаю ООП, научился использовать (и получать от этого удовольствие+выгоду) абстракции. Это позволяет писать куда более модульный код. Модульный код == код, который легче обновлять, который более стабилен и т. д. *Плюсы для нас:* по сути, самая важная часть обучения программированию — написание кода на пределе возможностей. Я получу много полезного опыта. *Плюсы для бизнеса:* в рамках этого конкретного проекта (пионы) — сказать сложно. Если текущий функционал далее развиваться не будет — наверное, можно и так прожить. Но если у них еще много идей по доработке, либо же если мы ориентируемся на более широкий рынок — это необходимо.