Реализация новой задачи
Когда я получаю задачу, на написание какого-нибудь функционала в скрипте, я иду приблизительно следующим образом:
Что она должна делать, какова ее цель. Составление предварительной логики работы.
- Соответствие другим задачам;
Для примера, в скрипте обменника RichExchanger более 150 000 строк кода и очень много функций и возможностей. Новая задача не должна конфликтовать со старыми. Даже если пользователь подключит 2 конфликтующих плагина, скрипт должен работать. Ничего не должно ломаться.
Любая задача в итоге должна масштабироваться. Прекрасно если это продумано изначально. Потому что потом начинаются сложные шаги миграции и всякие возможные проблемы. Когда мне говорят: «Сделай как-нибудь сейчас, потом поправим», это не нормально. Потому что потом придется делать все сначала.
Для решения какой-либо задачи нужно правильно подобрать функции. Если функции в скрипте уже есть, нужно пересмотреть все места, в которых они используются. Возможно, использование функции здесь и сейчас не входит в планы масштабирования, либо подразумевается масштабирование в другую сторону и произойдет конфликт.
Если функций у нас нет, нужно их написать. Если есть похожие, можно взять их. Но в основном, функции являются уникальными.
Когда код готов, логика продумана и установлена архитектура, можно все это дело протестировать. В ходе тестов приходит осмысление того, что половина работает неправильно, а вторую половину можно улучшить. Ну и ошибки, куда ж без них. Они есть всегда в сложном коде.
Полностью переписываем весь код. Дополняем, меняем функции. Сокращаем и выпускаем первую бета-версию, которую также нужно тестировать.
Всегда были и будут ошибки. Особенно если функция новая. Чем больше найдет тестировщик, тем меньше их найдет пользователь в будущем.
За кодом нужно постоянно следить в будущем. Если функции меняются, нужно проводить изменения. Если появляются функции лучше или быстрее, нужно внедрять их. Код без рефакторинга очень быстро станет устаревшим.