Введение

Мы часто говорим об алгоритмах как о «сердце» любой сложной системы. В контексте нашей платформы Гриндаты алгоритмы — это не просто код. Представьте, что данные — это деньги или документы клиентов, а алгоритмы — это инструкции и правила, которые позволяют быстро находить, сортировать, обрабатывать и сохранять эти «деньги/документы».

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

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

Концептуальная основа: ООП (Объектно‑ориентированное программирование)

Концепция ООП лежит в основе структуры и окружения нашей платформы. Понимание ООП необходимо аналитику для:

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

Приложения на GreenData (какие и многие другие приложения) имеют фронтовую часть и бэковую часть. Соответственно ошибки у нас тоже могут возникать как на фронте, так и на бэке.

Как понять относится ошибка к «фронту» или к «бэку»?

Об этом нам скажет сама ошибка, давайте рассмотрим 2 примера ошибок.

Когда я пришёл работать в компанию GreenData шесть лет назад, мои задачи были достаточно стандартными для аналитика, который работает с low-code решениями. Работа с объектной моделью, написание алгоритмов, настройка визуалов - всё что обычно выполняет начинающий специалист в данной области. Однако в процессе моей работы и роста иногда я сталкивался с необходимостью разбираться в тонкостях работы Java, а именно с ошибками, которые возникали в процессе её исполнения.

Эти встречи с Java сначала были случайностью, но со временем превратились в моё новое профессиональное увлечение. Каждый случай сбоя или нестандартного поведения программы становился для меня вызовом; я понял, что за ошибками стоят не просто коды и сообщения, а целые истории о том, как работает система. Этот интерес постепенно перерос в глубокое погружение в мир Java-логов, благодаря чему я стал одним из ведущих экспертов по анализу программных сбоев в компании.