Давным-давно от требовалось просто, чтобы программа решала задачу. Потом важным стали скорость работы и объём занимаемой памяти. Развитие электроники сделало эти параметры несущественными для большинства задач.
Сейчас критерия качества кода похожи на мантры, которые все в индустрии от вчерашних школьников до седовласых гуру неустанно повторяют, пытаясь достичь просветления.
Код должен легко поддерживаться, легко читаться, легко изменяться, быть красивым, ясным, коротким, понятным, надёжным и верным...
Список можно продолжить. Только ни один гуру не знает, как эти магические свойства измерить. А если что и измеряют, никто не может доказать, что цифра больше (или меньше) лучше. В толстых книжках тоже самое: половина - откровения свыше, половина - откровенный бред.
Плюс у меня ещё дюжина параметров, которые в определённых условиях могут оказаться критическими, а для других совершенно не важны.
Большинство программистов поддерживают миф о том, что хороший код создают эксперты, знающие тайны языка, освоившие все просторы библиотек и молящиеся на всевозможные руководства и наставления по правильнописанию.
К сожалению, это предостерегает только от элементарных ошибок. Как учебник грамматики, который позволит получить хорошую оценку у строгого учителя, но совершенно не поможет написать бестселлер.
Если бы грамматика делала хорошего писателя, бестселлеры пекли бы как блины, а программы не содержали бы ошибок.
Знания из книжки легко проверять и относительно не сложно получать. По крайней мере, это редко когда требует умственных усилий. Но внешние приобретаемые мудрости никогда не отменят того факта, что у разных людей мозги работают с разной эффективностью.
Опыт и ум нельзя заменить писаными правилами.
Обычно гуры и книги учат делать классы маленькими. Некоторые требуют, чтобы они помещались на один экран. Но нужно ли классу пять или двадцать пять методов, сильно зависит от задач. К тому же, сложность класса как такового не идёт ни в какое сравнение с вермишелью из классов, интерфейсов и структур. Правда, класс можно измерить в количестве строк, числе методов и атрибутов, а вермишель никто мерить не умеет, и все делают вид, что её не существует.
Любому программисту очевидно, что короткая функция лучше длинной. Потому что так говорят все гуру.
Однако.
Не очевидно, что короткая функция не содержат скрытых побочных эффектов.
Не очевидно, что она обрабатывает все случаи, тем более адекватно реагирует на ошибки.
Не очевидно, что в ней нет пяти имён, обозначающих не то, что на самом деле делают вызванные функции, и не то, что на самом деле содержат использованные переменные.
Очевидно, если один расписал что-то на два экрана, то другой, который решил задачу в три строки, сильно сэкономил на комментариях. И очень часто на обработке ошибок.
Я видел людей, много-много лет писавших на Яве, или на Перле, или на Си с крестами, знающих все мелочи и потаённые уголки языков и библиотек, и в то же время бывших совершенно бездарными. Пофиг, как человек разбирается в предмете. Если он не может сделать задачу заказчика, а вместо этого строит библиотеки, он бесполезен.
Крючкотворец, познавший все закоулки фришных и фирменных библиотек слишком часто не способен понять задачи пользователя. А часто и понимание внутренней логики замещается исполнением магических культов.
В результате, создаются хитроумные алгоритмы, великолепно решающие нечто, совершено не похожее на поставленную задачу. Вместо обработки ошибок эксперт по тайнам языка их прячет или пытается доказать, что виноват пользователь. В особых случаях при взгляде на код тыкаешь пальцем в первое попавшееся место, спрашиваешь, почему? и получаешь в ответ "О! Да! Это я не подумал!"
По прошествии двадцати с лишним лет и дофига проектов в разных областях я могу сказать, что люди с безупречными знаниями пишут заумную глюкавую муть, которую невозможно поддерживать. Сложно решать задачу просто и так, чтобы изменения коллегами со средним уровнем интеллекта её не разрушили.
Глубина познаний чаще всего выражается возгласом: «Эй, чуваки! Посмотрите, какую крутую штуку я придумал!»
Самое печальное, когда подобный эксперт, погружён в один язык, в одну среду и из года в год повторяет решение одной и той же задачи. Это уже не человек. Это Хуман Ресурс. Специалист, не желающий развиваться, не заинтересованный тем, что происходит за границей его задач, во что превращаются результаты его решений, не может быть умным.
У профессионала должен быть разнообразный опыт на многих платформах с многими языками. Даже свежий выпускник должен знать минимум три языка. Но главное, что отличает хорошего программиста от плохого - это понимание задач пользователя.
В магическом мире, в котором живут программисты, существуют волшебные специалисты, выступающие посредниками между ними и реальным миром. Они общаются с пользователями, выясняют их потребности, предлагают решения, а потом говорят программистам, что делать. Они знают, что пользователю хорошо, а что плохо, какие технические решения им помогут, а какие бесполезны. Они говорят с пользователями на нормальном человеческом языке и переводят его для программистов в диаграммы и техзадания. Они могут всё. И зовут их тоже очень просто: боги.
Это стандартное перепихивание ответственности. Программист должен понимать, что делает пользователь, или спрашивать там, где не понимает. Каждый лишний уровень создаёт игру в испорченный телефон.
Почему-то считается, что для программистов правильнее изображать обезьянок за клавиатурой, а вместо того, чтобы выделить достаточно ресурсов на вхождение в тему и правильное её понимание. Это называется «изучение в процессе» и практикуется даже тогда, когда люди должны этим заниматься годами.
Впрочем, программисты не любят читать толстые книги. Большинство их покупают только, чтобы полистать и иногда ознакомиться с одной-двумя главами. Если, конечно, они не нашли чего-нибудь покороче в Интернете.
К тому же, чаще всего в софте проблемы не от того, что программисты не способны предсказать действия пользователя, а от того, что не представляют побочных эффектов своих решений и решений своих коллег. Постепенно бардак накапливается и вот уже девяносто процентов времени дружный коллектив тратит не на решение задачи, а на стыковку кривого кода, написанного, купленного или найденного в интернете.
Не трудно догадаться, что отсюда растёт миф о бесполезности документации. Те, кто не читают, не умеют и писать. Особенно, на человеческих языках.
Есть много задач, где сертификаты и стандарты процессов требуют создавать горы документации. Часто требуется создать модель системы в диаграммах и описаниях дизайна, а только потом приступать к реализации. Во многих случаях гораздо правильнее 90% ресурсов потратить на то, чтобы понять, как решать задачу, и 10% на то, чтобы воплотить решение.
Если на шаг отойти от сказочной страны программирования, то можно увидеть, что этот подход успешно работает в множестве областей в течении столетий. Архитекторы строят из бумаги модели зданий. Конструкторы с напильниками подгоняют прототипы деталей. Электротехники с осциллографами проверяют результаты своих предположений.
И только программисты твердят о бесполезности прототипов, ждут чётких указаний и веруют в единственно правильное решение. Естественно, для них мир выглядит сборищем сумасшедших пользователей, которые истерично меняют требования.
Правильный подход подразумевает, что надо немного подумать, как достать бананы, прежде чем начинать трясти пальму. Практически нет случаев, когда бы за хаотичным изменением требований не стояли бы грубые ошибки в первоначальном анализе и полное игнорирование имеющихся систем, а также явных и скрытых зависимостей между ними. Очень часто первоначальное направление просто не верно, но зарывшись в него по самые уши, программисты тупо продолжают копать.
Это особенно важно учитывать в новых проектах, когда есть много принципиально разных вариантов решения и рывок по любому из них может завести в тупик. Для того и нужно вложить время и силы, чтобы выбрать оптимальный и не страдать потом от лавины неожиданных изменений.
Проверка концептов должна быть не по этапу работ, не по конечному результату и не годами эксплуатации. Как раз для этого человеку между ушей даны мозги. Основная их функция - предсказание.
Если конкретно, то на бумажках и картинках за два часа непринуждённой беседы с пользователем можно выяснить то, на что у команды агильных обезьянок уходит пара месяцев интенсивного кнопкодавства. Просто надо включать мозги и думать, как проверять концепты наиболее быстрым и дешёвым способом.
Документация как проектная, так и отчётная в разумно проведённом проекте, естественно, меняется в соответствии с приобретением новых знаний, в том числе и за время эксплуатации. Но это в большинстве своём не хаотические новые открытия программистов, в чьём мире пользователи выведены за скобки. Новая информация только уточняет и исправляет первоначальные планы. Или позволяет сделать выбор из заранее обдуманных и просчитанных вариантов.
Проекты, существующие десятки лет, наглядно демонстрируют, что большинство индустрий достаточно консервативны. Добавления и изменения бывают часто, коренные переломы - почти никогда. И в большинстве случаев это как раз изменения в области компьютерных технологий, смена поколений операционных систем, языков и фреймворков. Во многих случаях просто выход на пенсию бронтозавров, поддерживавших старое решение.
Но это недоступно людям, замкнувшимся в мире, где постановка задачи приходит извне. Они могут только слепо закодировать, то что приказано, показать, и услышать, что на самом деле всё должно быть не так.
Зато они очень гордятся тем, что знают все нетривиальные побочные эффекты в свежем фреймворке, который призван упростить и ускорить, а на самом деле служит только для самоудовлетворения играющихся с ним.