Можно я не буду отвечать на каждое твою строчку, и просто в целом попытаюсь ответить? Если тебе важно на какие-то из утверждений услышать мои ответы, то ты скажи на какие.Программирование -- это технология, часть стека технологий IT. Технологии создаются для того, чтобы обслуживать бизнес. То есть, мы часто программируем just for fun, и там мы можем себе ставить любые требования к программе или к процессу написания программ, какие нам нравятся, но в целом технологии создаются для того, чтобы делать миру хорошо, а это значит для бизнеса.
Бизнесу нужна предсказуемость процессов. В частности технологических процессов, но не только. Бизнес очень часто упирается в то, что он сначала вливает ресурсы в создание чего-то (часто эти ресурсы измеряются деньгами), и если всё выгорит, то он потом получает какие-то ресурсы взамен потраченных (тоже часто сводят всё к деньгам). Это риск, ты чуешь? Можно влить ресурсов и не получить ничего взамен. Режимов отказа может быть очень много, есть очень много способов для бизнеса профукать все полимеры. Технологические процессы тоже вносят свой вклад в список этих способов. Тут, если по-хорошему, надо было бы привести пару десятков способов пролететь, чтобы ты представлял себе хотя бы примерно многообразие этих способов, но у меня нет настроения писать такую простыню.
Так вот, нужна предсказуемость технологий. Откуда вылезает непредсказуемость? Ты, такое ощущение, хочешь свалить всю проблему на тупого инженера. Но ты в курсе, что у людей нет надёжных тестов для оценки тупости? То есть, зашкаливающую тупость можно объективно замерять, но вот объективно сравнить двух инженеров и сказать какой из них лучше справится с задачей -- тут нет методов. На HN пару лет назад, были очень популярны статьи посвящённые отбору кандидатов при найме, и всё это в целом выглядело как бред сивой кобылы. Можно попросить кандидата написать сортировку пузырьком, и если он не напишет, то отказать ему. А если напишет? Я в девятом классе мог написать сортировку пузырьком, и чё? А вот попроси меня написать сегодня чёрно-красное дерево, и я такой... эээ... там какая-то идея с тем, что узлы красные и чёрные, у красных может быть только чёрный ребёнок, все листы, вроде чёрные, бла-бла-бла... а фишка в том, что мы используя только локальные рассуждения (ну не совсем локальные: там O(log) сложность, а не O(1)) этими цветами кодируем информацию о состоянии сбалансированности дерева, которую используем при ребалансировках... ок, если вы хотите, чтобы я это написал, то либо я сейчас иду в гугл освежать память, либо мне нужно 3..8 часов на то, чтобы изобрести велосипед.
Но я отвлёкся, нет способа оценить квалификацию программиста, потому что нет чёткой технологии программирования. Можно использовать какие-то эвристики, которые имеют мало false negative, но они будут иметь много false positive. Можно найти эвристики, которые будут давать мало false positive срабатываний, но у них будет много false negative. Потому что достоверность и надёжность всех этих методик уровня социальных наук (неудивительно). Чёткая хорошая технология должна включать в себя, в частности, методику подготовки персонала и методы оценки их уровня подготовленности. У программирования их нет, а значит когда бизнес связывается с программистами, он должен не забыть пересчитать все вероятности в своих оценках рисков. Сильно пересчитать в сторону снижения шансов на успех. Бизнесу пофигу, считаешь ли ты проблемы с памятью проблемами программиста или проблемами CS, бизнесу нужен результат, причём с гарантией его достижения. CS -- это раздел науки, которая обслуживает IT, значит это проблемы CS.
Это был взгляд с точки зрения экономики. Но ежели ты планируешь когда-нибудь стать чем-то большим, чем обезъяна набирающая код, то тебе хоть и не обязательно знать экономику, но положение твоей области в этой экономике представлять надо.
Теперь с точки зрения инженера. Тебе, как программисту, приходится выносить решение о надёжности кода. О надёжности своего кода и о надёжности чужого кода. И как ты это делаешь? Заглянул в сорцы, увидел что там оформление кода кривое, сделал вывод о том, что сорцы -- отстой? Но ты ж понимаешь, что оформление кода -- это эвристика? Если я возьму хороший код, и испорчу там оформление, код не станет от этого менее надёжным. И в то же время, если я возьму плохой код и приведу оформление к идеалу, не внося других изменений, он не станет от этого надёжнее. Но и тем не менее, оформление кода остаётся одним из важных детекторов качества. Покрытие тестами -- важный критерий. Любая мейнстримовая технология повышения надёжности -- это детектор качества, это эвристика которая гарантий не даёт, но по-крайней мере говорит о том, что разработчики кода была достаточно в теме, чтобы знать про то, что такое мейнстрим. Они правильные ритуалы выполняли, правильно приседали и с нужной интонацией произносили "ку". Это карго-культ, но какие альтернативы ему? Ещё можно проводить аудит кода, это долго и дорого, но если ты посмотришь повнимательнее, этот аудит -- это тоже не алгоритм, это груда эвристик, только более системно применяющаяся, чем те эвристики, которые ты используешь.
Справедливости ради, тестирование, фаззинг, valgrind имеют шансы выловить баги, про которые ничего неизвестно заранее. То есть они стохастические методы оценки качества кода, и применяя статистику можно попытаться высчитать количество багов в данной программе. Но тут есть проблема: те кто разрабатывают программу тоже пользуются этими тулзами, а это значит, что ноль найденных нами багов -- это не гарантия того, что программа разрабатывалась специалистами, которые не допускают багов: они может быть в каждой второй строке кода допускают баг, но потом исправляют те, которые вылавливаются этими методами. А те, которые не вылавливаются, остаются в коде. И сколько их там?
Как инженер ты должен уметь оценить надёжность разработанной системы. Более того, ты должен уметь обосновать эту оценку. (Ты выше рассуждаешь, что "вычисление -- это не доказательство", но на самом деле это не так: вычисление это конструктивное доказательство результата, которое доказывает результат вычисляя его. Вычисление -- это тоже способ рассуждать, причём достаточно строгий способ, чтобы претендовать на звание математически строгого доказательства.) Но даже если ты и умеешь оценить надёжность, то какова надёжность этой оценки? Ты можешь сказать что-нибудь в стиле: программа за тысячу часов работы покажет бажное поведение K раз? Ты можешь дать оценку этого K, в виде среднее+стандартное отклонение? Нарисовать распределение вероятностей этого K? Если нет (а я уверен, что нет), то ты не можешь оценить надёжность разработанной системы.
