Vector дохнут. Мой лето проработал и скончался в муках: сначала начал «сыпаться», каждый день систему восстанавливать приходилось, а через неделю вообще перестал определяться. Гугл сказал, что я далеко не один такой. При этом Vertex 3 и 4 живут и чувствуют себя прекрасно.
Надо обходиться без «если». Если не хотите превратить проект в басню «Лебедь, рак и щука», нужно вводить какие-то правила. Как пример: атрибут data-app используется для определения роли элемента (привязки событий, обращения к нему из js итд).
Бэкендщикам бэкендово, фронтендщикам фронтендово. Как вообще роли касаются бэкенда? Да и чем они сложнее для понимания, чем классы? При использовании Рельсы в Slim они добавляются гемом role-rails, в Haml — role-haml.
При тестах, опять таки, особых проблем замечено не было, особенно при использовании паттерна Page Object.
Ну а экономией миллисекунд скорости на фронте я лично не страдаю.
Переименовать функцию с современными-то IDE типа PhpStorm — гораздо легче, чем оперировать классами, на которые что-то навешено…
Чем легче-то? В чем принципиальная сложность оперирования правильно составленными классами/ролями?
Если нужно привязать несколько событий к одному элементу — это изврат какой-то, но в любом случае сделайте обертку на этими несколькими действиями, из которой по очереди вызовите нужные…
Почему изврат-то? Нам нужно, например, обрабатывать клик по кнопке и обрабатывать наведение мыши, предположим. И превращается наш элемент из
<button class=".kill-all-humans-btn" data-tooltip="Dis button killz all humanz">Don't touch!</button>
в ужасное, на мой взгляд,
<button onclick="UsefulFunctions.killAllHumans" onmouseover="Tooltips.show('Dis button killz all humanz')" onmouseout="Tooltips.hide">Don't touch!</button>
В добавок, на класс можно навешивать не только события, но и поведение вообще. Т.е. к нему можно обращаться из js-кода.
Это, конечно, красиво и очевидно, когда нам нужно привязать одно событие к одному элементу. А если нужно привязать событие ко всем дочерним элементам (например, запрос результатов поиска по изменению значений в форме), если привязывать несколько событий к одному элементу, итд, то подобный способ ИМХО превращается в боль. После переименования функции при рефакторинге, опять же, переименовывать ее во всех шаблонах.
Для разработки расширения хватит знания названий методов API. Для эффективной разработки расширения — нет, тут уже нужно знать принципы работы той части CMS, которой касаешься.
Пример не про CMS, но близкий: ORM. При наличии хорошей ORM разработчик может вообще не касаться SQL. Но если этот разработчик хочет иметь эффективную работу с БД, ему необходимо знать этот самый SQL, знать его специфику для используемой БД и знать, какой запрос генерируется каждым из методов. Я видел код людей, посылающий тонны запросов к БД только потому, что разработчик не заглядывал при работе дальше ActiveRecord. Это было ужасно, поверьте.
Заметьте, я не предлагаю всегда все писать с нуля. При достижении определенного опыта, когда написание тех или иных кусков кода будет похоже скорее на рутину, чем на создание чего-то новго, нужно переходить на уровень выше — переиспользование чужого кода (фреймворки, CMS).
Если цель — быстренько сделать сайтик с новостями и картинками — да, с этого начинать не стоит. За это вообще не нужно браться. Если цель — стать программистом, то начинать нужно именно с этого.
Когда кто-то берется что-то писать, он рано или поздно посмотрит, как это сделано у других, особенно если этот человек очень новичок. (Если он так не сделает, то гнать такого «специалиста» в хвост и гриву). И на тот момент, когда он создаст что-то работоспособное, у него уже будет багаж знаний относительно архитектуры. Конечно, писать таким образом нужно только то, на чем можно экспериментировать. Я, например, писал систему DKP для онлайн-гильдии. Конечно, выйдет далеко не идеально, и написанное вы, скорее всего, больше никогда пользовать не будете. Но знания — останутся.
А если человек с самого начала начал клепать сайты на друпале, не представляя, что у него под капотом, и как оно работает, это не программист, это сайтошлеп.
Как раз таки дико полезно, если подходить к этому правильно. Попользовался готовым решением, в качестве хобби написал свое, выкинул. Это помогает понять, как все работает изнутри. Магия — хорошо, но когда понадобится сделать что-то выходящее за рамки используемого инструмента, хотелось бы не ударить в грязь лицом. Даже написание того же расширения для CMS может обернуться катастрофой, если не знать, что конкретно днелает та или иная функция API CMS. Ровно как и использование ORM без знаний SQL.
Когда-то давно мы с коллегой писали свой фреймворк. Сейчас, оглядываясь назад, я могу сказать, что это была страшная поделка, но она внесла неоценимый вклад в мое развитие как программиста.
Зачем расширять коллекцию govnokod.ru?
Все когда-то писали говнокод, это глупо и бессмысленно отрицать. Никто не начал писать идеальный код с первого дня.
— Вся Москва завешана объявлениями о продаже поддельных документов. Надо в этой сфере наводить порядок. Необходимы системные меры по закрытию иностранных серверов
— Вся Москва каждое утро стоит в пробках. Надо в этой сфере наводить порядок. Необходимы системные меры по закрытию иностранных серверов
— Резко уменьшился удой коров за последний год. Надо в этой сфере наводить порядок. Необходимы системные меры по закрытию иностранных серверов
— На Челябинск упал метеорит. Надо в этой сфере наводить порядок. Необходимы системные меры по закрытию иностранных серверов
— Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Надо в этой сфере наводить порядок. Необходимы системные меры по закрытию иностранных серверов
Ну так была уже тема тут на Хабре о законопроекте, в котором говорится, что ростелеком есть федеральный провайдер, через которого будет идти весь трафик, а остальные провайдеры — службы доступа к ростелекому. Мрачное будущее рунета не за горами так-то.
А можно просто заказать человека и ничего никому не говорить. Ну, разве что по первому каналу со вселенской печалью на лице: «Он был великим деятелем, это большая потеря российского народа, мы все скорбим. Выражаю сочувствие родственникам и близким убитого».
При тестах, опять таки, особых проблем замечено не было, особенно при использовании паттерна Page Object.
Ну а экономией миллисекунд скорости на фронте я лично не страдаю.
Чем легче-то? В чем принципиальная сложность оперирования правильно составленными классами/ролями?
Почему изврат-то? Нам нужно, например, обрабатывать клик по кнопке и обрабатывать наведение мыши, предположим. И превращается наш элемент из
в ужасное, на мой взгляд,
В добавок, на класс можно навешивать не только события, но и поведение вообще. Т.е. к нему можно обращаться из js-кода.
Пример не про CMS, но близкий: ORM. При наличии хорошей ORM разработчик может вообще не касаться SQL. Но если этот разработчик хочет иметь эффективную работу с БД, ему необходимо знать этот самый SQL, знать его специфику для используемой БД и знать, какой запрос генерируется каждым из методов. Я видел код людей, посылающий тонны запросов к БД только потому, что разработчик не заглядывал при работе дальше ActiveRecord. Это было ужасно, поверьте.
Заметьте, я не предлагаю всегда все писать с нуля. При достижении определенного опыта, когда написание тех или иных кусков кода будет похоже скорее на рутину, чем на создание чего-то новго, нужно переходить на уровень выше — переиспользование чужого кода (фреймворки, CMS).
Когда кто-то берется что-то писать, он рано или поздно посмотрит, как это сделано у других, особенно если этот человек очень новичок. (Если он так не сделает, то гнать такого «специалиста» в хвост и гриву). И на тот момент, когда он создаст что-то работоспособное, у него уже будет багаж знаний относительно архитектуры. Конечно, писать таким образом нужно только то, на чем можно экспериментировать. Я, например, писал систему DKP для онлайн-гильдии. Конечно, выйдет далеко не идеально, и написанное вы, скорее всего, больше никогда пользовать не будете. Но знания — останутся.
А если человек с самого начала начал клепать сайты на друпале, не представляя, что у него под капотом, и как оно работает, это не программист, это сайтошлеп.
Когда-то давно мы с коллегой писали свой фреймворк. Сейчас, оглядываясь назад, я могу сказать, что это была страшная поделка, но она внесла неоценимый вклад в мое развитие как программиста.
Все когда-то писали говнокод, это глупо и бессмысленно отрицать. Никто не начал писать идеальный код с первого дня.