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

  1. Ведите ежедневный журнал, чтобы отслеживать изменения и то, почему они необходимы

Я забуду, почему я иногда что-то делал всего через 10 минут после этого. Я не помню большинство решений на следующий день. Даже серьезные дизайнерские решения, когда я изменил структуру данных или большие части кода, я не буду помнить слишком долго после того, как внесу изменение. Журнал помогает мне не повторять те же ошибки снова в будущем - когда я могу задаться вопросом: «Хм, а почему я просто не сделал это?» Я просматриваю журнал и вспоминаю: «Ой, вот почему». Фактически, я считаю, что журнал дизайнера должен быть таким, как и ожидалось в проекте, поскольку файл README.md находится на GitHub. По сути, это карта, по которой каждый может проследить, почему структура устроена так, как она есть, и почему какой-то другой подход не так хорош. Это не должно быть сложным процессом. Просто поставьте запись с отметкой даты и времени и объясните в своих мыслях, что вы делали или думали сделать в тот день.

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

3. Промедление усугубляет ситуацию.
Временное построение чего-то плохого, или невыполнение правильных тестов, или знание, что может быть проблема, но все равно кодирую, пока вы не столкнетесь с ней. В данный момент кажется легким просто сосредоточиться на достижении прогресса. Но часто это прогресс по неправильному пути, и хотя вы можете чему-то научиться, делая это, часто в вашей голове быстрее проигрывается, будет ли что-то работать или нет. Это может показаться небольшой проблемой - «эта функция не является референциально прозрачной, она неявно зависит от этого изменяемого состояния, я просто запомню это пока». Через несколько часов вы уже по колено в отладчике, преследуя неуловимое состояние паники. Не могли бы вы потратить время на то, чтобы исправить эту мелочь сейчас? Или позже, после того, как заново открыли это через какое-то негативное столкновение, которое прокатилось по вашему коду.

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

4. Создавая что-то большое, начинайте с конца.
Часто нам нравится откладывать важные дизайнерские решения, потому что просто начать кажется намного проще. Очень сложно учесть все будущие препятствия и компромиссы, которые конкретное решение будет иметь в отношении дизайна. Если вы наткнетесь на эту стену, напишите имитацию интерфейса, который пользователь может использовать для вашей системы. Например, если вы создаете библиотеку графов, напишите, как пользователь будет определять, строить и выполнять операции, которые библиотека предоставляет с этим графом. Будут ли эти операции методами графа или узлов графа? Будут ли эти методы принимать идентификаторы узлов в качестве параметров или ссылок на объекты узлов? Интерфейс к вашей системе - это сумма всех ваших дизайнерских решений до этого момента, поэтому, если вы работаете в обратном направлении, вы можете сделать вывод, какие эти решения должны быть основаны на желаемом результате.

let graph = Graph::new();
let n = Node { x: 5 };
graph.add_node(n);
n.is_ancestor_of(m);
// Vs
graph.is_ancestor_of(n,m);

Бонусный принцип

5. Не забывай дышать

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