Ember — это сложно, часть 2: условности — это хорошо

Ember — это сложно, часть 2: условности — это хорошо

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

Большинство вещей, которые стоит делать в жизни, сложны

Я вижу две ситуации при выборе технологии: личный проект/рост и корпоративные команды, работающие над продуктом своей компании.

Если вы сидите в первом лагере, кто-то ищет роста или основы для нового проекта, я говорю: «Не позволяйте горе изучения чего-то нового пугать вас и не позволяйте негативу других людей влиять на вас». негативные разговоры и люди, которые находят причины винить кого-то другого вместо того, чтобы признать свои недостатки.

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

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

Вы хотите тратить свое время на создание этих условностей на своем рабочем месте?

Как разработчики программного обеспечения, у нас нет возможности отказаться от соглашений, с которыми мы работаем каждый день. мы вольно или невольно строим их каждый день. Объявление списка библиотек Javascript, которые вы используете, не создает хороших соглашений. Это все равно, что покупать все инструменты и расходные материалы без плана.

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

Итак, определите, что должны охватывать ваши планы, и спросите себя: «Хочу ли я создать свои собственные соглашения или мне следует потратить время на изучение фреймворка, который сделал это за меня?» Пожалуйста, сделайте одно или другое, в противном случае каждый участник вашей команды будут иметь свои собственные соглашения, и ваше приложение станет больше похоже на ужасные спагетти, которых мы все боимся.