Connect with us

Программирование

Программирование открытием

Я не выступаю за запрет всех проектных документов (они могут быть полезны), но вместо этого признаю и принимаю, что некоторые люди просто думают по-другому.

Опубликовано

/

     
     

Я не делаю заметок, не составляю конспекты, не делаю ничего подобного. Я просто бьюсь над этой чертовой штукой. — Стивен Кинг

В писательском деле (особенно в художественной литературе) существует общепринятое различие между авторами, которые начинают с написания набросков, и теми, кто создает свои истории в процессе написания. По какой-то причине у нас нет такого различия в программировании, поэтому я здесь, чтобы ввести его.

Объяснение программирования открытием (Discovery Coding)

Дискавери-кодинг — это практика понимания проблемы путем написания кода, а не попытка предварительного проектирования или обдумывания. Это означает, что программист-открыватель не всегда начинает с плана, прежде чем приступить к написанию кода. Скорее, он думает о ситуации, в которой находится. Какую проблему мы пытаемся решить с помощью этого нового кода? Какие ситуации породили требования? Как взаимодействуют эти различные части системы? Только в процессе написания кода и наблюдения за его реакцией программисты-открыватели понимают и разрабатывают план дальнейших действий.

Программистов-открывателей часто считают беспорядочными и недисциплинированными. При работе с их коллегами, занимающимися планированием, может возникнуть некоторая напряженность, которая не будет правильно объяснена. Программист с планами может чувствовать себя неловко, видя бессистемный подход программиста с открытиями. С другой стороны, программист-открыватель может быть озадачен, казалось бы, неправильно подобранными по времени вопросами, которые задает планировщик.

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

Кодирование открытиями — это не проектирование снизу вверх

Программирование открытием и дизайн снизу вверх — это не одно и то же. Я не удивлюсь, если кодеры-открыватели часто склонны к дизайну «снизу вверх», а планировщики предпочитают дизайн «сверху вниз». Но это ортогональные оси. Нисходящий дизайн — это угол, под которым вы подходите к проблеме, а не процесс, с помощью которого вы пытаетесь ее понять. Представьте себе следующее: вы пишете подробный проектный документ задолго до начала разработки, в котором излагаете основные примитивы и то, как они будут сочетаться для решения проблемы. Здесь мы явно имеем дело с планировщиком, выполняющим процесс проектирования снизу вверх.

Преимущества программирования открытиями

Я считаю, что даже для планировщика кодирование с помощью открытий может принести немало пользы. Когда вы подходите к проблемам в поисках решения, очень легко начать с тех решений, которые нам наиболее знакомы. Discovery coding, по своей природе, позволяет избежать этого подводного камня. Программирование открытием не предлагает решения, поэтому код, который мы начинаем писать, направлен на то, чтобы поковыряться в системе и понять, как она работает. При этом вы заполняете свой мозг не контекстом прошлых решений или описанием решений, о которых вам рассказывали другие. Вместо этого вы понимаете ряд ограничений, которые есть у системы и которым должно удовлетворять ваше решение.

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

Инструментарий для помощи в Discovery Coding

Я не думаю, что многие инструменты сегодня разработаны с учетом программирования открытием. Такие вещи, как live программирование в работающей системе (посмотрите, как работает большинство Clojure-истов. или SmallTalk-еров), невероятно ценны для программиста-открывателя. Системы, которые позволяют вам визуализировать на лету, использовать части системы и т.д., значительно облегчают и ускоряют процесс открытия. Это тот смысл динамики (не связанный с типизацией), который, как мне кажется, мы часто упускаем из виду.

Мы должны принять программирование открытием

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

Возможно, я неправильно представляю себе текущую культурную среду (или, возможно, вы читаете это спустя годы, и культура изменилась). Возможно, программирование открытиями любят и лелеют, а конспектирование презирают. Если это так, пожалуйста, инвертируйте все вышесказанное. Надеюсь, мы поймем, что единого ответа не существует. Разработка программного обеспечения — это человеческий процесс, и не все люди одинаковы.

Источник

Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Telegram

Популярное

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: