Spiiin's blogНе думать о методе достижения цели. Держать в голове не метод, а цель. Соответственно, чтобы так писать, нужен набор знаний в предметной области, чтобы решения не выдумывались, а были отработаны. “Если пытаешься понять код - ты уже проиграл”.
Не чинить код. Как только что-то не работает - выбрасывать его и решать проблему другим способом. Как можно более простым.
Минимально использовать наследование. По возможности стараться держать в коллекциях однородные объекты. Рефакторить по мере необходимости - дублирование кода вполне допускается, но с рассчетом, что его можно будет просто удалить, когда потребуется. По мере “раскручивания” кода, появляются общие методы, которые затем постепенно выносятся в классы/модули/другие сущности. Если потребуется. Вполне возможно, что лучше, что такие сущности и не будут нужны нигде, кроме как в одном месте, тогда и нет смысла их плодить.
Использование только известных инструментов. Данный стиль не предполагает изучение чего-то, а только быстрое получение результата. Если вдруг возникает возможность ускорить достижение результата за счет использование незнакомой библиотеки - то только, когда библиотека предоставляет элементарный интерфейс для решения задачи. В идеале - одной строкой кода.]
Следить за временем разработки каждой части вплоть до минут, чтобы после окончания проанализировать, на что расходуется больше всего.
Максимально быстрое создание прототипов всего. Потом постепенная замена кусков прототипа на то, что уже как-то работает (но работает). Любая модификация того, что уже работает ведет к проверке, что ничего не сломалось, потому что любая ненайденная вовремя поломка - конец.
Ставить удобство чтения и представления кода в голове выше, чем всё остальное. Использовать максимально декларативные средства. Наверно, здесь важен также выбор языка. Всё объявляется максимально локально, на максимально закрытом уровне инкапсуляции, кроме самых базовых структур. По возможности проектировать так, чтобы в основании было несколько простых структур данных и много функций оперирующих ими, чем много разнообразных структур и мало функций. Это - приближение к особенностям мышления, в голове проще оперировать малым набором существительных и множеством глаголов, чем наоборот. “Лучше иметь 100 функций, оперирующих с одной структурой данных, чем 10 функций оперирующих с 10 структурами данных.”
Хорошо работает вариант, когда все возникающие вопросы переадресовываются другому человеку, который не занят написанием кода и может позволить себе отвлекаться на обдумывание или вспоминание.
Данный подход используется в основном, когда программа нужна была “еще вчера”. Соответственно, его предполагается использовать либо для завершения проекта и сдачи хоть какой-то версии, после чего следует изучение кода и скорее всего сборка новой версии, в которой исправлены критические ошибки, либо для написания относительно простых программ максимально быстро (требование такой скорости встречается во фрилансе). Понятие простых очень относительно, зависит от разработчика. Ну и следует помнить, что выкладка на 100% не всегда самая эффективная в перспективе. Во-первых - постоянно работать на 100% нельзя - можно сгореть, во-вторых, можно тратить время на общее увеличение кпд - тогда получится, что 80% дадут более высокий результат, чем чьи-то 100%. “40% мощности порша - это 220% мощности малолитражки.”