Обсуждение

plz...

Да, статья Донского по ссылке не показывается. Нашлась через печатную версию http://www.polit.ru/science/2008/08/20/programmist_print.html Есть опыт в поддержку "стильного" подхода. В 2004 году выбрали Lua в качестве языка для написания элементов игровой логики в новом проекте. Простенький динамический язык, легко интегрируется в систему и переносится на другие платформы (XBox). Но "тусовки" с полезной культурой программирования для этого языка не существует (в отличие, например, от Python). В результате такая культура была создана в рамках отдельно взятой компании. Написали свой полноценный отладчик (в виде плагина к Visual Studio), дополнительный препроцессор. Постепенно эволюционировали методики программирования для AI, игровой механики и логики пользовательского интерфейса. А ребята из скриптовиков стали классными программистами, без привязки к языкам или технологиям.

Ссылка работает. Сайт Полит.ру иногда не успевает внутри себя договориться, и сообщает об отсутствии страницы. Ткните в ссылку несколько раз: текст появится. По крайней мере, я воспроизвел так и отсутствие страницы, и ее присутствие. http://polit.ru/science/2008/08/20/programmist.html -- на всякий случай повторю ссылку тут еще раз (чтобы не искать ее в тексте).

Ссылка работает, там сайт тормозит и глючит. Я воспроизвел и отсутствие страницы по своей ссылке, и присутствие оной. Вот-вот. Я сегодня говорил с Донским. Он подтвердил и усилил слова Кея: если проект большой (заведомо более одного года), то выгодно делать собственный инструментарий. Если маленький -- то пользоваться библиотеками и фреймворками.

По поводу фреймворков/своего инструментария - мой опыт, такой что если намечается серия интеграционных проектов, даже коротких (несколько недель по плану), то нужно иметь свой инструментарий. Иначе две-три недели легко растягиваются до полгода и больше (с доделками/переделками). И каждый проект - это сплошной геморрой и нервяк (знакомый сейчас так "трудиться"). Конечно над инструментарием нужно поработать заранее. Причем тут дело в отличии реальной и воспринимаемой (perceived) сложности софта: клиенты и менеджемент думают, что там работы на две-три недели, а при реальном программировании вылезает куча несостыковок и вопросов. А поскольку надо уложиться в "план", то их закрывают "заплатами". Наличие же своего инструментария, означает, что основные проблемы заранее продуманы и решены. Тогда реальная сложность гораздо ближе к воспринимаемой, и работы там действительно на две-три недели. При этом, чтобы обдумать и решить проблемы нужно время, чтобы банально мысли в голове уложились, а тут две-три недели маловато будет.

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