01:24 19-12-2005 Заметка себе на будущее
Прежде, чем сделать что-то через жопу, подумай, а не настанет ли момент, когда это что-то придется сделать правильно? И если такое развитие событий возможно, попробуй оценить, насколько просто будет это все переделать. И вне зависимости от результатов оценки (т.е. даже если кажется, что рефакторинг будет простым и безболезненным) делай так, как надо, даже если сейчас это связано с кучей рутинных и "очевидных" операций.
А то будет как сегодня.
Состояние: вымотаное
А то будет как сегодня.
Состояние: вымотаное
Комментарии:
10:22 19-12-2005
Мдя... логично...
Интересно, что на этот раз ты сделал через точку приложения?
Интересно, что на этот раз ты сделал через точку приложения?
Black Dragon
11:46 19-12-2005
Только лень заставит админа настроить все раз и навсегда :-)
13:18 19-12-2005
полностью согласен... такую политику (делать сразу правильно) надо брать за практику и постоянно ее применять... иначе... жопа случится
13:56 19-12-2005
А что сегодня было?)
15:16 19-12-2005
Ну ... есть у меня язык FTML - язык разметки шаблонов, основанный на фреймах. Есть его парсер, состоящий, по сути, из двух модулей. Первый модуль, основанный на регулярных выражениях, разбирает исходный текст шаблона и извлекает из него FTML-тэги, конструкцией своей напоминающие XML (отличающиеся от него знаком $ в начале имени каждого тэга). А второй модуль принимает на вход тэг, анализирует его имя, параметры и тело и заменяет их либо на текст, либо на пользовательские элементы управления Web. Так как язык планировался как довольно гибкая и универсальная штука, то в нем есть и переменные, и логические конструкции, и циклы, и рекурсивные вызовы (по сути в виду специфики предметной области именно рекурсии в нем больше всего). Для поддержания всей этой фигни используется набор стеков и индексированных списоков, в которых хранится все необходимая для папрсера информация. Набор этот именуется контекстом.
Ну и вот. Когда все это начинало писаться к октябре месяце, я все это дело просто сваливал в один класс и в один метод, нужное действие выбирал по имени тэга обычным if'ом, контекст хранился в виде полей того класса, где все это лежало, а когда требовался рекурсивный вызов, создавался новый экземпляр этого класса, в который передавались куски контекста.
А с тех пор количество тэгов приблизилось к сотне, действий, которые они могли выполнять и того больше, параметры, естественно, начали противоречить друг другу, а разобраться когда какой кусок контекста нужно передавать в рекурсивный вызов, а когда нет, было нереально. Но все это с горем пополам работало, трогать не хотелось.
А позавчера возникла необходимость сделать механизм расширения языка. Т.е. отделить модули парсера друг от друга - первый, выделяющий из текста сами тэги, оставался в рамках основной библиотеки системы, а второй, анализирующий их, должен был быть вынесен во внешние библиотеки, независимые друг от друга, чьи имена и количества неизвестны - для того, чтобы можно было раширять стандартную библиотеку тэгов засчет дополнительных модулей, создаваемых по отдельному заказу и просто копируемых в соответсвующую папку в проекте. Короче то, что обычно называется "позднее связывание". А для меня это значило то, что всю ту кучу малу if'ов и else'ов, которые у меня занимались анализом тэгов, можно было отправить на свалку, для каждого тэга создавть отдельный метод, а методы эти были раскиданы по разным классам разных сборок - и кто где удается узнать только в runtime при помощи анализа метаданных. И соответственно, каждый этот метод должен видеть контекст, при рекурсии создавать новый экземпляр парсера, новый контекст, синхронизировать контексты до и после рекурсивного вывода.... Вообще задача не сложная и вообщем понятная, но н сортировку всей той горы мусорора на группу четко структурированных размеченых библиотек ушло ровно 16 часов, из котрых 5% занимало написание нового кода, 45% - попытка разобраться "как эта фигня работала раньше", и 50% - тупая пошаговая отладка в дебаггере в попытке выяснить почему эта же фигня не работает теперь. При этом причиной исключения, сгенерированного обработчиком тэга А на n-ом уровне рекурсии, зачастую оказывалась неадекватная парсировка тэга B на n-5 уровне, а эта неадекватная парсировка получалась так из-за того, что на n-8м уровне обработчик тэга С некорректно передал "дальше" контекст.
Вообщем утром взялся "быстренько переделать парсер", ночью система наконец-то заработала на новой архитектуре. Радости, как вы понимаете, не было предела.
Ну и вот. Когда все это начинало писаться к октябре месяце, я все это дело просто сваливал в один класс и в один метод, нужное действие выбирал по имени тэга обычным if'ом, контекст хранился в виде полей того класса, где все это лежало, а когда требовался рекурсивный вызов, создавался новый экземпляр этого класса, в который передавались куски контекста.
А с тех пор количество тэгов приблизилось к сотне, действий, которые они могли выполнять и того больше, параметры, естественно, начали противоречить друг другу, а разобраться когда какой кусок контекста нужно передавать в рекурсивный вызов, а когда нет, было нереально. Но все это с горем пополам работало, трогать не хотелось.
А позавчера возникла необходимость сделать механизм расширения языка. Т.е. отделить модули парсера друг от друга - первый, выделяющий из текста сами тэги, оставался в рамках основной библиотеки системы, а второй, анализирующий их, должен был быть вынесен во внешние библиотеки, независимые друг от друга, чьи имена и количества неизвестны - для того, чтобы можно было раширять стандартную библиотеку тэгов засчет дополнительных модулей, создаваемых по отдельному заказу и просто копируемых в соответсвующую папку в проекте. Короче то, что обычно называется "позднее связывание". А для меня это значило то, что всю ту кучу малу if'ов и else'ов, которые у меня занимались анализом тэгов, можно было отправить на свалку, для каждого тэга создавть отдельный метод, а методы эти были раскиданы по разным классам разных сборок - и кто где удается узнать только в runtime при помощи анализа метаданных. И соответственно, каждый этот метод должен видеть контекст, при рекурсии создавать новый экземпляр парсера, новый контекст, синхронизировать контексты до и после рекурсивного вывода.... Вообще задача не сложная и вообщем понятная, но н сортировку всей той горы мусорора на группу четко структурированных размеченых библиотек ушло ровно 16 часов, из котрых 5% занимало написание нового кода, 45% - попытка разобраться "как эта фигня работала раньше", и 50% - тупая пошаговая отладка в дебаггере в попытке выяснить почему эта же фигня не работает теперь. При этом причиной исключения, сгенерированного обработчиком тэга А на n-ом уровне рекурсии, зачастую оказывалась неадекватная парсировка тэга B на n-5 уровне, а эта неадекватная парсировка получалась так из-за того, что на n-8м уровне обработчик тэга С некорректно передал "дальше" контекст.
Вообщем утром взялся "быстренько переделать парсер", ночью система наконец-то заработала на новой архитектуре. Радости, как вы понимаете, не было предела.
13:06 24-12-2005
мда....что-то как-то слишком сложно...
10:06 26-12-2005
очень хочется распечатать на большом формате и вывесить в отделе заказчика. но, боюсь, слово ж*па не сплотит наш корпоративный дух.
17:46 26-12-2005
Алекс Лочер, я бы сказал, что изложено более чем доступно. Тебе же еще защита предстоит? так? Вот если также расскажешь на ней - будет мега!
21:00 26-12-2005
Самоирония - это великий дар, даже лучше здорового цинизма
00:11 27-12-2005
Miranda - ну, у нас с тобой немного разные специальности На самом деле это несложно - для специалиста, разумеется.
kyrstya ну... словосочетание "через ж*пу" можно в распечатке заменить на "методом, неоптимальным даже с точки зрения нижнего полушария мозга"
Anthrax - изложено-то оно изложено. Только вот боюсь комиссию мало будут волновать особенности фреймового представления, теневого копирования, и позднего связывания. Комиссию будет спрашивать "почему .Net, a не Java", "почему MSSQL (да еще и 2005й), а не Oracle", "Как будет работать ваша система, если к ней будет несколько сотен подключений одновременно" и прочую вообщем-то очевидную (для меня) ерунду, но на нее корректно отвечать почти нереально (потому что ответы "а потому что мне так захотелось" и "а хрен его знает, поживем-увидим" их не устраивают, а других тут придумать малореально). А еще один замечательный твоварищ будет возмущаться, почему я использую буржуинские слова "CMS", "контент", "парсер" и "коммьюнити", придираться к оформлению и шрифтам, а так же требовать обоснования использования новых технологий вместо "проверенных временем и несколькими поколениями программистов старых добрых методов, разработанных еще в 60е годы академиком таким-то". Другой гражданин наверняка будет утверждать, что не раскрыта тема еб... ээ... е-бизнеса, интеркоммуникации, кастомизации, юзабилити, флексибилити и виртуальных промышленных корпораций. И хрен эту тему раскроешь, ибо предыдущий гражданин за использование каждого из этих (вообщем-то пустых и надуманных) англифицированных терминов будет способен загрызть на месте (с моей точки зрения совершенно справедливо, тока мне от этого не легче). А если вспомнить еще о гражданине, который во всей этой фигне вообще не шарит, но зато мнит себя великим математиком, обожает спрашивать про "алгоритмическую эффективность и вычислительную сложность", активно пересыпая свою ресь фамилиями известных математиков и названиями дано забытых мною теорем и методов.... вообще, скучно не будет
Ладно, ничего, прорвемся
cpcat - больше, собственно, ничего тут и не остается
На самом деле это несложно - для специалиста, разумеется.kyrstya ну... словосочетание "через ж*пу" можно в распечатке заменить на "методом, неоптимальным даже с точки зрения нижнего полушария мозга"
Anthrax - изложено-то оно изложено. Только вот боюсь комиссию мало будут волновать особенности фреймового представления, теневого копирования, и позднего связывания. Комиссию будет спрашивать "почему .Net, a не Java", "почему MSSQL (да еще и 2005й), а не Oracle", "Как будет работать ваша система, если к ней будет несколько сотен подключений одновременно" и прочую вообщем-то очевидную (для меня) ерунду, но на нее корректно отвечать почти нереально (потому что ответы "а потому что мне так захотелось" и "а хрен его знает, поживем-увидим" их не устраивают, а других тут придумать малореально). А еще один замечательный твоварищ будет возмущаться, почему я использую буржуинские слова "CMS", "контент", "парсер" и "коммьюнити", придираться к оформлению и шрифтам, а так же требовать обоснования использования новых технологий вместо "проверенных временем и несколькими поколениями программистов старых добрых методов, разработанных еще в 60е годы академиком таким-то". Другой гражданин наверняка будет утверждать, что не раскрыта тема еб... ээ... е-бизнеса, интеркоммуникации, кастомизации, юзабилити, флексибилити и виртуальных промышленных корпораций. И хрен эту тему раскроешь, ибо предыдущий гражданин за использование каждого из этих (вообщем-то пустых и надуманных) англифицированных терминов будет способен загрызть на месте (с моей точки зрения совершенно справедливо, тока мне от этого не легче). А если вспомнить еще о гражданине, который во всей этой фигне вообще не шарит, но зато мнит себя великим математиком, обожает спрашивать про "алгоритмическую эффективность и вычислительную сложность", активно пересыпая свою ресь фамилиями известных математиков и названиями дано забытых мною теорем и методов.... вообще, скучно не будет
Ладно, ничего, прорвемся
cpcat - больше, собственно, ничего тут и не остается
отредактировано: 27-12-2005 01:03 - Алекс Лочер
Black Dragon
09:14 27-12-2005
Как мне это мою защиту напомнило... Особенно пассаж про математику и тему е-бизнеса