fisher (raa) wrote,
fisher
raa

программистское

слушайте, меня тут снова просят проапгрейдить blitz и добавить туда расширенную версию if-ов. ниже я хотел перечислить варианты, которые предлагаются, чтобы обсудить, но смех, я так растекся мыслею по древу, что у меня до них просто не дошло - получилось о другом совсем. я ваще-то давно такое хотел написать, ну вот вдруг и сложилось неожиданно.



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

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

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

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

но спагетти образуется не сразу. это происходит в какой-то неожиданный момент, никто не помнит как. это психология. разбивается одно окно, и понеслась. и программер моментально такой работы всячески хочет избежать, потому что просто опускает руки, не желая продолжать ковыряться в дерьме. а вероятность того, что этот кусок в дерьмо превратиться - огромна. и как только это происходит - всё, приплыли. если менеджер - лопух и не разгрёбет это немедленно несмотря ни на что - эта история может определить стиль работы и атмосферу в компании на долгие годы вперёд, если не навсегда.

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

на практике конечно начинаются попытки положение исправить. когда настоящему программисту окончательно надоедает влезать в HTML, он конечно довольно быстро придумывает какую-нибудь Штуку. Штука представляет некий инструмент, который можно отдать куда-то к этим и сказать: "вот вам, ребятки, ебитесь сами". эта штука является неотъемлимой и чуть ли не самой важной частью Движка.

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

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

ладно, теперь о том, какие решения по разделению отвественности обычно применяются в-основном на практике
1) логика отображения вместе с HTML реализуется в шаблонах. это мы значит перенесли всю отвественность на непрограммистов. минусы - программят непрограммисты, либо и те и другие - колхоз, не разделяем HTML и код, большой риск получить спагетти.
2) логика отображения реализуется через XML/XSLT - ну теперь верстальщик уже просто не может оставаться непрограммистом, должен забивать голову много ещё чем, да и иметь эту голову несколько иного качества. превращать верстальщика в программиста рискованно, да и сама технология тяжелая с точки зрения потребления ресурсов. но сам подход лучше идеологически.

п.2 оставим, не хотим усложнять. но и п.1. в чистом виде выглядит очень опасно. конечно народ научился снижать риски. как? да очень просто: люди начали сами ограничивать себя. например, разделять логику на два куска: простой внутри HTML, а сложный - где-то ещё. любая логика может быть декомпозирована так, чтобы со стороны HTML она была максимально простой: какой-то блок будет либо показан (один, либо несколько раз), либо нет. условия, при которых это возникает, могут быть сколь угодно сложными. но при работе с HTML достаточно иметь перед глазами конструкцию вида:
{{ IF $show_promo_block }}
тут идет код блока
{{ END }}

а вот уже где-то в скриптовом коде, не смешанном с HTML, там и содержатся эти самые условия, при которых этот самый $show_promo_block выставляется в 1, TRUE или что там. эта логика - важная логика приложения, и за неё отвечает программист. а в HTML коде есть компактный блок, в котором есть очень простое условие, которое не мешает, и всего лишь говорит что некий блок либо будет показан, либо нет.

так вот некоторые шаблонные движки идут дальше и говорят: так какой смысл в этом "IF $show_promo_block"? всё равно непонятно, при каких условиях это всё будет показано. И идут дальше, в шаблоне есть только именованный блок
{{ PROMO_BLOCK }}
тут идет код блока
{{ END }}

а весь код управления блоком выносится в код скрипта. и мы не дадим никакой возможности и соблазна пихнуть в HTML что-то ещё, что сложнее.

и тут происходит ещё одна замечательная вещь, которая делает эти движки очень похожими на хороший идеологически XML/XSLT-подход - с точки зрения разделения работы внутри команды. на самом деле "сцеплением" кода верстальщика и кода программиста, тем самым протоколом взаимодействия, может служить некоторый структурированный массив данных, который просто своей структурой определяет, какой блок будет показан. можно один блок показать несколько раз - для этого просто соответсвующая структура данных должна быть массивом. вложенные блоки - не вопрос, делайте вложенные структуры. в blitz это называется итерацией, её можно сдампить, проанализировать. можно даже сохранить - например использовать в тестах, или хранить "снепшоты" - примеры ситуаций для контекста при переводе в мультиязычных приложениях.

так устроена логика отображения. почему? потому что так удается кучу постоянно изменяемого кода поддерживать компактной командой.
иногда кому-то кажется, что этого маловато (нам - нет, слава Богу, мы даже if не используем в шаблонах - по-моему его первыми вообще хабра-команда крутила). может, и впрямь маловато - не знаю. попробуем разобраться на днях и в другом посте ;)

Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 22 comments