Alan Carter - The Programmers Stone (Программистский камень)

Дзенская притча говорит о мудром монахе, пришедшем к старому учителю. Он вошел в комнату учителя и сел перед ним. «Когда ты входил, с какой стороны двери ты оставил свой посох?» — спросил учитель. Монах не знал. «В таком случае, ты потерял свой Дзен».

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

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

Вы можете разворачивать только часть вашего плана, над которым вы работаете. Вот как можно спланировать изменения некоторой программы в своей голове:

1. Идентифицировать все файлы, которые включают функции:

ModelOpen(),

ModelRead(),

ModelWrite(),

ModelClose().

2. Отключить контроль версий этих файлов.

3. Внести изменения.

3.1. Изменить modread.c

3.1.1. Исправить ModelOpen()

3.1.2 Исправить ModelRead()

3.1.3. Исправить ModelWrite()

3.1.4. Исправить ModelClose()

3.2. Изменить appfile1.c

3.3. Изменить appfile2.c

4. Обратно включить контроль версий

5. Перекомпилировать

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

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

3.1.5. Разобраться со всеми заголовочными файлами:-(

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

Нам не нужно помнить, в какое мусорное ведро мы выбросили стаканчик из-под выпитого утром кофе, чтобы иметь полное понимание, где мы находимся в нашей организованной работе. Вместо этого мы можем проникнуться духом TQM и организовать самих себя с полным осознанием того, что мы делаем. Если мы это сделаем, проявятся все обычные преимущества от обдумывания того, что мы делаем. Мы сможем увидеть возможности автоматизации скучного набора текста с помощью скриптов и макросов, а в рамках Персонального Послойного Процесса (PLP) мы всегда можем задать вопрос: «Как бы я мог отменить это действие»; это то, что отличает от людей, которые случайно стирают свой код (удалив по ошибке файл) и которым приходится два часа ждать администратора, чтобы восстановить этот файл со сделанной ночью резервной копии.

И, в качестве последнего комментария этого раздела, скажем, что в условиях профессиональной инженерной среды часто нам нужно использовать PLP для управления сложностью даже простейшей работы. Ритуализация PLP может стать гипнотической. Чтобы выдержать пропорции, всегда спрашивайте себя, не хватит ли 30 секунд, чтобы завершить эту работу, и если ее можно просто сделать, не теряйте время на выполнение ритуалов. Всегда делайте резервную копию!

Мы описали центральную проблему проектирования программного обеспечения как нахождение оптимальной карты взаимосвязей между проблемой и семантикой системы. Мы также обсуждали деятельность, которую обычно называют «написание документов», как выполнение необходимой работы и отражение ее результатов в документе. Итак, что входит в выполнение работы, но не показывается в документе? Это нечто связано с поиском оптимальной карты взаимосвязей.

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

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

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

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