au> Хороший программист пишет хороший код — это единственный критерий оценки. Именно так. А вот критерий «хорошего кода» уже далеко не однозначен (не путать с «идеальным кодом»). Ну, как хороший писатель не обязан быть хорошим редактором.
Код в общем случае не может быть правильно работающим, быстрым, красивым внутри и снаружи (в виде программы), понятным, легко поддерживаемым и быстро пишущимся. Любой код — это набор массы компромиссов. Постоянные размены эффективности и скорости разработки, эффективности и надёжности и т.п. А про то, что отличная архитектура кода в рамках мышления программиста практически не сочетается с отличным интерфейсом программы я с соционической точки зрения не раз расписывал
Даже если взять частную задачу, программирование космической аппаратуры, и всякие вопросы GUI отпадают, то остаётся ещё много неразрешимых противоречий.
— Пишем высоко надёжный код и он оказывается недостаточно эффективен в рамках имеющейся аппаратуры.
— Делаем высокую оптимизация и получаем плохо расширяемый код, на котором при последующей модификации зевнём хитрую ошибку
— Пишем наглядный документированный код и не укладываемся в сроки разработки
И так далее, и тому подобное.
А ошибки в нормальном ответственном проекте, кстати, вообще не программист должен ловить. Построение модели функционирования, разработка и написание тестов покрывающих её — это, вообще, работа целого отдельного коллектива. Который ничем, кроме тестов заниматься не будет.
И в итоге программист зевнёт дедлок при редком сочетании параметров, тестировщики не предусмотрят один из выходов за пределы оптимальных параметров, разработчики железа не предусмотрят аппаратного ограничения, а корабль запустят с небольшими отклонениями от заданных параметров. И система навернётся. Кого потом винить в этом? Программиста, что не предусмотрел особой ситуации? Тестировщиков, что не сделали проверок за рамками узкого ТЗ? Составителей ТЗ, которые не подумали, что по этому параметру можно получить такие значения? Разработчиков аппаратуры, которые подумали, что софт всё переварит? И так далее…
… чтобы понять рекурсию, нужно сперва понять рекурсию …