Мини анонс

Издательства

загрузка списка...


Вы здесь: Авторские колонки FantLab > Авторская колонка «kenrube» > Мини-анонс
Поиск статьи:
   расширенный поиск »

Мини-анонс

Статья написана 20 августа 2020 г. 19:09

Прошу прощения у всех неравнодушных админов и пользователей, но я вынужден закрыть прием заявок на доработки по сайту. К настоящему моменту открытыми висят 95 задач по сайту* и еще порядка 10 достаточно крупных задач по API (Go, Perl и документация), так что банально не успеваю их разгребать. Откроется ли прием заявок после закрытия всех задач — не знаю, но вряд ли. Чинить сайт в его текущем состоянии можно до скончания времен, глобально это ничего не изменит. А у меня есть и другие проекты, которые ждут своей очереди. Еще раз приношу свои извинения.

* Разумеется, речь только про мои задачи — все то, что было обещано к исправлению/реализации. Общее количество незакрытых задач много больше

PS Но если что-то прямо совсем срочное — пишите, постараюсь починить

PPS Надеюсь, рано или поздно про сайт вспомнят и программисты-основатели. Пора бы уже





142
просмотры





  Комментарии
Ссылка на сообщение20 августа 2020 г. 22:53
Чинить можно долго? А что надо переделывать с сайтом?
свернуть ветку
 
Ссылка на сообщение21 августа 2020 г. 08:25
По-хорошему, ответ на этот вопрос должен быть длинным, подробным и аргументированным, но если кратко: переписать с нуля, начиная с базы. Все остальное долгосрочного эффекта не возымеет
 
Ссылка на сообщение21 августа 2020 г. 08:37
Для непрофессионала. А почему такая необходимость?
 
Ссылка на сообщение21 августа 2020 г. 11:39
Это не необходимость, а просто рекомендация. Причин много, вот несколько:
  1. Perl в качестве основного языка. Он морально устарел, так что найти сейчас специалистов, готовых забесплатно разгребать авгиевы конюшни устаревший код, — задача, близкая к невыполнимой
  2. Perl — язык без строгой типизации. Как следствие, ты не можешь быть уверен, что код, который ты написал, в реале заработает именно так, как планировалось. В современных языках все ошибки типизации отлавливаются на этапе сборки приложения
  3. Более того, из-за этой особенности невозможно понять, какая часть кода рабочая, а какая — нет. Если код ниоткуда не вызывается, о его работоспособности вообще ничего сказать нельзя. Когда-то, году в 2013, была предпринята попытка разгрести ужасную старую лапшу из кода и перенести это все на рельсы современного фреймворка, но года через полтора-два застопорилась. По итогу половина кода работает по-новому, половина — по-старому и есть еще большой массив кода, который есть и в старом варианте, и в новом, и какой из них работает на самом деле — неясно (это последствие еще одной причины — процессов разработки; практически никакой старый код не удалялся)
  4. Переписать оставшийся код тоже достаточно проблематично: там крайне разветвленная и сложная для понимания логика, написанная разработчиками, которые в большинстве своем давно покинули проект, так что и спросить некого (впрочем, попытки спросить ныне здравствующих программеров в 95% случаев тоже оборачиваются ничем, в итоге забил что-либо спрашивать). Недавно я убил несколько дней на то, чтобы понять всю логику отрисовки одной страницы темы форума (чтобы перенести эту логику в Go-API), так вот, там ад: список сообщений отличается в зависимости от того, залогинен ли юзер, обычный юзер или модератор, активирован или нет, есть черновик или нет, тема отмодерирована или нет; внешний вид сообщения зависит от того, зацензурено оно или нет, какой рейтинг, какие у текущего юзера права, модератор он или нет, можно ли на этом форуме ставить минусы и тд, и тп. Все бы ничего, будь это написано по-человечески, но нет, очередная лапша
  5. Несмотря на то, что часть кода переписана на новый лад, там все равно регулярно используются плохие практики — поход из слоя отрисовки к базе данных за данными и тд. Это очень плохо и нарушает архитектурный паттерн MVC, который и пытались внедрить
  6. Неполная миграция на MVC, кстати, не дает хоть сколько-нибудь значимо поменять интерфейс сайта. Например, простейшее — внедрить темную тему. Одно дело, когда тебе достаточно завести альтернативный CSS для этого, и другое — когда надо переписать гору мешанины из Perl, запросов к базе, HTML и JS, поскольку все свалено в одну кучу
  7. Плохие архитектурные решения, типа файловых кешей (на замену есть гибридные специализированные решения типа Redis, хранящие данные и в памяти, и на диске) или вечные кеши в памяти, особенно любимые Лешей. Если у вас после правок какое-то поле не обновляется, знайте — скорее всего, кто-то накосячил с кешированием
  8. При создании и доработке базы, судя по всему, никаких архитектурных решений вообще не было. В одной базе спокойно живут по соседству библиографические данные и приватная переписка юзеров. В одной таблице лежат данные библиографические и поля, связанные с каким-нибудь Озоном. И тд. Про понятие нормализации баз данных вообще никто не слышал, а это ключевое условие для надежной, производительной и легкой к изменениям базы
  9. Здесь надо понимать, что любая ошибка в структуре базы влечет за собой необходимость кратно больших усилий для ее нейтрализации на уровне кода. Классический пример — ограничение в 5 авторов на ворк. В каждом месте, где надо показать/изменить/что-то еще сделать с ворком, приходится извращаться, чтобы поработать со списком его авторов. Неоднократно были предложения это исправить, но метастазами поражен уже весь код: по моим прикидкам, порядка 250 мест, где это надо исправлять
  10. Это только малая толика всех проблем

Короче говоря, я совершенно не удивлен, что все программисты разбежались кто куда: разгребать все это наследие, попутно наблюдая полное безразличие со стороны руководства — занятие малоприятное
 
Ссылка на сообщение21 августа 2020 г. 11:49
Спасибо. В целом это системная проблема, не только программирования. :-(((
 
Ссылка на сообщение21 августа 2020 г. 12:55
Да, разумеется, все это глубоко печально
 
Ссылка на сообщение22 августа 2020 г. 12:11
Спасибо за развернутый ответ, более-менее внятный даже для чайника.

Думаю, следует перенести этот текст в тело основного поста.

Я правильно понимаю, что сохранение текущей ситуации это практически приговор развитию сайта уже в ближнесрочной перспективе?
 
Ссылка на сообщение22 августа 2020 г. 12:20

цитата Крафт

Я правильно понимаю, что сохранение текущей ситуации это практически приговор развитию сайта уже в ближнесрочной перспективе?

Хочу верить, что эпоха застоя все же закончится в скором времени
 
Ссылка на сообщение22 августа 2020 г. 14:47
Будьте реалистом — требуйте невозможного!


Ссылка на сообщение21 августа 2020 г. 10:39

цитата Kons

А почему такая необходимость?

Могу предположить, что «нельзя всё время ложить заплатки, нужно что-то просто перешить».
Уж, как минимум, в заплатках ориентироваться очень трудно.
свернуть ветку
 
Ссылка на сообщение24 августа 2020 г. 13:04
Да, одна из причин


Ссылка на сообщение23 августа 2020 г. 19:14
Я извиняюсь, если что-то неаккуратно сказал, чем-то задел.
свернуть ветку
 
Ссылка на сообщение24 августа 2020 г. 13:16
Да все норм :) Это мне надо извиниться за то сообщение, когда сорвался — меня тогда покоробило предложенное решение (которое не решает проблему на корню), особенно при незнании внутреннего устройства, которое накладывает большой отпечаток на сложность закрытия любого бага.
Собственно, прошу прощения


Ссылка на сообщение30 августа 2020 г. 16:24
спасибо за то, что сделано
свернуть ветку
 
Ссылка на сообщение30 августа 2020 г. 16:34
:beer:


⇓ ⇑ Наверх