продолжая беседу

[juan_gandhi]

Т.к. есть такое европейское мнение, что рефакторинг - это метросексуальный аджальный метод продажи навоза юзерам, то я вдруг задумался - а что в Европе делают, когда их хакают и информацию воруют? Ну понятно, против воровства в Европе есть законы, например, GDPR; а в Швейцарии так даже масс шутинги запрещены (это мне швейцарцы когда-то сказали); но вот если случилось, так что тогда? Компьютеры сжигают на свалке, покупают новые, и пишут для них новые программы?

Ведь, я слышал, в Европе сначала на Z-notations и на Rational Rose весь дизайн правильно напишут, так что европейская программа не может быть неправильной, так что и рефакторить там нечего. Она совершенна.

И вот если она сломалась, то чо. Неужели с нуля переписывают?

Тесты-то понятное дело что не нужны; программист выполняет приказ менеджера, а менеджер не может ошибаться; и только плохой программист пишет код с ошибками. Немецкий код работает везде и без ошибок. Ой, тут сразу вспоминается Энигма, и три ушлых поляка, которые ее кракнули как раз перед Второй Мировой. 

Comments

[snowps]

Для того, чтобы - условно - сделать мою простейшую домашнюю конструкцию выходного дня, Вам придётся не только вспоминать программирование на ассемблере, но и изучать элементную базу из многих сотен компонентов, зная плюсы, минусы и применимость каждого из них, и ещё тысяч - по аналогии; особенности микроконтроллеров, их баги и фичи, возможности тех самых cool tricks; аналоговую и цифровую схемотехнику; проектирование и изготовление печатных плат и т.д., и т.п., причём это нормальные умения среднестатистического инженера, который использует программирование по прямому назначению - в качестве лишь одного из инструментов для создания законченного устройства. Если брать более серьёзные инженерные задачи, нежели я решаю для собственного удовольствия, то пришлось бы разбираться с FPGA и CPLD (что, кстати, тоже программирование и временами очень сложное), спецификой проектирования высокочастотных устройств, компенсации задержек от разной геометрии печатных дорожек, читать массу стандартов и прочее-прочее-прочее. Это ни разу не небольшой тренинг - Вы просто не сможете работать в подобных комплексных инженерных областях, поскольку в них нет программирования в том узком смысле, который Вы считаете единственно возможным. Да - в молодости Вы занимались программированием в том стиле, в котором им занимаются инженеры, но даже тогда схемотехникой и прочими практическими задачами помимо кода занимались другие люди. У меня нет сомнений в том, что Вы хороший программист (поскольку Вас от этой сферы прёт и это не меркантильный интерес), но программист - это далеко не всегда инженер. Инженер отличается от чистого программиста тем, что он может создать с нуля готовую конструкцию, поскольку владеет разнообразным инструментарием на том уровне, который позволяет получать полноценный, целостный, ни от чего не зависящий продукт только своими силами, а чистые программисты пишут код, а на остальное говорят "мне наплевать на производительность, когда есть AWS и map/reduce", "я не сисадмин, чтобы настраивать сервера", "мне не интересно, что внутри компа и как работает компилятор". Да - инженеры не обязательно являются программистами-математиками, пишущими код для того же DSP, или специалистами по проектированию СВЧ-оборудования, разрабатывающими фронтэнд для инструментальной техники 10+ гигагерцового диапазона, но они владеют _разными_ инструментами, а не одним. Я много лет читаю посты и комментарии в этом журнале и многократно убеждался, что как только в обсуждении возникает нетривиальная задача, которую хочется решить, практически все участники обсуждения, порграммисты со стажем, едут по глубокой и абсолютно прямолинейной колее в своих идеях, не замечая очевидные и намного более красивые решения, забывая, что "a problem that seems difficult may have a simple, unexpected solution." (c)

[vit_r]

Угу. Спор инженеров с теоретиками частенько заканчивается тем, что они решают проблему, коварно придумывая простые масштабируемые методы.