Когнитивные компетенции

Фактором, позволяющим развить как технические, так и когнитивные навыки, является открытость кода и сопровождающих материалов. Код, его документация, спецификации архитектуры могут служить хорошим наглядным пособием по созданию сложных продуктов. У проектов с долгой историей наверняка есть оригинальные примеры решения тех или иных вопросов - как небольших технических нюансов, так и комплексных архитектурных проблем.
Не следует забывать, что открытая разработка подразумевает не просто публичную доступность кода, но и открытость самого процесса создания ПО. В частности, в свободном доступе обычно находятся архивы почтовых рассылок разработчиков, системы отслеживания ошибок, системы контроля версий с полной историей модификаций исходного кода, документация и многие другие артефакты.
Добавьте к этому различные специализированные сайты, форумы, на которых пользователи совместно с разработчиками решают возникающие проблемы, и другие онлайн-ресурсы и вы получите огромную базу знаний, охватывающую все аспекты программной инженерии.
Эта база постоянно меняется и по своей природе имеет распределенный характер. Но поскольку она доступна через Интернет, то все ее материалы индексируются поисковыми машинами и при необходимости легко находятся. И если еще лет десять - пятнадцать назад за решением многих вопросов разработчики (по крайней мере под Windows) первым делом обращались к библиотеке MSDN, распространявшейся на нескольких дисках, то теперь гораздо проще набрать необходимый запрос в поисковой машине. Благо тот же MSDN сейчас доступен онлайн и тоже является частью всемирной базы знаний.
Справедливости ради стоит отметить, что код и структура некоторых открытых проектов могут служить примером того, как не надо писать программы; однако и изучение неудачных практик тоже очень полезно, главное - понимать, почему они неудачны.
Помимо ретроспективного анализа, полезно и наблюдение за текущей жизнью проекта. Одно дело - читать архивную переписку про выбор того или иного решения и совсем другое - наблюдать такое общение вживую и даже иметь возможность принять в нем участие, внося свои предложения и получая о них аргументированное мнение.
В заключение хотелось бы отметить, что при наблюдении за разработкой и проведением ретроспективного анализа полезно сопоставлять декларируемые планы и их реальное воплощение. Не секрет, что число ИТ-проектов, заканчивающихся полной или частичной неудачей, достаточно велико. Для того чтобы избежать таких провалов, полезно анализировать опыт предшественников, искать причины, приведшие к неудаче, а также пути их решения и предотвращения.
Для коммерческих проектов провести такой анализ вряд ли получится, даже если разработчики признают, что проект завершился провалом либо результат имеет серьезные недочеты. А вот при открытой разработке скрыть что-то вряд ли получится - как говорится, «все ходы записаны».
С другой стороны, во многих открытых проектах часто нет четкого планирования, ведь многие разработчики трудятся над ними в свободное от основной работы время, и количество часов, отводимых на проект, может серьезно меняться в зависимости от внешних факторов. Как следствие, отставание от желаемых сроков обычно связано с недостатком времени.
Однако в крупных проектах (особенно поддерживаемых коммерческими компаниями или некоммерческими фондами) планирование разработки достаточно формализовано, и анализ процесса может помочь выявить менее тривиальные проблемы, как то: организационные промахи, неверные оценки сложности задач и количества ресурсов, или архитектурные недочеты.
Не следует забывать, что открытая разработка подразумевает не просто публичную доступность кода, но и открытость самого процесса создания ПО. В частности, в свободном доступе обычно находятся архивы почтовых рассылок разработчиков, системы отслеживания ошибок, системы контроля версий с полной историей модификаций исходного кода, документация и многие другие артефакты.
Добавьте к этому различные специализированные сайты, форумы, на которых пользователи совместно с разработчиками решают возникающие проблемы, и другие онлайн-ресурсы и вы получите огромную базу знаний, охватывающую все аспекты программной инженерии.
Эта база постоянно меняется и по своей природе имеет распределенный характер. Но поскольку она доступна через Интернет, то все ее материалы индексируются поисковыми машинами и при необходимости легко находятся. И если еще лет десять - пятнадцать назад за решением многих вопросов разработчики (по крайней мере под Windows) первым делом обращались к библиотеке MSDN, распространявшейся на нескольких дисках, то теперь гораздо проще набрать необходимый запрос в поисковой машине. Благо тот же MSDN сейчас доступен онлайн и тоже является частью всемирной базы знаний.
Справедливости ради стоит отметить, что код и структура некоторых открытых проектов могут служить примером того, как не надо писать программы; однако и изучение неудачных практик тоже очень полезно, главное - понимать, почему они неудачны.
Помимо ретроспективного анализа, полезно и наблюдение за текущей жизнью проекта. Одно дело - читать архивную переписку про выбор того или иного решения и совсем другое - наблюдать такое общение вживую и даже иметь возможность принять в нем участие, внося свои предложения и получая о них аргументированное мнение.
В заключение хотелось бы отметить, что при наблюдении за разработкой и проведением ретроспективного анализа полезно сопоставлять декларируемые планы и их реальное воплощение. Не секрет, что число ИТ-проектов, заканчивающихся полной или частичной неудачей, достаточно велико. Для того чтобы избежать таких провалов, полезно анализировать опыт предшественников, искать причины, приведшие к неудаче, а также пути их решения и предотвращения.
Для коммерческих проектов провести такой анализ вряд ли получится, даже если разработчики признают, что проект завершился провалом либо результат имеет серьезные недочеты. А вот при открытой разработке скрыть что-то вряд ли получится - как говорится, «все ходы записаны».
С другой стороны, во многих открытых проектах часто нет четкого планирования, ведь многие разработчики трудятся над ними в свободное от основной работы время, и количество часов, отводимых на проект, может серьезно меняться в зависимости от внешних факторов. Как следствие, отставание от желаемых сроков обычно связано с недостатком времени.
Однако в крупных проектах (особенно поддерживаемых коммерческими компаниями или некоммерческими фондами) планирование разработки достаточно формализовано, и анализ процесса может помочь выявить менее тривиальные проблемы, как то: организационные промахи, неверные оценки сложности задач и количества ресурсов, или архитектурные недочеты.
Другие новости по теме:
- Участие в свободном проекте
- Программы вовлечения студентов
- Социальные компетенции
- Технические компетенции
- Свободные проекты
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии к данной публикации.
Посетители, находящиеся в группе Гости, не могут оставлять комментарии к данной публикации.