---
# System prepended metadata

title: insta2amo

---

---
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. **Продумать архитектуру:**
	Как и первый, этот пункт довольно абстраткный. Сейчас я куда лучше понимаю ООП, научился использовать (и получать от этого удовольствие+выгоду) абстракции. Это позволяет писать куда более модульный код. Модульный код == код, который легче обновлять, который более стабилен и т. д.
	*Плюсы для нас:* по сути, самая важная часть обучения программированию — написание кода на пределе возможностей. Я получу много полезного опыта.
	*Плюсы для бизнеса:* в рамках этого конкретного проекта (пионы) — сказать сложно. Если текущий функционал далее развиваться не будет — наверное, можно и так прожить.
	Но если у них еще много идей по доработке, либо же если мы ориентируемся на более широкий рынок — это необходимо.