Как я могу убедить члена команды использовать веб-фреймворк? [закрыто]

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

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

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

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

Как группа, мы решаем, какие технологии использовать при реализации веб-сайта; в частности, использовать ли PHP-фреймворк (Code Igniter) или нет.

Я выступаю за, ссылаясь на:

1. Не изобретать велосипед
2. Хорошо написанная и проверенная база кода для работы с
3. Начало (крайний срок ближе, чем хотелось бы)
4. Скорость развития
5. Надежные и поддерживаемые шаблоны проектирования и передовой опыт

Он выступает за работу так, как он привык:

• Запись одноразовых функций в «библиотечный» файл так, как он ему нужен
  • Функции для доступа к данным и рендеринга этих данных на странице, получения / настройки в и из сеанса и получения / публикации данных и т. Д.
• Наличие 1 файла на страницу (что не приводит к разделению проблем между управлением, представлением и данными)

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

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

Я могу понять, почему он приводит эти аргументы, но я не согласен с его «отсутствием заботы о ремонтопригодности» и его «пренебрежением к хорошему дизайну» или даже разделением интересов. Тем не менее, я подозреваю, что он никогда не изучал шаблоны проектирования, поэтому я не знаю, насколько эффективной будет демонстрация того, почему его метод может оказаться неприемлемым.

Я хочу начать этот проект, но я не хочу делать это без учета всего, что я узнал за эти годы. Как я уже говорил, здесь нет возможности получить звание, и другие члены команды не хотят участвовать. Должен ли я просто отступить и сделать все по-своему? Он слишком упрям ​​и неопытен, чтобы знать лучше? Или я здесь упрямый?

TL; DR Неопытный член команды упрям, как я могу победить его?

Вы не сможете убедить его в этом. Это называется эффектом Даннинга-Крюгера . Он слишком невежествен, чтобы знать, чего не знает, и слишком боится потерять то, что он называет преимуществом.

Когда вы не можете достичь консенсуса, вы должны вместо этого прийти к компромиссу. Может быть, вы можете разделить работу так, чтобы его изучение основ было минимальным. Может быть, у вас есть какое-то «замысел», когда вы каждый делаете это по своему усмотрению в течение пары недель, а затем команда голосует, какой из них лучше. Может быть, вы можете привлечь вашего спонсора профессора или кого-либо, кто участвует в решении этой проблемы.

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

Другим аргументом может быть конкретное измерение затрат на разработку / обслуживание. Я полагаю, что разработчик, хорошо разбирающийся в CodeIgniter, может развиваться быстрее, чем ваш коллега, пишущий все эти проприетарные функции сам. Это может быть продемонстрировано, если вы и он создадите одинаковую веб-страницу - вы с CodeIgniter, он по-своему - и измерите время до завершения. Затем внесите ряд изменений / расширений в страницы, снова измеряя время до завершения. Конечно, спецификация должна быть подготовлена ​​кем-то независимым от вас обоих, чтобы сражаться на нейтральной территории.

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

Конечно, когда вы испытываете нехватку времени, у вас может не быть возможности остановиться и сделать такие измерения. Таким образом, вы, вероятно, хотите быстрое решение этой дилеммы. Попробуйте убедить других членов команды (например, попросив их прочитать предстоящие ответы на ваш пост здесь :-), чтобы оказать на него некоторое групповое давление. В конце концов, если он действительно не может быть убежден, вы можете разделить проект на две части, одну для него и - в идеале - одну для остальной части команды, используя CodeIgniter. Сосредоточьтесь на том, чтобы делать все, что в ваших силах, и пусть он делает все, что хочет. Результаты, вероятно, будут говорить сами за себя.

Я чувствую, что вам нужно привлечь 3 других товарищей по команде. Вы оба должны представить свои аргументы им и объяснить им, чтобы они поняли. В конце дня им также придется работать с этой кодовой базой. И если все равны, то они должны сказать, над чем они хотят работать.

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

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

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

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

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

А для неопытных членов команды их шансы на трудоустройство / лучшую занятость возрастут с такой структурой, как CodeIgniter, в их резюме (на самом деле это знание оправдывает это в их резюме).