> чтобы делать миру хорошо, а это значит для бизнеса.Ваш этот "бизнесс" обесценил людской труд, ваш "бизнесс" завтра спокойно уволит всех "программистов" как только программы научаться писать программы.
> Бизнесу нужна предсказуемость процессов. В частности технологических процессов, но не
> только.
Предсказуемы только автоматы, и то написанные "предсказуемыми" людьми, а из ваших суждений выходит, что человек "непредсказуем", парадокс.
> Так вот, нужна предсказуемость технологий. Откуда вылезает непредсказуемость? Ты, такое
> ощущение, хочешь свалить всю проблему на тупого инженера.
Предсказуемость вылезает от предсказуемых людей, людей которые работая с памятью соблюдают правила работы с ней. Разгильдяям тут не место. Помните проблему с дыркой на МКС? Что это было? Как такое допустили? А все просто, тупо разгильдяйство, не там просверлил, залепил жвачкой, и после этого еще ни хрена не перепроверили изделие (не отладили), запустили, и уже на орбите обнаружили. Вот так вот - технология "непредсказуемых" людей. И дырка эта разве проблема данной области? Разве не проблема разгильдяя с дрелью в руках после похмелья (а жвачка, чтобы перегар загасить)?
> статьи посвящённые отбору кандидатов при найме, и всё это в целом
> выглядело как бред сивой кобылы. Можно попросить кандидата написать сортировку пузырьком,
> и если он не напишет, то отказать ему. А если напишет?
А не надо говорить ему напиши "пузырьковую" сортировку, надо говорить - отсортируй вот такой массив данных.
> сейчас иду в гугл освежать память, либо мне нужно 3..8 часов
> на то, чтобы изобрести велосипед.
Нормальный рабочий ход, изобретать велосипед не грех. Главное понимать принцип его работы, видеть плюсы и минусы того или иного вида велосипеда.
> Но я отвлёкся, нет способа оценить квалификацию программиста, потому что нет чёткой
> технологии программирования.
Есть способ, его конечный продукт необходимо оценивать, если он не удовлетворяет поставленным требованиям, значить менее квалифицирован. Если нет четких требований, то и смысла оценивать нет.
> Бизнесу пофигу, считаешь ли ты проблемы с памятью проблемами программиста или проблемами
> CS, бизнесу нужен результат, причём с гарантией его достижения.
И ему пофиг как этот результат достигается. Бизнесу пофиг на вашу проблему и скидывает он на вас, а вы эту проблему скидываете на CS, ну ждите 2000 лет когда CS решит эту проблему.
> CS -- это раздел науки, которая обслуживает IT, значит это проблемы CS.
Ок, пусть будет проблемой CS? Будем ждать у моря погоды.
> Это был взгляд с точки зрения экономики.
А я рассматриваю все с точки зрения философии.
> Теперь с точки зрения инженера. Тебе, как программисту, приходится выносить решение о
> надёжности кода. О надёжности своего кода и о надёжности чужого кода.
> И как ты это делаешь? Заглянул в сорцы, увидел что там
> оформление кода кривое, сделал вывод о том, что сорцы -- отстой?
Ну это утрирование, оформление кода и прочая хрень, я же говорю я пытаюсь мыслить шире, и не ограничивать себя понятиями системы, языка, синтаксиса и т.д. для меня это все чуждо. Чтобы ребенку объяснить "пузырьковую" сортировку я должен сначала его обучить языку какому-то? да нет, вырежу квадратики бумажные пронумерую разложу на полу и покажу алгоритм в действии. А перед тем как выносить решения о "надежности" кода, для начала необходимо определить строгие критерии надежности. И поэтому мне щас трудно отвечать на такие рассуждения, необходима строгость в суждениях, чтобы вывод был строгий. Чтобы неоднозначности в трактовке не было.
> оформление кода остаётся одним из важных детекторов качества. Покрытие тестами
> -- важный критерий.
Посредственный сказал бы, не важный как минимум для меня, многие возразят - мол используй форматтер, или какой смысл писать некрасиво оформленный код, если есть строгие правила его оформления принятые в то или иной компании, мы же не будем их нарушать? Или допустим оформление кода это договоренность в команде, и нарушая её - проявление неуважения к коллегам как минимум, но не как не важны "детектор".
> Они правильные ритуалы выполняли, правильно приседали и с нужной интонацией произносили "ку". Это карго-культ, но какие альтернативы ему?
Ну да это сродни ритуалам, а ритуал - договоренность. Если это не принимают, то это перестает быть ритуалом. А отношение к ритуалом разные, вам не обязательно соблюдать правила ритуала если вы не в этой среде (в ритуальном кругу).
> Ещё можно проводить аудит кода, это долго и дорого, но
> если ты посмотришь повнимательнее, этот аудит -- это тоже не алгоритм,
> это груда эвристик, только более системно применяющаяся, чем те эвристики, которые
> ты используешь.
Вот тут ошибочка, аудит именно и есть алгоритм проверок и выставления оценок, а проверки заранее подготовлены.
> Справедливости ради, тестирование, фаззинг, valgrind имеют шансы выловить баги, про которые
> ничего неизвестно заранее. То есть они стохастические методы оценки качества кода,
> и применяя статистику можно попытаться высчитать количество багов в данной программе.
> Но тут есть проблема: те кто разрабатывают программу тоже пользуются этими
> тулзами, а это значит, что ноль найденных нами багов -- это
> не гарантия того, что программа разрабатывалась специалистами, которые не допускают багов:
> они может быть в каждой второй строке кода допускают баг, но
> потом исправляют те, которые вылавливаются этими методами. А те, которые не
> вылавливаются, остаются в коде. И сколько их там?
Пошаговая отладка отловит все баги, ибо найденные выше указанными инструментами баги проверяют в процессе отладки, или ждут когда программа выпадет в корку и тогда уже запускают отладчик. Разве не так? или идут ищут баги в исходном коде? Отладка, еще раз отладка.
> Как инженер ты должен уметь оценить надёжность разработанной системы. Более того, ты
> должен уметь обосновать эту оценку. (Ты выше рассуждаешь, что "вычисление --
> это не доказательство", но на самом деле это не так: вычисление
> это конструктивное доказательство результата, которое доказывает результат вычисляя
> его.
Как выше указал, должны быть определены критерии надежности, и согласован метод оценки, ибо что тут доказывать? Это не доказательства получается, это и есть аудит, проверка качества и т.д. как в случае с любым промышленным продуктом. После всех проверок и оценок ставиться знак качества :)
Далее, вот тут ошибка "Ты выше рассуждаешь, что "вычисление -- это не доказательство"", я так не писал, привожу как есть:
"""
Оценку дают, это результат вычислений. Оценку доказывать нет необходимости, но метод получения оценки может требовать доказательства, согласен. Но обычно этот метод должен быть принят обеими сторонами ибо смысла нет.
"""
Оценка как результат вычислений, а оценку в свою очередь доказывать не надо, но метод оценки может требовать доказательства. Метод оценки должен принят обеими сторонами.
> Вычисление -- это тоже способ рассуждать, причём достаточно строгий способ,
> чтобы претендовать на звание математически строгого доказательства.) Но даже если ты
> и умеешь оценить надёжность, то какова надёжность этой оценки?
Повторяю, не надежность оценки, а метода оценки, и доказывать нужно метод оценки, но его нафиг доказывать не нужно, он должен быть согласован и принят обеими сторонами. Если допустим мне необходимо оценить ваш продукт, и я воспользуюсь вашим методом оценки, то простите меня это будет самообман с вашей стороны. Аудит не должен зависеть от сторон, на то и есть независимый аудит. И в практике не просят подрядчика доказать что его продукт надежный, приглашают со стороны независимы аудит и он дает оценку.
> Ты можешь
> сказать что-нибудь в стиле: программа за тысячу часов работы покажет бажное
> поведение K раз? Ты можешь дать оценку этого K, в виде
> среднее+стандартное отклонение? Нарисовать распределение вероятностей этого K? Если
> нет (а я уверен, что нет), то ты не можешь оценить
> надёжность разработанной системы.
Да могу, как минимум методом Монте Карло.
