Веб-разработка [закрывается]

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

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

Как знает каждый менеджер проекта, есть план и есть реальность - две разные вещи :)

Каков ваш план: завершить один единственный проект как можно быстрее, дешевле и лучше? Или, может быть, вы хотите создать качественную и счастливую команду, которая даст вам лучшие результаты и большую гибкость в будущем?

Поищите на мгновение ответ, и вам лучше сделать его твердым, прежде чем вы продолжите и столкнетесь с реальностью...

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

Вывод:

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

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

Люди, к сожалению, не машины - они издают трещащие звуки, даже когда все в порядке - если ваш лучший человек издает звук, дайте ему тизер того, что он хочет, так он все равно сделает 90% своего основного проекта.

Ответ на этот вопрос зависит от вовлеченных людей и размера проекта.

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

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

Как и в случае с большинством субъективных вопросов, это зависит от обстоятельств.

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

Стив, так трудно сказать, что лучше , если не указать конкретную цель.

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

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

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

Как говорят люди, это зависит от проекта, но то, как мы работаем, ожидается, что у каждого есть базовые навыки по всему архитектурному стеку от web front end, через java до SQL, и они берут функциональные области для работы над всем этим.

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

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

Исключения из этого правила, с которыми я обычно не связываюсь:

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

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

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

Я уверен, что когда вы попадете в такие организации, как myspace, facebook и google, у вас не может быть только одного человека, работающего над кодом.

Я думаю, что лучший способ справиться с ситуацией - это протоколировать все и объяснять, какие работы / изменения они сделали.

Например, если мой партнер работает над какой-либо функцией для моего сайта, он должен будет задокументировать и полностью объяснить изменения, которые он сделал или внедрил, а также объяснить, что делает его код и как он интегрируется в остальную систему. .

Таким образом, когда я прихожу, я вижу, что он внес изменения в систему в классе Input, и он объяснил, как он защитил одну из последних XSS-атак или что-то еще.

Итак, когда я читаю Его код, я уже знаю:

• Какова цель кода.
• Как код внедряется в остальную часть системы.
• Зачем это было необходимо.
• Его основное назначение и функции.

Основная часть работы в команде - это общение, поэтому наличие такой системы, которая будет обеспечивать общение, будет жизненно важным.

Люди, как правило, отлично работают в одиночку, потому что в общении нет необходимости. но по мере того, как вы растете и расширяетесь, вы должны иметь возможность структурировать свое приложение и команду, чтобы убедиться, что у вас может быть 20 человек, занимающихся разными делами, но все они знают, что происходит в приложении, поскольку они видят «Журнал изменений» как таковой.

Я считаю, что команда лучше, чем один человек.

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

Я очень предпочитаю функциональность по мере развития. В основном потому, что если вы закончите 80% функций, у вас будет работающее приложение, но если вы закончите 80% слоев, у вас ничего не останется.

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

Послойная разработка позволяет получить максимальную отдачу от экспорта, но вы сталкиваетесь с некоторыми опасностями.Если ваш специалист по базе данных не понимает требований к интерфейсу, ваша БД может быть организована таким образом, что от внешнего интерфейса требуется выполнение множества запросов. Если ваше промежуточное программное обеспечение разработано объектно-ориентированным способом, у вас может быть «несоответствие импеданса» с вашей базой данных или внешним интерфейсом. Вы также можете закончить тем, что что-то построено на неправильном уровне, потому что «мы не можем дождаться обновления промежуточного программного обеспечения, поэтому мы просто сделаем это во внешнем интерфейсе».

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