Парадокс программиста: стиль Ватерлоо

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

Снова и снова я пытался разными способами объяснить это в этом блоге. Но я думаю, что продолжаю путаться в определениях, что, вероятно, делает его недоступным для большинства людей.

Итак, я попробую еще раз.

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

Если вы попытаетесь кодировать, составляя все более крупные списки инструкций, вы сойдете с ума задолго до того, как заставите его работать должным образом. Итак, не делайте этого.

Вместо этого сосредоточьтесь на данных. Подумайте, как она должна течь.

Сейчас он хранится где-то на диске, в какой-то базе данных. Но пользователь хочет видеть это на своем экране, завернутый в какой-нибудь симпатичный интерфейс.

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

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

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

Итак, если у вас есть такая перспектива, как вы ее применяете?

В объектно-ориентированной парадигме вы берете каждый тип данных, которые вы перемещаете, оборачиваете их в объект и туда же помещаете все маленькие функции, с которыми возитесь. Затем вы просто перемещаетесь по объектам. Это буквально взаимно однозначное сопоставление.

Запутанно то, что некоторые технологии не являются объектно-ориентированными. Но, к счастью, одним из основных факторов, повлиявших на ООП, были АТД или абстрактные типы данных. Люди, как правило, знают их как списки, деревья, стеки и тому подобное. Но это всего лишь «почти» объекты без идеологии Объекта, отпечатанной в языке программирования. То есть любой набор данных имеет некоторую структуру, которую вы должны приспособить, что неудивительно называется «структурами данных». Захватите это, и базовая механика сможет правильно хранить любой экземпляр этих данных. Запороть, а то хоть один экземпляр не влезет, придется халтурить, о чем потом пожалеете.

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

Если вы упаковываете данные вместе и создаете несколько небольших функций, которые правильно понимают и работают с этими данными и их структурой, вы можете сохранить все это вместе, эффективно «инкапсулируя» их от всего остального. Или в основном слабо определенный объект.

Итак, вы сразу же возвращаетесь к главному вопросу. Вы перемещаете данные, и вы можете делать это с объектами, структурами или на таком языке, как Go, с интерфейсами. В конце концов, это одно и то же, поскольку все это происходит из оригинальной философии ADT. Разные имена и разные языковые возможности, но все они являются частью одного и того же стиля кодирования структуры данных.

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

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

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

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

Очень редко вам нужно подумать о коде. Некоторые системы имеют небольшое ядро ​​сложности, обычно менее 10%, где им нужен действительно сложный код. Прежде чем браться за дело, лучше провести небольшое исследование, но механика проста. Получите все данные, которые вам нужны, передайте их алгоритму, надеюсь, без сохранения состояния, затем получите все выходные данные и переместите их по мере необходимости. Очень просто.

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

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

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

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

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

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