Outsourcing stories

Наткулся сегодня на пост c размышлениями о пользе статической типизации для ограничения ущерба, который может быть нанесен проекту неквалфицированным и/или не заботящимся о качестве программистом. Читать здесь: Антиметапрограммирование

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

1. обучить его
2. избавиться от него

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

Вредные решения

1. Языки со статической типизацией, проверяемыми исключениями и прочей защитой от дурака — вся команда пишет медленее, чтобы худшие разработчики наносили меньше вреда. Общий баланс будет почти всегда отрицательным, потому что от приведения языка к наименьшему общему знаменателю лучшие разработчики страдают больше всех, а выгода невелика и мало зависит от навыка.

2. Запрет сложных решений (например, метапрограммирования) стандартом кода в рамках конкретной команды. Опять-таки, мы отнимаем мощный инструмент у лучших разработчиков чтобы снизить шансы худших отпилить себе ногу по неосторожности. Ущерб будет больше положительного эффекта

Полезные решения

1. Автоматическая проверка кода (с помощью *lint и других инструментов такого рода) — небольшие дополнительные затраты времени на каждый коммит, позволяющие снизить количество ошибок определенных типов. Здесь мы имеем дело с небольшим выигрышем, обеспеченным еще более незначительными затратами, общий эффект положительный.

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

В следующий раз я постараюсь проиллюстрировать свои предварительные выводы цифрами и напишу о неоднозначности пользы от юнит-тестов.

Гвидо ван Россум окончательно выбрал Mercurial в качестве системы контроля исходного кода для разработки Python. Оригинал новости

Что ж, как я писал в комментариях про git, можно ожидать существенного расширения экосистемы mercurial за счет связанных с python проектов. Скорее всего, эффект будет не меньший, чем от перехода Ruby on Rails на git. Теперь надо внимательно следить за Django, SQL Alchemy и pygtk — многое зависит от того, на что перейдут они.