Принятие во внимание изучения в [закрытом] процессе разработки
5 ответов
Я думаю, как и другие, что важно иметь хорошую ментальную модель и понимать абстракции, которые вы будете использовать ... Однако иногда это не так просто, возможно, из-за недостатка времени, опыта или даже документации . Вы можете получить некоторые мысли здесь: http://www.se-radio.net/podcast/2009-06/episode-138-learning-part-development-allan-kelly Существует также гибкая методология, которая рассматривает обучение как стратегическую часть: Адаптивная разработка программного обеспечения (ASD) http://en.wikipedia.org/wiki/Adaptive_Software_Development Наконец , Я хочу упомянуть исследовательские тесты в Test Driven Development, которые могут помочь в изучении новых фреймворков http://en.wikipedia.org/wiki/Exploratory_testing .
В большинстве команд, в которых я работал, был хотя бы один энтузиаст языка. Эти ребята любят узнавать все, что можно о новых языках, и более чем счастливы делиться ими. Выясните, кто этот человек в вашей команде, и сообщите им, что вы собираетесь работать с новым языком.
Как только вы начнете, проведите проверку кода. Многие из них на небольших управляемых фрагментах кода. Энтузиаст кода сможет указать на вещи, которые лучше обрабатываются языком. Так учится вся команда.
А как насчет какой-то проверки кода или связанного с ней шага, когда какой-нибудь опытный человек может просмотреть и предложить свои предложения.
RTFM кажется пустой тратой времени, особенно если вы занимаетесь гибкой разработкой.
РЕДАКТИРОВАТЬ : Поскольку вы сказали, что «никто в команде не знает языка» ... Я не знаю, но RTFM по-прежнему кажется пустой тратой времени, чтобы попытаться «выучить весь язык», прежде чем вы начнете .
Изучите платформу, прежде чем писать рабочий код!
Часто люди просто прыгают и начинают писать свое приложение, и это превращается в беспорядок, разработчики многому учатся, а затем сожалеют о «новичках», которые они сделали, но застревают в них.
Так что моя теория состоит в том, чтобы сделать несколько всплесков и перейдем к реализации очень тонкой функции, которая проходит через все уровни фреймворка.
то есть, скажем, если бы это были веб-службы mvc / веб-службы ..... что-то, что имеет javascript -> ajax -> html -> веб-службу -> Контроллер -> Модель -> База данных.
Попросите людей просмотреть его. Не тратьте время на создание слоя фреймворка, если вы мало знаете о технологии, с которой имеете дело. Потратьте некоторое время на изучение гибкости вашей технологии (например, попробуйте несколько различных способов снятия шкуры с кошки)
Практическое обучение будет превосходить RTFM почти каждый раз, если предположить, что у вас есть команда квалифицированных разработчиков, а новая технология в некоторой степени эквивалентна тому, что команда исторически делала. Например, я мог бы видеть, как я занимаюсь веб-разработкой .NET с группой веб-разработчиков Java, но мне было бы не очень удобно заниматься веб-разработкой .NET с командой, которая была сосредоточена на приложениях VB Windows. Вы должны начать с пиков базовой функциональности, которые охватывают все слои. Лучшей практикой было бы добавить эксперта или двух в команду, чтобы помочь наставнику и руководить процессом разработки с помощью парного программирования. Для целей оценки я бы значительно сократил количество сюжетных моментов, которые я позволил бы команде предпринять в первых нескольких итерациях. КонсервативноЯ бы планировал достичь не более половины исторической скорости команды в первые несколько итераций.