samizdam

Писать код так, чтобы он сам себя документировал.
Давать осмысленные имена переменным и функциям, пусть длиннее, зато читабельнее.
Почитать про архитектуру, паттерны.
Рекомендую "Чистый код" Р. Мартин. Там эта тема поднимается.

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

Как тестовое задание на понимание и знание апи
1. Предложить сделать список новостей с фильтрацией по месяцу и году.
2. Вывести предыдущий элемент и следующий (можно так же на примере списка новостей)

Среднячок:
1. Это конечно же более глубокое знание АПИ и принципов работы Системы.
2. Конечно же евенты платформы.
3. Поспрашивать про оптимизацию кода при разработке на бх фреймвок.
4. Умение создать свой компонент (хотя бы по аналогии с уже созданным)

Если шоп:
5. В целом спросить про коммерс модуль системы, что в ходит в него (товары, sku, группы)
6. Интеграция с 1с.
7. Настройка оплат, складов, заказов, скидок, доставок.
8. Фильтрация и поиск по каталожику.

Задания:
На эвенты:
1. Для заполнения веб формы (из модуля форм) создать 2 доп поля, и при добавлении результата дописывать урл и название страницы с которой была отправлена.
2. Так же для веб форм реализовать "подмену" получателя, получатель будет устанавливаться полем - селектом, например поле Офис, и под каждый офис свой получатель письма.
Компонент:
1. Создать свой компонент например аккордеон или сгруппированный по разделам список. (можно поизвращаться с парамертрами :)

Ну все кто выше уровнем:
1. d7 \ ORM
2. Свои модули или сложные архитектурые решения.
3. Оптимизация хостинга \ вм под
4. Сложные интеграции

Тут тестовое задание кроме написать модулек я не придумал)) Скорее всего будет реальное портфолио из решений задач.

P.S список накатал за пару минут, не панацея, может быт деструтурирован или переосмыслен.

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

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

Например, ваше представление: "ООП удобен для бизнеса, можно разделять программу на модули" - неверно.
Модульность появилась задолго до ООП. Бизнес появился задолго до программирования, и ООП и бизнес не слишком и связаны.

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

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

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

И напоследок - полиморфизм и все другие фичи ООП - это уже следствие того, что парадигму стараются сделать максимально гибкой.
Самая главная суть ООП заключается в следующем:

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

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

Оправдано ли будет использование NodeJS в качестве бэкенда крупного приложения?

Если крупного - по нагрузкам и маленького по коду, вполне возможно. Если же предполагается крупная кодовая база, нода - это не лучшая идея.

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

Приведу несколько примеров.

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

С тестами асинхронного кода все очень плохо, вам придется обмазываться всякими proxyquire, sinon и т.д. При этом очень внимательно следить за очисткой состояния. Да, я понимаю, что моки и в других языках нужно юзать, но тот же proxyquire можно сравнить с php-шным runkit, что как бы вообще по хорошему трогать не надо, а придется. Примите также за исходную, что вы будете много времени тратить на то, что бы понять какой из тестов асинхронщины у вас сфейлился.

Рано, или поздно у вас возникнет потребность в неком DI контейнере, привычный require 'myService' уже не прокатит. Пробросы зависимостей станут источником ошибок. Если вы не будете это дело покрывать функциональными тестами много ошибок обнаружите уже на stage сервере.

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

Лука Никитин
Не проводили тест, когда по 2 сервера и на ноду и на php?

https://gist.github.com/

Можно ли писать на TypeScript под NodeJS? Вопрос о том, хорошая ли это практика?

Да, да

Смогу ли я использовать без особых проблем пакеты из npm, либо какие-то сторонние скрипты/классы написанные на js?

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

Плюсы:
- свежие фичи из спецификаций ES
- статическая типизация, а, следовательно, все плюсы, которые она даёт. если в двух словах: часть ошибок будет отлавливаться ещё до запуска и, соответственно, нужно меньше тестов
- хорошая поддержка языка всякими редакторами. IDE от Jetbrains лучше будут выдавать подсказки. И даже простые редакторы кода, например Atom, Sublime, VS Code начнут выдавать нормальные подсказки, переходить по определениям в коде, выдавать сигнатуру методов, и т.д.

Минусы:
- Нужно понять, как правильно подключать обычные js-библиотеки к проекту. В целом, это не сложно, но многие не осиливают.
- Типы "существуют" только в compile-time. На выходе обычный JS со всей его динамической природой. Если код написан плохо (например, часто используется тип any), то typescript не поможет.

А про отладку я уже говорил: с ней проблем нет. Просто нужно подключить вот эту штуку, и всё будет нормально. VS Code точно умеет подключаться к нодовскому (и хромовскому) дебагеру и будет прыгать по исходникам, а не по скомпилированной каше.