IT-блогер Серж Потаман | Мурманск

Часть 3/3

Вопрос: Какие технические особенности в твоей работе?

Наше скриптописание - это функциональное программирование с намеками на объекты. Инкапсуляция, наследование, полиморфизм отсутствуют как принцип. Жестко привязаны к функционалу скриптового движка с одной стороны, но можем использовать сторонние dll при необходимости. Либо писать какие-то библиотеки самостоятельно, но в любом случае, без скриптового движка основного софта ничего не будет.

Из-за критичности данных на сотню строк кода реально работают 20 строк, остальное - проверки на все случаи жизни. Потеря данных заказчика недопустима.

Приходится работать с кучкой разных технологий и бд (слава богам обычно глубоко лезть не надо) - Oracle, Postgres, SQLite, Apache MQ, всяко-разное по вебу, проприетарные API-шки и тыды.

Заодно поделюсь мыслями про ООП с моей колокольни:

Кажется мне, ООП свернуло куда-то не туда. Уровни абстракции над уровнями абстракции погоняют уровнями абстракции уровни абстракции. Ковырял как-то DLL на C# для одного проекта - это был кошмар. Без нормальной IDE на C# делать вообще нечего, удержать все в голове невозможно. Для ООП-проектов нужно приличное количество времени тратить на архитектуру, иначе потом начнется жесть - кто ж нынче тратит время на архитектуру? Хуяк-хуяк и в продакшн!


А потом начинается - вот тут надо бы переделать, но класс изначально криво сделан, поэтому мы сейчас отнаследуемся и вкорячим туда еще и вот это вот, а вот тут надо заинклюдить вот ту библиотеку на 5 мегабайт и дернуть оттуда одну функцию, а документацию на это все мы будем писать примерно никогда. Брррр. Функциональное как-то поадекватнее будет, если все правильно делать )))))

За рассказ о работе с БигТех спасибо @Zlyden69

👍8🤔1

www.group-telegram.com/us/p1ngpub.com/2328

1.05K viewsedited  Jun 15 at 12:24

Часть 3/3

Вопрос: Какие технические особенности в твоей работе?

Наше скриптописание - это функциональное программирование с намеками на объекты. Инкапсуляция, наследование, полиморфизм отсутствуют как принцип. Жестко привязаны к функционалу скриптового движка с одной стороны, но можем использовать сторонние dll при необходимости. Либо писать какие-то библиотеки самостоятельно, но в любом случае, без скриптового движка основного софта ничего не будет.

Из-за критичности данных на сотню строк кода реально работают 20 строк, остальное - проверки на все случаи жизни. Потеря данных заказчика недопустима.

Приходится работать с кучкой разных технологий и бд (слава богам обычно глубоко лезть не надо) - Oracle, Postgres, SQLite, Apache MQ, всяко-разное по вебу, проприетарные API-шки и тыды.

Заодно поделюсь мыслями про ООП с моей колокольни:

Кажется мне, ООП свернуло куда-то не туда. Уровни абстракции над уровнями абстракции погоняют уровнями абстракции уровни абстракции. Ковырял как-то DLL на C# для одного проекта - это был кошмар. Без нормальной IDE на C# делать вообще нечего, удержать все в голове невозможно. Для ООП-проектов нужно приличное количество времени тратить на архитектуру, иначе потом начнется жесть - кто ж нынче тратит время на архитектуру? Хуяк-хуяк и в продакшн!


А потом начинается - вот тут надо бы переделать, но класс изначально криво сделан, поэтому мы сейчас отнаследуемся и вкорячим туда еще и вот это вот, а вот тут надо заинклюдить вот ту библиотеку на 5 мегабайт и дернуть оттуда одну функцию, а документацию на это все мы будем писать примерно никогда. Брррр. Функциональное как-то поадекватнее будет, если все правильно делать )))))

За рассказ о работе с БигТех спасибо @Zlyden69

BY IT-блогер Серж Потаман | Мурманск