(no subject)
Jul. 31st, 2009 04:31 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
norianХорошая композиция и бенефиты
Определение хорошей композиции из курса изобразительных искусств "если убрать или изменить один из элементов, то целое изменится". Возможно, это морской пейзаж с маяком, который образует вертикаль с одной стороны, направляя взгляд и противопоставляя себя волнам. Если заменить благородный маяк на урну для мусора, картина будет означать что-то другое. Если волны заменить на пятно нефти или пляжную толпу, это также изменит впечатление от картины.
Общий смысл в том, что не должно быть чего-то, что не несёт точно определённой цели по отношению к другим элементам композиции. Художник должен сохранять контроль над смыслом картины, а если она содержит случайные кусочки, то они вызывают непредсказуемые ассоциации у зрителей и ухудшают восприятие отношений между главными элементами.
Логики, изучающие систему аксиом, сталкиваются с тем же самым. Они говорят, что система должна быть "необходимой и достаточной". Необходимость и достаточность позволяют ясно видеть природу рассматриваемого явления и гарантируют, что следствия действительно относятся к рассматриваемой области, а не являются произвольными.
К сожалению, при разработке софта часто требуется функциональность, которую создают настолько быстро, насколько это возможно. Созданная функциональность становится частью пейзажа, и все участники проекта попадают в эту ловушку. Хотя это явление и выглядит неизбежным злом, есть люди, вырвавшиеся из заколодованного круга, и с точки зрения программирования как искусства, можно показать, как они это сделали.
Основная сложность в сохранении контроля над унаследованными структурами, являются ли они особенностями процесса заказчика или древней системой индексирования, это время. Иногда это называют ценой, но редко это на самом деле цена. Это дедлайны, та суровая реальность, над которой разработчики не властны. Это нормально - надо лишь относиться к ним реалистично и решать их проблемы вместо того, чтобы использовать их как оправдания в плохом качестве продукта.
Первая линия обороны против дедлайнов заключается в прозрачной среде, без странных флагов или функций, несовместимых соглашений о вызовах, разных соглашений об именах и подобного мусора. День после чистки стоит больше дня до чистки, поэтому сначала надо провести чистку в самом начале, когда весь проект впереди. Чистку придётся делать почти в любом случае - большинство организаций помещают в репозиторий первый же код, который прошёл всё тестирование. Это неважно - сделайте очистку на этом этапе, протестируйте код и приведите его в тот вид, который позволяет всё ясно видеть.
Основная сложность на этом этапе - реалистичная оценка продолжительности очистки. Чем больше мусора, тем больший эффект от очистки, но тем больше риск, что не хватит времени. В таких случаях может помочь вопрос "насколько сложна внешняя функциональность?" - если она небольшая, то можно рассчитывать на постепенное улучшение методом последовательных упрощений, даже если не видно всего пути.
Вторая линия обороны использует экспоненциальное уменьшение сложности программ. Если упростить алгоритм, его реализация будет проще и занимать меньше кода. Чем меньше кода, тем проще видеть его структуру и уменьшить количество багов. В то же время, меньше кода означает меньше синтаксических ошибок, меньше изменений, меньше тестов. Команда разработчиков числом больше пяти через некоторое время вязнет в процессе взаимных патчей, доступ к репозиторию становится самым узким местом. Откладывать решение проблем на более поздние стадии означает заложить бомбу с часовым механизмом, которая взорвётся тогда, когда поздно будет пить боржоми. В то же время, несколько напряжённых дней, потраченных на разрешение ситуации сразу же, могут надолго восстановить процесс.
Третья линия обороны - "комната скунсов", маленький, часто изолированный исследовательский отдел, функционирующий самостоятельно, практически без контроля начальства. Это страшное оружие может использоваться опытными командами или просвещённым начальством, его работу мы рассмотрим дальше.
В эпоху индустриального строительства мы имеем дело со многими физическими объектами (например, кирпичами), которыми неудобно управлять. Вместо того, чтобы сравнивать кучи кирпича с эталонными, чтобы определить необходимое количество, мы их считаем. Этот переход от физического уровня к информационному даёт нам огромное преимущество в управлении. Когда у нас есть множество чисел о поставках, транспорте и потребностях, их надо организовать в шаблоны. Мы составляем таблицы, и переход от информационной к концептуальной абстракции опять даёт преимущество.
В такой области информационных технологий, как программирование, мы не начинаем с физического уровня и не получаем преимуществ с переходом на информационный. Мы начинаем с информационных требований и должны управлять ими при помощи информационных инструментов, в силу как хороших причин, например, для взаимодействия с заказчиками и коллегами, так и плохих, как слишком буквальное применение технологии разработки для управления информационными "кирпичами" вроде измерения производительности количеством строк кода.
Проблема в том, что мы не получаем преимуществ. Результаты обсуждения могут быть больше, чем предмет обсуждения, то есть обсуждение принесло отрицательное усиление. Мы можем получить выигрыш, только применяя новый кусок информации много раз или получая многократную выгоду от его использования вместе с другими частями.
Остаётся только одна возможность - использовать понимание, чтобы достичь преимуществ в области информации. "Комната скунсов" иногда воспринимается как отход от процесса в интересах креативности, но это совсем не так. Для такой работы нужна высокая концентрация опытных профессионалов, которые могут заменять понимание, заключённое в процессе, пониманием, заключённым в личном опыте. Это необходимое условие для "комнаты скунсов". Отход от детального процесса с его персональной защитой в виде простых определённых задач несёт неизбежный риск. Все должны понимать, что возможны ошибки, и результаты могут не соответствовать ожиданиям или противоречить существующим методам управления. Но когда это работает, это работает превосходно.
Все успешные стартапы являются "комнатой скунсов". Так же, как и провалившиеся. Скунсы могут превратить большой риск потери поддерживаемости проекта в меньший риск увеличения времени разработки, то есть в определённых ситуациях это эффективный инструмент управления рисками.
Определение хорошей композиции из курса изобразительных искусств "если убрать или изменить один из элементов, то целое изменится". Возможно, это морской пейзаж с маяком, который образует вертикаль с одной стороны, направляя взгляд и противопоставляя себя волнам. Если заменить благородный маяк на урну для мусора, картина будет означать что-то другое. Если волны заменить на пятно нефти или пляжную толпу, это также изменит впечатление от картины.
Общий смысл в том, что не должно быть чего-то, что не несёт точно определённой цели по отношению к другим элементам композиции. Художник должен сохранять контроль над смыслом картины, а если она содержит случайные кусочки, то они вызывают непредсказуемые ассоциации у зрителей и ухудшают восприятие отношений между главными элементами.
Логики, изучающие систему аксиом, сталкиваются с тем же самым. Они говорят, что система должна быть "необходимой и достаточной". Необходимость и достаточность позволяют ясно видеть природу рассматриваемого явления и гарантируют, что следствия действительно относятся к рассматриваемой области, а не являются произвольными.
К сожалению, при разработке софта часто требуется функциональность, которую создают настолько быстро, насколько это возможно. Созданная функциональность становится частью пейзажа, и все участники проекта попадают в эту ловушку. Хотя это явление и выглядит неизбежным злом, есть люди, вырвавшиеся из заколодованного круга, и с точки зрения программирования как искусства, можно показать, как они это сделали.
Основная сложность в сохранении контроля над унаследованными структурами, являются ли они особенностями процесса заказчика или древней системой индексирования, это время. Иногда это называют ценой, но редко это на самом деле цена. Это дедлайны, та суровая реальность, над которой разработчики не властны. Это нормально - надо лишь относиться к ним реалистично и решать их проблемы вместо того, чтобы использовать их как оправдания в плохом качестве продукта.
Первая линия обороны против дедлайнов заключается в прозрачной среде, без странных флагов или функций, несовместимых соглашений о вызовах, разных соглашений об именах и подобного мусора. День после чистки стоит больше дня до чистки, поэтому сначала надо провести чистку в самом начале, когда весь проект впереди. Чистку придётся делать почти в любом случае - большинство организаций помещают в репозиторий первый же код, который прошёл всё тестирование. Это неважно - сделайте очистку на этом этапе, протестируйте код и приведите его в тот вид, который позволяет всё ясно видеть.
Основная сложность на этом этапе - реалистичная оценка продолжительности очистки. Чем больше мусора, тем больший эффект от очистки, но тем больше риск, что не хватит времени. В таких случаях может помочь вопрос "насколько сложна внешняя функциональность?" - если она небольшая, то можно рассчитывать на постепенное улучшение методом последовательных упрощений, даже если не видно всего пути.
Вторая линия обороны использует экспоненциальное уменьшение сложности программ. Если упростить алгоритм, его реализация будет проще и занимать меньше кода. Чем меньше кода, тем проще видеть его структуру и уменьшить количество багов. В то же время, меньше кода означает меньше синтаксических ошибок, меньше изменений, меньше тестов. Команда разработчиков числом больше пяти через некоторое время вязнет в процессе взаимных патчей, доступ к репозиторию становится самым узким местом. Откладывать решение проблем на более поздние стадии означает заложить бомбу с часовым механизмом, которая взорвётся тогда, когда поздно будет пить боржоми. В то же время, несколько напряжённых дней, потраченных на разрешение ситуации сразу же, могут надолго восстановить процесс.
Третья линия обороны - "комната скунсов", маленький, часто изолированный исследовательский отдел, функционирующий самостоятельно, практически без контроля начальства. Это страшное оружие может использоваться опытными командами или просвещённым начальством, его работу мы рассмотрим дальше.
В эпоху индустриального строительства мы имеем дело со многими физическими объектами (например, кирпичами), которыми неудобно управлять. Вместо того, чтобы сравнивать кучи кирпича с эталонными, чтобы определить необходимое количество, мы их считаем. Этот переход от физического уровня к информационному даёт нам огромное преимущество в управлении. Когда у нас есть множество чисел о поставках, транспорте и потребностях, их надо организовать в шаблоны. Мы составляем таблицы, и переход от информационной к концептуальной абстракции опять даёт преимущество.
В такой области информационных технологий, как программирование, мы не начинаем с физического уровня и не получаем преимуществ с переходом на информационный. Мы начинаем с информационных требований и должны управлять ими при помощи информационных инструментов, в силу как хороших причин, например, для взаимодействия с заказчиками и коллегами, так и плохих, как слишком буквальное применение технологии разработки для управления информационными "кирпичами" вроде измерения производительности количеством строк кода.
Проблема в том, что мы не получаем преимуществ. Результаты обсуждения могут быть больше, чем предмет обсуждения, то есть обсуждение принесло отрицательное усиление. Мы можем получить выигрыш, только применяя новый кусок информации много раз или получая многократную выгоду от его использования вместе с другими частями.
Остаётся только одна возможность - использовать понимание, чтобы достичь преимуществ в области информации. "Комната скунсов" иногда воспринимается как отход от процесса в интересах креативности, но это совсем не так. Для такой работы нужна высокая концентрация опытных профессионалов, которые могут заменять понимание, заключённое в процессе, пониманием, заключённым в личном опыте. Это необходимое условие для "комнаты скунсов". Отход от детального процесса с его персональной защитой в виде простых определённых задач несёт неизбежный риск. Все должны понимать, что возможны ошибки, и результаты могут не соответствовать ожиданиям или противоречить существующим методам управления. Но когда это работает, это работает превосходно.
Все успешные стартапы являются "комнатой скунсов". Так же, как и провалившиеся. Скунсы могут превратить большой риск потери поддерживаемости проекта в меньший риск увеличения времени разработки, то есть в определённых ситуациях это эффективный инструмент управления рисками.
