Мне тут в голову пришла неожиданная идея оптимизации кода: убрать на компьютера разработчика функцию copy-paste.
Вопрос: повысится ли качество кода?
Источник: bash.org.ru, удалённая цитата
Ответом на вопрос из эпиграфа будет, по-моему, скорее “да”, чем “нет”. Та или иная ограниченность ресурса (машинного времени), приводит к более эффективному его использованию.
Когда мой учитель информатики работал программистом на большом советском заводе с большими компьютерами, программы для которых писались на перфокартах, скармливаемых компьютерам специально-обученными девочками, у него не было возможности дебаггить программу в реальном времени. Он готовил перфокарты с программой, дожидался своей очереди, отдавал перфокарты с исходниками девочкам и через время получал от них другие перфокарты с результатом работы его программы. Результатами были или искомые данные, или ошибки в том или ином виде. В случае неудачи (представьте, что вы первый раз компилируете программу после того, как она полностью написана — и прикиньте вероятность удачной компиляции) он готовил новые перфокарты и снова ждал своей очереди, чтобы отдать перфокарты девочкам. Чем больше раундов он затрачивал на решение задачи, тем сильнее был нагоняй от начальства. Эти ограничения выработали некоторые навыки компилирования и исполнения программ без компьютера (”в уме” и “на бумажке”).
Когда я учился в школе, у меня не было личного компьютера, машинное время было ограничено уроками информатики в лицее и ИГЗ там же. Компьютерного времени очень не хватало, а программировать хотелось много. Из-за этого очень многие программки писались заранее “на бумажке” (целиком или полностью), а компьютер использовался лишь для ввода, отладки и доводки программы. Иначе (если программировать только тогда, когда оказывался у компьютера) успевалось очень немного — из-за того, что неэффективно расходовалось время. Нехватка машинного времени научила писать программы без компьютера.
Вынужденное программирование без компьютера заставляло больше думать, изменяя стиль программирования: тщательное продумывание алгоритма вместо методичного перебора возможных вариантов решения. При решении алгоритмической задачи всё время есть несколько конкурирующих путей решения задачи. Если у тебя есть компьютер под рукой, то самый простой способ выбрать лучшее решение — это перебровать все способы, которые пришли в голову, и выбрать тот, который лучше всего работает. Это самое простое решение, но оно требует довольно больших затрат компьютерного времени - на ввод и отладку каждого решения с его последующей проверкой. Когда доступа к компьютеру нет, и будет его всего ничего, ты не можешь позволить себе перебирать варианты. Приходится анализировать их в голове (на бумажке) и искать решение “теоретически”.
Самый простой пример: задача — сделать в программе хитрую операцию с большим массивом за наименьшее время. Есть 3-4 способа запрограммировать эту операцию, на первый взгляд все одинаково эффективные. Как будет решать эту задачу глупый программист? Сядет и закодит все решения, посмотрит на скорость работы и выберет правильный. Умный программист прежде чем кодить, оценит каждое из решений в уме, т.е. без компьютера.
Очевидно, что для того, чтобы быть умным программистом, не обязательно быть ограниченным в компьютерном времени. Достаточно выработать в себе привычку не бросаться кодить без предварительного рисования фигнюшек на бумажке. Принудительное ограничение машинного времени вынуждает тебя решать задачу без компьютера, при этом приходится думать. Это ограничение помогает осознать, что в программировании код — вторичен; первично решение задачи (алгоритм, структура данных, правильные подпрограммы и прочее). Свободный доступ к компьютеру развращает программиста — искушение выбрать правильное решение перебровав все варианты велико и часто берёт верх.
Безусловно, некоторые программистские задачи требуют некоторого перебора. Написанное выше относится скорее к алгоритмическим задачам, и решать такие задачи нужно тщательнее.
Возвращаясь к эпиграфу: если запретить разработчику делать copy-paste, то это вынудит его писать правильные (в меру универсальные) подпрограммы, а не плодить код а-ля индус.
