Понимает ли ваш супруг, как вы думаете?
Инженерия — это аналитическая профессия, в которой, если все сделано правильно, все может быть проверено холодным расчетом. Это данность. Не имеет значения, что вы думаете о чем-то, важен только результат.
Недавнее статья Малкольма Гладуэлла в Нью-Йоркер поднимает этот вопрос. В ней обсуждается роль инженеров в автомобильной службе отзыва. Помните катастрофу Пинто? Столкновения сзади может превратить автомобиль в огненный шар. Что не так с этими инженерами?
Оказывается, числа просто не поддерживают страстные крики о переменах. Большое дело, которое было инициировано, когда три девочки-подростка погибли, когда их Пинто сгорел, выиграл Ford.
Статья дает не относящиеся к инженерам превосходное понимание, как мы думаем, как мы принимаем решения, и что еще более важно, как мы смотрим на мир. Она рисует разительный контраст образа мысли людей, ориентированных на число, и многих других, которые принимают решения, основанные на том, как они себя чувствуют.
Конечно, иногда наши аналитические стороны не всегда уместны. Когда мы растили детей, моя жена спросила, почему я всегда думал о том, что может пойти с ними не так. Я ответил: «Я тренировался в анализе худшего случая.»
Я EE, как и многие из людей прошивки, провел последние четыре десятилетия в зазоре между проектированием схем и написанием кода для поддержки этих схем. Аппаратных сторона не прощает эмоций или какие-либо идей заставить электроны двигаться не в точности так, как предсказано теорией. Что касается программного обеспечения, оно застыло в фазе «но это работает?».
В аппаратуре мы имеем совокупность знаний. Закон Ома. Законы Максвелла. Физика транзисторов. Мы можем проанализировать HFE и другие параметры, чтобы предсказать передаточную функцию, и можно вычислить Q и резонансную частоту при создании колебательного контура, который соответствует определенным требованиям.
Мир программное обеспечение искажен. Прогнозировать трудно. Простотой вопрос — как долго это подпрограмма обработки прерываний, написанная на С, будет выполняться? Большинство из нас не может это предсказать. К счастью, это можно измерить. К сожалению, немногие это делают. Как перевести требования в размер необходимого флэша? Как можно предсказать размер стека или кучи?
В оборудовании мы можем проанализировать нештатные ситуации. Экстремальные температуры, допуски и посадки, сопряженные размеры — все это понятно математически.
Программное обеспечение не слишком понятно. Недостатки скрыты, проявляясь в самых неожиданных местах. Бурю прерываний трудно анализировать. Управление задачами не является детерминированным.
Тогда появляются фичи. Они несутся через программное обеспечение, как пламя пожара в Калифорнии. Редко они рассматриваются в инженерном стандарте — который является холодным, жестким анализом. К сожалению, программное обеспечение процессов очень трудно изучать. Академическая литература полна статей о разных идеях, но подавляющее большинство из них связаны с экспериментами, использующими крошечные кодовую базу, созданную несколькими разработчиков, среди которых в основном студенты с небольшим опытом, и, конечно, не в реальном мире. Инженеры по праву скептически смотрят на выводы из этих игрушечных экспериментов.
Тем не менее, у нас есть много данных, которые большая часть сообщества в программной инженерии не знает.
Что является лучшим способом для разработки кода? Этот вопрос, наверное, даже не имеет смысла, учитывая широкий спектр приложений, постоянно создаваемых. Программа, которая будет использоваться одним человеком дважды, имеет совсем другие потребности, чем та, что управляет двигателями на A380.
Рассмотрим agile-сообщество. Есть десятки agile методов. Которые из них работают? Какой из них лучше? Никто не знает. На самом деле, мало достоверных данных (за пределами игрушечных экспериментов) об эффективности agile методов против других подходов. Это определенно не повод выкидывать agile, как я считаю, (из за отсутствия аналитических данных) некоторые из agile идей просто блестящи.
Некоторые люди говорят, что, конечно, нам не хватает данных о agile, но это справедливо и для других методов. В это много правды, поскольку в EE были столетия для развития теории, чтобы извлечь выгоду из работ Георга Ома и других. Программное обеспечение относительно новая концепция. Мы по-прежнему нуждаемся в Теории Программного Обеспечения Всего.
Но полагаю, можно по-новому сформулировать эти вопросы. Например: «Какие два самых эффективных способа уменьшить ошибки и ускорить разработку?».
Интересно, какой будет ваш ответ.
Все очень просто: формальные проверки и статический анализ. Почему? У нас есть данные. На самом деле, у нас есть десятки тысяч точек данных. Один источник «The Economics of Software Quality» by Capers Jones and Olivier Bonsignour, но есть многие других.
Мы знаем, что цикломатическое сложность — это, на самом деле, хороший способ измерить аспекты эффективности тестирования.
Мы знаем, на самом деле, что средняя команда программистов не удаляет 15% предварительно внесенных ошибок. Мы знаем, что команда прошивки пропускает треть от внесенных ошибок.
У нас есть данные, часть закона Ома для разработки программного обеспечения. Тем не менее, в мире встраиваемых систем лишь около 2% команд используют эти данные для управления их методами разработки.
Я считаю, что есть много данных, и я призываю разработчиков использовать их, и применять результаты в своей повседневной работе.
Эдвардс Деминг сказал лучше всех: «В Бога мы верим, все другое требует данных».
Комментарии (30)
tangro
12.05.2015 14:21Мы знаем, что цикломатическое сложность — это, на самом деле, хороший способ измерить аспекты эффективности тестирования.
Вспоминается доклад JetBrains с какой-то конференции, где они говорят, что цикломатическая сложность, как и прочие «абстрактные попугаи в вакууме» несёт не так много смысла, как кажется. С чего это автору оригинала кажется, что он на 100% знает, как какая-то метрика отражается на качестве? Где теоретические и практические выкладки в доказательство этого «закона Ома для разработки программного обеспечения»?
GarryC Автор
12.05.2015 14:40Если я правильно понял мысли Джека (а я могу ошибаться) ему цикломатика понравилась тем, что дает конкретный результат в конкретном числе, то есть в одном случае этот формальный параметр в 3 раза больше (хуже), чем в другом. Конечно, и в коде с цикломатикой 2 можно сделать 25 ошибок, и код с цикломатикой 35 можно написать аккуратно (хотя тут я не уверен), но есть какой-то объективный критерий.
tangro
12.05.2015 15:01+2Из объективности критерия не следует его полезность. Одна кошка может быть в 2 раза пятнистее другой или иметь в 3 раза более тёмный окрас, но насколько хорошо они ловят мышей из этого совершенно непонятно.
GarryC Автор
12.05.2015 16:45Боюсь, что пример с пятнами несколько неуместен.
Если у Вас код с отступом на 15 уровней, то допустить у нем ошибка проще, чем в коде с 3 уровнями отступа.
Критерий цикломатки напрямую завязан со сложностью понимания кода и вряд ли может быть сравним с окраской.
Более близкий пример — раньше последовательность действий, необходимых для запуска двигателя, состояла более чем из 10 пунктов и занимала 2 страницы технического описания автомобиля. Теперь она сводится к одной строке — нажмите кнопку «Старт». Где проще допустить ошибку?tangro
12.05.2015 16:49+1Код с большим цикломатическим числом мог быть сгенерирован каким-нибудь кодогенератором и вообще не предназначен для чтения человеком. Ну или такую структуру кода потребовали какие-нибудь ограничения по памяти\быстродействию. Можно придумать и другие причины. В общем, вот всё это «иногда правда, а иногда нет» никак нельзя сравнивать с фундаментальными физическими законами, вроде закона Ома.
GarryC Автор
12.05.2015 23:58Если бы Вы внимательно прочитали оригинал (читать такой ужасный перевод, несомненно, нельзя, это понятно) то заметили бы, что Джек говорит о части закона Ома. Всего лишь о части и я это постарался перевести. «Иногда правда а иногда нет» по-любому лучше, чем всегда непонятно что, особенно если Вы понимаете ограничения применяемого метода. Можно придумать множество причин для оправдания неряшливо спроектированного и неудачно реализованного кода (шлеп шлеп и в продакшн), но, может быть, лучше потратить это время на улучшение кода.
eugenius_nsk
12.05.2015 15:13+2Один из самых объективных критериев — количество строк кода. Вот только к качеству программ он не имеет никакого отношения.
webkumo
12.05.2015 15:46+1Отношение к качеству — ещё фигня… оно ведь ещё и к реализации задачи не имеет никакого отношения!
GarryC Автор
12.05.2015 16:47Ну есть и другие числовые критерии, связанные с размером.
Например, средний размер модуля. Многие считают непрерывный код длиной более 200-300 строк просто недопустимым и требуют его разбиения на независимые единицы компиляции. И этот подход во-многом оправдан.
Так что критерии есть, конечно, их нельзя абсолютизировать, но и пренебрегать ими не стоит.
Suvitruf
12.05.2015 14:21+31Инженерия — это аналитическая профессия, в которая, если все сделано правильно, все может быть проверено холодным числом.
А переводы можно проверить «холодным числом»?
Если серьёзно, то спрячьте лучше статью, до тех пор пока не приведёте перевод в читабельный вид.
StrangerInRed
12.05.2015 15:09+2Я кстати читал, читал, думаю, что за херня с согласованием слов? А потом осознал что это перевод.
eugenius_nsk
12.05.2015 15:15+5Да там не только с согласованием проблемы:
Я EE, как и многие из людей прошивки, который провел последние четыре десятилетия между проектированием схем и написания кода для поддержки этих устройств.
Aiki
12.05.2015 17:03+4После этого абзаца моему мозгу настал абзац, пришлось лезть в оригинал. Там написано: «I’m an EE, like many embedded people, one who has spent the last four decades split between designing circuits and writing code to support those devices.» — , что можно перевести как: «Я — разработчик встраиваемых систем (Embedded Engineer), и как многие „встраиваемые“ люди, один из тех, кто провел последние четыре десятилетия между проектированием схем и написанием кода для устройств.»
GarryC Автор
12.05.2015 23:42-3При всем уважении, перевести ЕЕ как Embedded Engineer, это взять на себя определенные риски. Не менее распространенное сокращение Electonics Engineer ( от IEEE — Institute of Electrical and Electronics Engineers) и лично я не возьму на себя смелость утверждать, какой именно смысл вложил в сокращение Джек, особенно учитывая слово embedded в том же предложении. Что касается кавычек при слове встроенный, то в оригинале их нет и если Вы так хотите его закавычить, то надо сопровождать примечанием переводчика на две-три фразы.Считаете это целесообразным? Конечно, на вкус все краски разные, но «люди прошивки» более точно передает суть данного термина, нежели Ваш вариант. Меня радуют люди, которые предъявляют претензии к переводу, а потом представляют подобные варианты.
Лично я стараюсь делать минимальные правки именно по той причине, что не владею английским в достаточной степени, чтобы учесть все нюансы и смыслы фразы, а вкладывать свое ее понимание в уста Джека не считаю возможным. Если бы я хотел написать свой пост на тему, навеянную постом Джека, я так бы и заявил в начале текста. Поскольку там написано перевод а не вольное изложение, я и пытаюсь сохранить максимальное подобие исходному тексту. Жаль, что большинство минусующих этого понять не в силах.Aiki
13.05.2015 05:00+5Я прошу прощения, но одно дело, когда вы пытаетесь дать перевод, максимально близкий к оригиналу, и совершенно другое дело, когда вы даете слегка подкорректированный машинный перевод. «Недавнее статья», «в автомобильной службе отзыва», «Аппаратных сторона не прощает эмоций», «Мир программное обеспечение искажен», и т. д. И это не говоря об ужасном, ломанном языке. Прошло более половины суток с момента публикации, и вместо того, чтобы писать развернутые комменты, о том, почему вы так поступили, вы могли бы поправить эти ошибки, и сделать текст более удобоваримым. Тогда люди найдут силы дочитать до конца, и начнут задавать вопросы по существу.
Перевод — это почти всегда адаптация. Есть огромное количество терминов, которые не имеют простых аналогов в других языках. Если вы беретесь за перевод, то будьте готовы, что дословно может не получится. Соответственно главная задача — передать максимально точно смысл. В «узких» местах, если вы сомневаетесь, можно в скобках привести оригинал, тогда вам смогут подсказать в комментах, а еще лучше — обратиться к автору за пояснением, что конкретно он хотел сказать в данном месте данным речевым оборотом.
А если вы не поняли смысла, то зачем начали переводить? То что вы сделали не на много ценнее, чем публикация ссылки вида translate.google.ru/translate?sl=en&tl=ru&js=y&prev=_t&hl=ru&ie=UTF-8&u=http%3A%2F%2Fwww.embedded.com%2Felectronics-blogs%2Fbreak-points%2F4439394%2FThe-engineer-s-lament&edit-text=&act=url
GarryC Автор
13.05.2015 00:14-3То есть вы всерьез считаете, что из прочтения этого перевода (вполне возможно, не очень удачного) невозможно понять, о чем говорит Джек? Какие мысли он хочет донести своим постом? Если можно (а мне кажется, что вполне), то зачем прятать? Чтобы кто-нибудь не поставил минус? Так я, в общем-то, цель собрать побольше плюсиков и не ставил. Просто увидел интересный пост уважаемого мною человека, специалиста в данной области, и подумал, что его мысли могут представлять интерес не для меня одного. А для тех, кому будет лениво читать оригинальную заметку, попытался дать представление о ней. Жаль, что ошибся, не в смысле того, что жаль полученных минусов и (о Боже, какая трагедия) упавшей кармы (меня неделю назад вообще за пост банили, так что я переживу), а в смысле того, что проблемы, волнующие Джека, для читателей Хабра просто не существуют. Грустно, господа, грустно.
Suvitruf
13.05.2015 09:15+4Я считаю, что публиковать такой сырой перевод — это, как минимум, неуважение к читателю.
vlreshet
12.05.2015 15:37+9Такое ощущение что текст через переводчик прогнали с минимальными правками. Читать невозможно.
«Я EE, как и многие из людей прошивки, который провел последние четыре десятилетия между проектированием схем и написания кода для поддержки этих устройств. Аппаратных сторона не прощает эмоции или какие-либо идеи заставить электроны двигаться не в точности так, как предсказано теорией»
Ну вот объясните мне, что здесь вообще написано?
UPD: я всегда буду обновлять комментарии перед отправкой, я всегда буду обновлять комментарии перед отправкой, я всегда буду обновлять комментарии перед отправкойGarryC Автор
12.05.2015 23:50-7Прочитайте мой ответ на предыдущий комментарий. Да, именно, вы необычайно тонко подметили, с минимальными правками. Если я буду переводить с английского текст, написанный Вами (все может быть), я, конечно, отнесусь к нему совершенно по-другому и переведу как мне понравится, не задумываясь о смысле, который Вы вложили в свои фразы. Вряд ли стоит разъяснять причины подобного, не переходя к прямым оскорблениям. Чтобы понять, что «здесь вообще написано», обратитесь к оригиналу, и, уверяю Вас, я старался максимально точно передать именно фразу Джека. Когда предложите свой вариант, не перевирающий эту фразу, не меняющий ее построение, продолжим дискуссию.
marapper
13.05.2015 00:07+1Да ему достаточно хотя бы поправить орфографические и грамматические ошибки для этого. Запомните, при переводе вы можете оставить типичный для английского порядок слов, не учесть игру слов или что-то подобное, но надо сделать хотя бы половину работы.
Навскидку
Я EE, как и многие из людей прошивки, провел последние четыре десятилетия в зазоре между проектированием схем и написанием кода для поддержки этих схем. Аппаратных сторона не прощает эмоций или какие-либо идей заставить электроны двигаться не в точности так, как предсказано теорией. Что касается программного обеспечения, оно застыло в фазе «но это работает?».
I’m an EE, like many embedded people, one who has spent the last four decades split between designing circuits and writing code to support those devices. The hardware side is unforgiving of emotion or any idea that doesn’t push electrons in exactly the way needed. The software side holds results to the “but does it work?” standard.
А я разработчик встраиваемых систем, как и многие «недовстроившихся» людей, последние четыре десятилетия разрываюсь между проектированием схем для устройств и написанием кода, который будет выполняться на них. Железо не прощает эмоций и никаких идей, если это не заставляет двигаться электроны в правильном направлении. Софт же удерживает результаты в пределах норматива «а это работает?».GarryC Автор
13.05.2015 00:26-1Офигеть, «недовстроившиеся» люди, это что-то новое в любовном лексиконе нашего двора.
А вот насчет «разрываюсь между» — действительно неплохо и, пожалуй, ближе к смыслу.
Тем не менее, позволю вопрос, мой вариант не про то-же самое?
folkyatina
12.05.2015 23:31+3Плач переводчика?
GarryC Автор
13.05.2015 00:04-1Что интересно, по сути сказанного Джеком высказался только один комментирующий. Видимо, иметь свое мнение о Agile технологиях несколько сложнее, нежели заметить и без того очевидные несовершенства перевода. Я то думал, что мне скажут о недооценке данных технологий и о блестящих идеях, в них заложенных, и постарался заранее предупредить о своем недостаточном их знании, но, видимо, переоценил степень осведомленности в Agile среднего читателя Хабра. Несколько озадачен происшедшим.
Int_13h
13.05.2015 07:23+2Agile технологиях
Так что это за технологии то? «Шустрые технологии» — непонятненько.
GarryC Автор
Сразу скажу, что это мысли Джека, а не мои, я не настолько сведущ в Agile технологиях, так что на часть комментариев, скорее всего, квалифицированно ответить не смогу.
marapper
Эта мысль которую придумал Джек, а это статья, которую перевело Гарри, о мыслях, котороя подумала Джека.
GarryC Автор
Необычайно тонко, мои поздравления, но, по-моему, joyreactor все-таки по другому адресу, нет?