Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 30
Сразу скажу, что это мысли Джека, а не мои, я не настолько сведущ в Agile технологиях, так что на часть комментариев, скорее всего, квалифицированно ответить не смогу.
Мы знаем, что цикломатическое сложность — это, на самом деле, хороший способ измерить аспекты эффективности тестирования.
Вспоминается доклад JetBrains с какой-то конференции, где они говорят, что цикломатическая сложность, как и прочие «абстрактные попугаи в вакууме» несёт не так много смысла, как кажется. С чего это автору оригинала кажется, что он на 100% знает, как какая-то метрика отражается на качестве? Где теоретические и практические выкладки в доказательство этого «закона Ома для разработки программного обеспечения»?
Если я правильно понял мысли Джека (а я могу ошибаться) ему цикломатика понравилась тем, что дает конкретный результат в конкретном числе, то есть в одном случае этот формальный параметр в 3 раза больше (хуже), чем в другом. Конечно, и в коде с цикломатикой 2 можно сделать 25 ошибок, и код с цикломатикой 35 можно написать аккуратно (хотя тут я не уверен), но есть какой-то объективный критерий.
Из объективности критерия не следует его полезность. Одна кошка может быть в 2 раза пятнистее другой или иметь в 3 раза более тёмный окрас, но насколько хорошо они ловят мышей из этого совершенно непонятно.
Боюсь, что пример с пятнами несколько неуместен.
Если у Вас код с отступом на 15 уровней, то допустить у нем ошибка проще, чем в коде с 3 уровнями отступа.
Критерий цикломатки напрямую завязан со сложностью понимания кода и вряд ли может быть сравним с окраской.
Более близкий пример — раньше последовательность действий, необходимых для запуска двигателя, состояла более чем из 10 пунктов и занимала 2 страницы технического описания автомобиля. Теперь она сводится к одной строке — нажмите кнопку «Старт». Где проще допустить ошибку?
Если у Вас код с отступом на 15 уровней, то допустить у нем ошибка проще, чем в коде с 3 уровнями отступа.
Критерий цикломатки напрямую завязан со сложностью понимания кода и вряд ли может быть сравним с окраской.
Более близкий пример — раньше последовательность действий, необходимых для запуска двигателя, состояла более чем из 10 пунктов и занимала 2 страницы технического описания автомобиля. Теперь она сводится к одной строке — нажмите кнопку «Старт». Где проще допустить ошибку?
Код с большим цикломатическим числом мог быть сгенерирован каким-нибудь кодогенератором и вообще не предназначен для чтения человеком. Ну или такую структуру кода потребовали какие-нибудь ограничения по памяти\быстродействию. Можно придумать и другие причины. В общем, вот всё это «иногда правда, а иногда нет» никак нельзя сравнивать с фундаментальными физическими законами, вроде закона Ома.
Если бы Вы внимательно прочитали оригинал (читать такой ужасный перевод, несомненно, нельзя, это понятно) то заметили бы, что Джек говорит о части закона Ома. Всего лишь о части и я это постарался перевести. «Иногда правда а иногда нет» по-любому лучше, чем всегда непонятно что, особенно если Вы понимаете ограничения применяемого метода. Можно придумать множество причин для оправдания неряшливо спроектированного и неудачно реализованного кода (шлеп шлеп и в продакшн), но, может быть, лучше потратить это время на улучшение кода.
Один из самых объективных критериев — количество строк кода. Вот только к качеству программ он не имеет никакого отношения.
Отношение к качеству — ещё фигня… оно ведь ещё и к реализации задачи не имеет никакого отношения!
Ну есть и другие числовые критерии, связанные с размером.
Например, средний размер модуля. Многие считают непрерывный код длиной более 200-300 строк просто недопустимым и требуют его разбиения на независимые единицы компиляции. И этот подход во-многом оправдан.
Так что критерии есть, конечно, их нельзя абсолютизировать, но и пренебрегать ими не стоит.
Например, средний размер модуля. Многие считают непрерывный код длиной более 200-300 строк просто недопустимым и требуют его разбиения на независимые единицы компиляции. И этот подход во-многом оправдан.
Так что критерии есть, конечно, их нельзя абсолютизировать, но и пренебрегать ими не стоит.
Инженерия — это аналитическая профессия, в которая, если все сделано правильно, все может быть проверено холодным числом.А переводы можно проверить «холодным числом»?
Если серьёзно, то спрячьте лучше статью, до тех пор пока не приведёте перевод в читабельный вид.
Да там не только с согласованием проблемы:
Я 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.» — , что можно перевести как: «Я — разработчик встраиваемых систем (Embedded Engineer), и как многие „встраиваемые“ люди, один из тех, кто провел последние четыре десятилетия между проектированием схем и написанием кода для устройств.»
При всем уважении, перевести ЕЕ как Embedded Engineer, это взять на себя определенные риски. Не менее распространенное сокращение Electonics Engineer ( от IEEE — Institute of Electrical and Electronics Engineers) и лично я не возьму на себя смелость утверждать, какой именно смысл вложил в сокращение Джек, особенно учитывая слово embedded в том же предложении. Что касается кавычек при слове встроенный, то в оригинале их нет и если Вы так хотите его закавычить, то надо сопровождать примечанием переводчика на две-три фразы.Считаете это целесообразным? Конечно, на вкус все краски разные, но «люди прошивки» более точно передает суть данного термина, нежели Ваш вариант. Меня радуют люди, которые предъявляют претензии к переводу, а потом представляют подобные варианты.
Лично я стараюсь делать минимальные правки именно по той причине, что не владею английским в достаточной степени, чтобы учесть все нюансы и смыслы фразы, а вкладывать свое ее понимание в уста Джека не считаю возможным. Если бы я хотел написать свой пост на тему, навеянную постом Джека, я так бы и заявил в начале текста. Поскольку там написано перевод а не вольное изложение, я и пытаюсь сохранить максимальное подобие исходному тексту. Жаль, что большинство минусующих этого понять не в силах.
Лично я стараюсь делать минимальные правки именно по той причине, что не владею английским в достаточной степени, чтобы учесть все нюансы и смыслы фразы, а вкладывать свое ее понимание в уста Джека не считаю возможным. Если бы я хотел написать свой пост на тему, навеянную постом Джека, я так бы и заявил в начале текста. Поскольку там написано перевод а не вольное изложение, я и пытаюсь сохранить максимальное подобие исходному тексту. Жаль, что большинство минусующих этого понять не в силах.
Я прошу прощения, но одно дело, когда вы пытаетесь дать перевод, максимально близкий к оригиналу, и совершенно другое дело, когда вы даете слегка подкорректированный машинный перевод. «Недавнее статья», «в автомобильной службе отзыва», «Аппаратных сторона не прощает эмоций», «Мир программное обеспечение искажен», и т. д. И это не говоря об ужасном, ломанном языке. Прошло более половины суток с момента публикации, и вместо того, чтобы писать развернутые комменты, о том, почему вы так поступили, вы могли бы поправить эти ошибки, и сделать текст более удобоваримым. Тогда люди найдут силы дочитать до конца, и начнут задавать вопросы по существу.
Перевод — это почти всегда адаптация. Есть огромное количество терминов, которые не имеют простых аналогов в других языках. Если вы беретесь за перевод, то будьте готовы, что дословно может не получится. Соответственно главная задача — передать максимально точно смысл. В «узких» местах, если вы сомневаетесь, можно в скобках привести оригинал, тогда вам смогут подсказать в комментах, а еще лучше — обратиться к автору за пояснением, что конкретно он хотел сказать в данном месте данным речевым оборотом.
А если вы не поняли смысла, то зачем начали переводить? То что вы сделали не на много ценнее, чем публикация ссылки вида 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
Перевод — это почти всегда адаптация. Есть огромное количество терминов, которые не имеют простых аналогов в других языках. Если вы беретесь за перевод, то будьте готовы, что дословно может не получится. Соответственно главная задача — передать максимально точно смысл. В «узких» местах, если вы сомневаетесь, можно в скобках привести оригинал, тогда вам смогут подсказать в комментах, а еще лучше — обратиться к автору за пояснением, что конкретно он хотел сказать в данном месте данным речевым оборотом.
А если вы не поняли смысла, то зачем начали переводить? То что вы сделали не на много ценнее, чем публикация ссылки вида 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
То есть вы всерьез считаете, что из прочтения этого перевода (вполне возможно, не очень удачного) невозможно понять, о чем говорит Джек? Какие мысли он хочет донести своим постом? Если можно (а мне кажется, что вполне), то зачем прятать? Чтобы кто-нибудь не поставил минус? Так я, в общем-то, цель собрать побольше плюсиков и не ставил. Просто увидел интересный пост уважаемого мною человека, специалиста в данной области, и подумал, что его мысли могут представлять интерес не для меня одного. А для тех, кому будет лениво читать оригинальную заметку, попытался дать представление о ней. Жаль, что ошибся, не в смысле того, что жаль полученных минусов и (о Боже, какая трагедия) упавшей кармы (меня неделю назад вообще за пост банили, так что я переживу), а в смысле того, что проблемы, волнующие Джека, для читателей Хабра просто не существуют. Грустно, господа, грустно.
Прочитайте мой ответ на предыдущий комментарий. Да, именно, вы необычайно тонко подметили, с минимальными правками. Если я буду переводить с английского текст, написанный Вами (все может быть), я, конечно, отнесусь к нему совершенно по-другому и переведу как мне понравится, не задумываясь о смысле, который Вы вложили в свои фразы. Вряд ли стоит разъяснять причины подобного, не переходя к прямым оскорблениям. Чтобы понять, что «здесь вообще написано», обратитесь к оригиналу, и, уверяю Вас, я старался максимально точно передать именно фразу Джека. Когда предложите свой вариант, не перевирающий эту фразу, не меняющий ее построение, продолжим дискуссию.
Да ему достаточно хотя бы поправить орфографические и грамматические ошибки для этого. Запомните, при переводе вы можете оставить типичный для английского порядок слов, не учесть игру слов или что-то подобное, но надо сделать хотя бы половину работы.
Навскидку
А я разработчик встраиваемых систем, как и многие «недовстроившихся» людей, последние четыре десятилетия разрываюсь между проектированием схем для устройств и написанием кода, который будет выполняться на них. Железо не прощает эмоций и никаких идей, если это не заставляет двигаться электроны в правильном направлении. Софт же удерживает результаты в пределах норматива «а это работает?».
Навскидку
Я 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.
А я разработчик встраиваемых систем, как и многие «недовстроившихся» людей, последние четыре десятилетия разрываюсь между проектированием схем для устройств и написанием кода, который будет выполняться на них. Железо не прощает эмоций и никаких идей, если это не заставляет двигаться электроны в правильном направлении. Софт же удерживает результаты в пределах норматива «а это работает?».
Плач переводчика?
Что интересно, по сути сказанного Джеком высказался только один комментирующий. Видимо, иметь свое мнение о Agile технологиях несколько сложнее, нежели заметить и без того очевидные несовершенства перевода. Я то думал, что мне скажут о недооценке данных технологий и о блестящих идеях, в них заложенных, и постарался заранее предупредить о своем недостаточном их знании, но, видимо, переоценил степень осведомленности в Agile среднего читателя Хабра. Несколько озадачен происшедшим.
взрыв мозга
«Я — туманная мысль Джека»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Плач инженера