Гибкая система, но вот магический bizrul в виде php строки кода, который явно в eval уходит, немного покоробил. Вместо него напрашивается анонимная функция, но я думаю ребята во 2 версии это поправят.
У меня обфускатор получился не более 80-100 строк кода. он, конечно, не идеален, но решает маркетинговые задачи не хуже готовых коробочных. учитывая, что при желании любой обфусцированный код можно деобфусцировать, а для сторонних решений есть уже готовые деобфускаторы, то простой обфускатор, использующий токинайзер более чем не плох:)
Еще одна возможность, которую обеспечивает токинайзер — написание простого обфускатора кода.
Так же, есть мысль использовать его для анализа качества сторонних решений для коробочного продукта. Например, можно выявить, что разработчик из модели пытается обратиться к контроллеру или из контроллера напрямую взаимодействовать с бд (неймспейсы очень помогают в этом).
После обновления с 5 до 6 весь код в цепочном стиле подсвечивается не валидным, рефактринг такого кода тоже перестал работать. Всей командой не можем перейти с 5 на 6 из-за этой критичной баги. youtrack.jetbrains.com/issue/WI-15903
Надеюсь вы ее поправите как можно быстрее.
PS. других претензий к шторму нет — лучшая IDE на мой вкус
Согласен, такими темпами личное присутствие при общении с родными начнут считать ретроградством. А зачем, если есть скайп и придумают какие-нибудь гаджеты — эмуляторы к нему?
Что это за друзья, если они не могут встретиться и лично поговорить о жизни, это же намного приятнее.
Передача изображения человека и его голоса никогда не заменят личного присутствия. Ну не буду я рассказывать о своих проблемах другу по скайпу, если есть возможность встретиться лично.
Есть даже выражение «это не телефонный разговор» — или оно уже тоже устарело? )
… и его антогонист: Дарт-Продуман по несколько месяцев пишет прототип какой-либо простой фичи, усложняя и раздувая сложность реализации до вселенских масштабов. Пишет 100500 абстракций «на всякий случай». Прототип обычно готов, но фича уже не актуальна.
Написать идеальный код сразу (да и со временем) не возможно, но возможно написать тестируемый код. Если код возможно протестировать и эти тесты для него написаны, то код уже близкий к идеалу, так как его можно рефакторить и не бояться что отвалится пол системы.
В том то и дело, что обычно хреновый код в долгий ящик кладут (работает — не трогай!), а код который покрыт тестами он «живой», он дышит…
Ну да, главное чтобы все понимали что это только прототип. И не надо его завтра выкладывать в продакшн, хоть он и работает на первый взгляд =)
А вообще, суровая реальность в том, что хороший проект делается со второго раза, ну или уж точно не с первого. Первый вариант — обкатка идеи, сбор требований и анализ ошибок. Потом все переписывается правильно.
> Допустим мы хотим проверить, насколько удобно воспользоваться API некого, возможного партнёра
В этом случае проблем не вижу, в песочнице на дев-сервере попробовать можно и без TDD.
Хотя, я не понимаю как вы убедитесь что оно работает как вы ожидаете. Ручками будете API методы вызывать и сверять с ожидаемым результатом? А если завтра обновленное API партнера вместо ожидаемого графика вам пришлет котиков?
Как вы об этом узнаете? От клиентов? Как раз-таки в этом случае стороннего API без нормальной архитектуры и TDD вы далеко не уедете.
> К некой дате нужно выпустить некий промо(викторина/розыгрыш), который день покрутится, а после будет забыт и удалён.
Если считаете что это действительно простая задача и не требует архитектуры и TDD, то можете их не использовать.
Только помните: ничего не бывает более постоянного чем временное.
Тема раскрыта не до конца. Рассматривается только суровая реальность написания кода для стороннего заказчика.
Если заказчик — сама компания в которой ты работаешь (например, какой-нибудь SAAS) и поддерживать код и архитектуру, которую ты пишешь сейчас тебе предстоит годами, то я думаю вопрос о возможности говнокода, отказа от TDD и хороших практик тут вообще стоять не должен.
Да, чудес не бывает(
Тут важна совокупность инструментов и процессов. Рефакторинг должен быть постоянным процессом и его нельзя откладывать «на потом».
А чтобы его не откладывать на потом, нужно его не бояться. А не бояться возможно только при максимальном покрытии кода тестами.
А это чаще всего чудеса, особенно на проектах, доставшихся в наследство.
Ну практически все что вы описали может делать хорошая IDE'шка, причем намного удобнее «разруливать» конфликты, наблюдая непосредественный контекст вызова.
Вообще, таким образом можно применить лишь очень ограниченный набор простых рефакторингов (Rename Class / Method и т.п.). Что-то более сложное, например «выделение класса», «замена кода типа» все равно придется вручную разруливать ибо страшно это доверять скрипту, даже с тестами…
Если необходимо раздать все 500 призовых билетов в какой-то актуальный срок, когда не известно сколько вообще людей будут участвовать в лотерее, то можно действовать так:
— берем промежуток времени, за который планируется раздать 500 билетов (для простого примера 100 часов),
— делим его на маленькие промежутки (для простого примера 1 час),
— в час у нас должны выйграть 5 билетов, раздаем их первым 5 счастливчикам (проверяя наличие кода в базе и помечая код как использованный),
— если счастливчиков было меньше 5 (например 2), то в следующий час раздаем 7 билетов и так далее.
Рандомность создает сам участник, попадая или не попадая в нужный промежуток времени )
Эх, если бы CommerceML был бы форматом, проблем бы не было!
Сейчас же форматом его назвать не возможно, так нет схемы и описания. Точнее она есть, но давно не соответствует тому что отдает 1C(
То что отдает 1С — это просто XML некого формата (спасибо хоть что well-formed), которая меняется / дополняется от версии к версии, что разрывает мозг разработчикам коробочных решений, заставляя их городить костыли.
Так же, есть мысль использовать его для анализа качества сторонних решений для коробочного продукта. Например, можно выявить, что разработчик из модели пытается обратиться к контроллеру или из контроллера напрямую взаимодействовать с бд (неймспейсы очень помогают в этом).
Ждем 6.0.1
Надеюсь вы ее поправите как можно быстрее.
PS. других претензий к шторму нет — лучшая IDE на мой вкус
Что это за друзья, если они не могут встретиться и лично поговорить о жизни, это же намного приятнее.
Передача изображения человека и его голоса никогда не заменят личного присутствия. Ну не буду я рассказывать о своих проблемах другу по скайпу, если есть возможность встретиться лично.
Есть даже выражение «это не телефонный разговор» — или оно уже тоже устарело? )
Дарт-Продуман по несколько месяцев пишет прототип какой-либо простой фичи, усложняя и раздувая сложность реализации до вселенских масштабов. Пишет 100500 абстракций «на всякий случай». Прототип обычно готов, но фича уже не актуальна.
В том то и дело, что обычно хреновый код в долгий ящик кладут (работает — не трогай!), а код который покрыт тестами он «живой», он дышит…
А вообще, суровая реальность в том, что хороший проект делается со второго раза, ну или уж точно не с первого. Первый вариант — обкатка идеи, сбор требований и анализ ошибок. Потом все переписывается правильно.
В этом случае проблем не вижу, в песочнице на дев-сервере попробовать можно и без TDD.
Хотя, я не понимаю как вы убедитесь что оно работает как вы ожидаете. Ручками будете API методы вызывать и сверять с ожидаемым результатом? А если завтра обновленное API партнера вместо ожидаемого графика вам пришлет котиков?
Как вы об этом узнаете? От клиентов? Как раз-таки в этом случае стороннего API без нормальной архитектуры и TDD вы далеко не уедете.
> К некой дате нужно выпустить некий промо(викторина/розыгрыш), который день покрутится, а после будет забыт и удалён.
Если считаете что это действительно простая задача и не требует архитектуры и TDD, то можете их не использовать.
Только помните: ничего не бывает более постоянного чем временное.
PS. Во всем нужен здравый смысл и мера
Если заказчик — сама компания в которой ты работаешь (например, какой-нибудь SAAS) и поддерживать код и архитектуру, которую ты пишешь сейчас тебе предстоит годами, то я думаю вопрос о возможности говнокода, отказа от TDD и хороших практик тут вообще стоять не должен.
Тут важна совокупность инструментов и процессов. Рефакторинг должен быть постоянным процессом и его нельзя откладывать «на потом».
А чтобы его не откладывать на потом, нужно его не бояться. А не бояться возможно только при максимальном покрытии кода тестами.
А это чаще всего чудеса, особенно на проектах, доставшихся в наследство.
Вообще, таким образом можно применить лишь очень ограниченный набор простых рефакторингов (Rename Class / Method и т.п.). Что-то более сложное, например «выделение класса», «замена кода типа» все равно придется вручную разруливать ибо страшно это доверять скрипту, даже с тестами…
— берем промежуток времени, за который планируется раздать 500 билетов (для простого примера 100 часов),
— делим его на маленькие промежутки (для простого примера 1 час),
— в час у нас должны выйграть 5 билетов, раздаем их первым 5 счастливчикам (проверяя наличие кода в базе и помечая код как использованный),
— если счастливчиков было меньше 5 (например 2), то в следующий час раздаем 7 билетов и так далее.
Рандомность создает сам участник, попадая или не попадая в нужный промежуток времени )
Кинотеатр заполнен, задача выполнена.
Сейчас же форматом его назвать не возможно, так нет схемы и описания. Точнее она есть, но давно не соответствует тому что отдает 1C(
То что отдает 1С — это просто XML некого формата (спасибо хоть что well-formed), которая меняется / дополняется от версии к версии, что разрывает мозг разработчикам коробочных решений, заставляя их городить костыли.