1. nwalker.mp

    21.09.2011

    0 ↑
    0 ↓

    Это не столько вопрос, сколько рассуждения на офтоповые темы. Извиняюсь, если что не так.

    Есть проект, в котором работают джанго и торнадо. Вкратце - на джанго весь ui и api для мобильных приложений, на торнадо - comet через socket.io, эти части общаются через redis pub/sub, в редисе еще чуть-чуть данных. Это три четверти кода, оставшаяся часть - яваскрипт.

    В джанго-части, кажется, я наворотил лишнего с разделением на приложения, сделал несколько лишней магии в авторизации, в паре мест уперся в возможности orm - например, отсутствие batch insert. В торнадо-части есть необходимость дергать БД, что мне очень не нравится, но для этого заботливо приделан костыль. Короче, мне ощутимо не нравится результат. Пока есть время и проект не торопится в бой, думаю о рефакторинге или вовсе переписывании с нуля.

    Вариантов у меня три:

    1. Рефакторинг и реорганизация имеющегося кода.
    2. Переписать джанго-часть на flask+sqlalchemy. В ui всего десяток вьюх, в api 10-20 методов, кода не много и не особо страшно. Для админки сойдет flask-admin, для организации кода сгодятся blueprints, для авторизации - flask-login, плюс - есть webassets, которые любом случае нужно прикрутить(5 js + 3 css на одной странице - это плохо).
      Что мне не нравится в этом варианте: blueprints не могут содержать в себе модели, модели будут одной лежать большой кучей. Нужно вручную таскать везде application object, и вообще, flask не очень приспособлен для разделения кода по разным файлам(или я не умею его готовить?). Не меняется торнадо-часть.
    3. Очень интригующий вариант - Erlang+ChicagoBoss. Почти приличные django templates, почти не нужно переписывать. Огромный плюс - есть встроенный pub/sub, выкидывается все, что касается IPC, один процесс на все.
      Но дальше идут сплошные минусы. Erlang, который я знаю недостаточно, чтобы хакать сам фреймворк. ORM, который не сильно гибче джанговского и не умеет миграций. Отсутствие management cli, отсутствие отладочной оболочки, отсутствие готовых компонент. Короче, помимо преимуществ эрланга, почти ничего нет, и это очень печально.

    Если кто-то таки осилил эту сумбурную простыню - поделитесь впечатлениями, идеями, предложениями. Кто бы что предпочел в данной ситуации?

  2. Короче, мне ощутимо не нравится результат. Пока есть время и проект не торопится в бой, думаю о рефакторинге или вовсе переписывании с нуля.

    Если кто-то таки осилил эту сумбурную простыню - поделитесь впечатлениями, идеями, предложениями. Кто бы что предпочел в данной ситуации?

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

  3. nwalker.mp

    21.09.2011

    0 ↑
    0 ↓

    Без более формализованных метрик обоснования вывода "не нравится" невозможно дать совет или что-то предложить.

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

    1. код слишком раздроблен на приложения - маловажно, но неудобно. Стремясь четко разбить функциональность по приложениям, я, кажется, чересчур увлекся.
    2. работа с бд кажется мне откровенно неоптимальной. В нескольких местах встречаются Smth.objects.get_or_create или Smth.related.all() в цикле. C учетом неясных скачков нагрузки в production, хотелось бы эти места оптимизировать.
    3. работа с бд не django way. Для сериализации данных в JSON "чтобы было DRY" были написаны отдельные объекты, а не использованы менеджеры/методы моделей. Эти объекты быстро и решительно стали write-only. В некоторых местах для сериализации нужно было знать что-то о связанном объекте, что не способствовало использованию нормальных методов.
    4. на основе этого проекта будет делаться еще один с схожей функциональностью. Хотелось бы иметь возможность легко вносить изменения, с которой сейчас не очень.
  4. Тесты-то пишете?

    bulk insert в джанге в транке есть (+ сторонние штуки вроде http://pypi.python.org/pypi/dse/, не знаю, как это на деле).

    С чрезмерной раздробленностью кода есть один хитрый метод борьбы - проверять эти раздробленные куски на автономность и полезность (хотя бы для вашего проекта), потом выкладывать в open source и ставить через requirements в pip :) Или хотя бы писать их так, чтоб можно было скопировать и использовать в другом проекте без изменений - главное тут следить за зависимостями между пакетами и упрощать их, убирая неоправданные.

    В основном проблемы-то, как я понимаю, идеологического плана - как организовать код. Можно почитать Мартина ("Чистый код", хорошая книжка про микро-рефакторинги), Фаулера (главное без фанатизма, просто чтоб идей больше узнать, а идей там много), SICP (чтоб без ООП писать научиться) и т.д.

    Тут супер-пилюли нет, и абсолютной истины imho тоже нет, и у "гуру" субъективизма полно, но если идеи более-менее понимать и больше думать при написании кода (не только о том, чтоб он работал - об этом как раз особо думать не надо, написал тест и вперед, - а о том, как его организовать проще и лучше), то вполне можно поддерживаемый код получать.

  5. nwalker.mp

    21.09.2011

    0 ↑
    0 ↓

    Тесты-то пишете?

    приучаюсь. не проверять же всё апи curl-ом, в самом деле. но "test first" как-то мне пока не по нраву. опять же, далеко не все понятно как тестировать.

    bulk insert в джанге в транке есть

    о, спасибо. как-то я за ним не следил с выхода 1.3.

    http://pypi.python.org/pypi/dse/

    спасибо, посмотрю. хотя, после django-primate(да и до него, он просто добил) я не очень люблю манкипатчинг.

    проблемы-то, как я понимаю, идеологического плана - как организовать код

    да, это есть. регулярный тупик, как что-то сделать красивее и аккуратнее. =)

    помимо этого этого всегда хочется взглянуть на что-то новенькое из инструментов. а как еще лучше взглянуть, чем реализовать что-то, что уже хорошо представляешь?.. =)

  6. admin

    22.09.2011

    0 ↑
    0 ↓

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

    появление таких проблем от выбранной платформы практически не зависит — действуя в текущей канве через пару месяцев получите кучу "новенького" кода с аналогичными вопросами в плане поддержки и дальнейшего развития). классный реферат по теме http://www.ibm.com/developerworks/ru/library/os-php-7oohabits/ .

  7. Slay

    22.09.2011

    0 ↑
    0 ↓
    Раз тут стали сравнивать с марафоном, то у топикстартера сбилось дыхание, потому что дышал он несколько не правильно.

    nwalker.mp
    Полагаю вы увлеклись, работали без передышек, сделали неумышленно архитектурные ошибки? А теперь от кода с такими ошибками сложно отказаться, сложно его поддерживать, сложно внедрять новое?

    Если это так то возможно такие советы помогут вам правильно организовать работу над любым проектом.

    Ставьте для себя задачу и ставьте для себя сроки его выполнения.
    Уменьшайте время итерации над задачами до приемлемых сроков, так чтобы это было не в ушерб качеству кода.
    Разбивайте задачу на шаги, более мелкие итерации.
    Чем меньше времени будете тратить на итерацию, тем легче будет отказаться от кода написанного за это время, в случае если код окажется неудачным.
    Проектируйте, анализируйте, сравнивайте плюсы и минусы разных подходов до написания кода.
    7 раз подумайте 1 напишите.
    Отдыхайте и не увлекайтесь.
  8. nwalker.mp

    22.09.2011

    0 ↑
    0 ↓

    разработка кода, который удобно поддерживать, требует иного уровня подготовки, выбора стратегий и решений, нежели кодинг казуальный.

    значит, мне предстоит еще учиться и учиться. впереди Макконнелл, Фаулер, Мартин и много работы.

    появление таких проблем от выбранной платформы практически не зависит

    от платформы зависят другие результаты, которые мне не менее важны.

    SQLAlchemy позволит оптимизировать работу с БД, Erlang позволит избавиться от IPC, которое нетривиально в тестировании. к Ruby прилагается куча штучек, ускоряющих разработку, которые портированы на другие платформы весьма посредственно. Это порождает вечные муки выбора и ощущение, что счастья нет.

  9. admin

    22.09.2011

    0 ↑
    0 ↓

    вам виднее. все равно нормальное решение получается с третьего раза :)

Внимание! Это довольно старый топик, посты в него не попадут в новые, и их никто не увидит. Пишите пост, если хотите просто дополнить топик, а чтобы задать новый вопрос — начните новый.