ВСА>Авторы: ВСА> moudrick
ВСА>Аннотация: ВСА>Если Вы программируете как большинство, и даже, вероятно, все программисты (скромненько включая автора этой статьи), то ваш код — отстой. Возможно, не целиком; возможно, не всегда, но наверняка какая-то его часть и в какой-то момент времени.
В конце оригинальной статьи указано "Comments are disabled" — всяких ругательств изначально ожидалось много, но у нас-то комменты enabled!!!
Мое мнение такое:
У автора статьи злое начальство. — он излил все то, что говорит про его код его начальство. Я в корне не согласен с таким кодовоззрением. Да, иногда, а может даже часто, приходится делать так, как описано в этой статье. Но если код выполняет свою задачу — то он уже не отстой!
Все, о чем говориться в этой статье, давно известно, но ради выполнения поставленных задач приходится чем-то жертвовать.
Часто ругают Microsoft за их изобретения, но также часто ими и пользуются. И если взглянуть на код, написанный программерами Microsoft, то он также часто несовершенен.
А переводчики в своем вольном переводе могли бы употребить вместо "отстой" — "несовершенен" — статья была бы более логична. А получилось, что то вроде "Весь мир г..но, все быба б..ди и солнце е...ный фонарь"
З.Ы: Извиняюсь за выражения
Re[4]: Как спроектировать для автомат. тестирования?
Здравствуйте, Constructor, Вы писали:
C>Блин, а я много раз проходил мимо этой книги, когда она еще лежала на полках, и даже не брал в руки. Т.к., первая появившаяся книжка Бека "экстремальное программирования" восторга не вызвала. Не думал я, что разработка через тестирование окажется нормальной технологией. Думал это из разряда "программирование парами".
Дык, она и есть из этого разряда — из разряда матодик, улучшающих результат работы программиста.
2>В конце оригинальной статьи указано "Comments are disabled" — всяких ругательств изначально ожидалось много, но у нас-то комменты enabled!!!
Если Вы хотите откоментить оригинальный текст — welcome here, там на время написания моего поста 17 коментов, и не закрыта возможность добавлять новые.
Я хотел указать именно эту линку в публикации перевода, т.к. именно она является "I'm lucky!@Google" на фразу "Why your code sucks", но автор, когда давал разрешение на публикацию перевода, он просил разместить то, что размещено. Можно также обратить внимание на разницу в датах публикации статьи в обоих блогах.
2>Мое мнение такое: 2>У автора статьи злое начальство. — он излил все то, что говорит про его код его начальство. Я в корне не согласен с таким кодовоззрением. Да, иногда, а может даже часто, приходится делать так, как описано в этой статье.
Спасибо За Ваш превосходый неологизм — кодовоззрение. Ёмкое и правильное слово.
2>Но если код выполняет свою задачу — то он уже не отстой!
Если код работает — это говорит лишь о том, что он, возможно, все-таки не отстой. Но для того, чтобы код не был отстоем, его бесперебойной работы недостаточно. Формальная логика с модальностью возможности.
2>Все, о чем говориться в этой статье, давно известно, но ради выполнения поставленных задач приходится чем-то жертвовать.
Статья написана для тех, кому это неизвестно, из-за чего они искренне полагают, что их код является достойным. Статья призвана несколько развенчать эти пагубные убеждения.
Статья написана также для тех, кто это знает, но ничего с этиим не делает — как стимул искать эффективные пути сделать код не-отстоем.
Я приведу выдержку из письма к RSDN Group с предложением этого перевода к публикации.
...посвященную особенностям кодирования при использовании практик и методик быстрой (гибкой, agile) разработки ПО. Эта статья предназначена в первую очередь для тех, кто собирается начать использовать agile-процесс в своих проектах. Думается, однако, что она поможет по новому взглянуть на вещи также и тем, кто уже пользуется agile-методикой. Надеемся, что она будет полезна и другим читателям, в том числе сторонникам традиционных методик.
Статья написана в достаточно провокационной и бросающей вызов форме. Однако для того чтобы начать работать в духе agile, надо ломать многие из устоявшихся стереотипов, и такая форма призвана облегчить отказ от порочных практик, которые себя не оправдывают, и привить использование других, более надежных практик.
Видимо, эти и другие приведенные агрументы оказались достаточными, и перевод был принят к публикации. Причем асболютно правильно, что эти агрументы не были поставлены как преамбула к переводу. Статья должна больно ударить ремнём по мягкому месту и поставить в угол для размышлений о том как исправиться. Думаю, что а-постериори можно поместить эту смягчающую формулировку, чтобы немного уменьшить количество ответных постов типа "сам дурак", ибо эффект внезапности уже не потерялся (если, конечно не читать сперва коменты перед статьёй. Но мне думается, что большинство сперва все таки прочтут саму статью, именно багодаря её провокационному названию)
2>А переводчики в своем вольном переводе могли бы употребить вместо "отстой" — "несовершенен" — статья была бы более логична.
Перевод не является вольным. Он действителньно содержал много вольностей в том варианте, что мы использовали для себя. Но благодаря редколлегии все вольности в переводе были устранены еще до публикации.
Здравствуйте, moudrick, Вы писали:
M>Перевод не является вольным. Он действителньно содержал много вольностей в том варианте, что мы использовали для себя. Но благодаря редколлегии все вольности в переводе были устранены еще до публикации.
Да я согласен с переводом, да и сам не нашел более подходящего перевода для sucks, соответствующего духу статьи.
M>Статья написана в достаточно провокационной и бросающей вызов форме. Однако для того чтобы начать работать в духе agile, надо ломать многие из устоявшихся стереотипов, и такая форма призвана облегчить отказ от порочных практик, которые себя не оправдывают, и привить использование других, более надежных практик.
Меня возмутила эта вызывающая форма. Хотя, возможно, это один из немногих способов продвинуть идеи eXtreme Programming среду существующих методик.
M>Видимо, эти и другие приведенные агрументы оказались достаточными, и перевод был принят к публикации. Причем асболютно правильно, что эти агрументы не были поставлены как преамбула к переводу. Статья должна больно ударить ремнём по мягкому месту и поставить в угол для размышлений о том как исправиться. Думаю, что а-постериори можно поместить эту смягчающую формулировку, чтобы немного уменьшить количество ответных постов типа "сам дурак", ибо эффект внезапности уже не потерялся (если, конечно не читать сперва коменты перед статьёй. Но мне думается, что большинство сперва все таки прочтут саму статью, именно багодаря её провокационному названию)
Я следую большинству наставлений Макконнелла, поэтому меня заинтересовал заголовок статьи — эффект удался!
M>>Перевод не является вольным. Он действителньно содержал много вольностей в том варианте, что мы использовали для себя. Но благодаря редколлегии все вольности в переводе были устранены еще до публикации.
2>Да я согласен с переводом, да и сам не нашел более подходящего перевода для sucks, соответствующего духу статьи.
Здравствуйте, moudrick, Вы писали:
M>>>В любой мало-мальски приличной среде программирования для любого мало-мальски приличного ОО языка имеются средства сделать это немедленно в одно движение. K>>Visual Studio 2005 — мало-мальски приличная? M>Мне очень жаль, но, учитывая то, что для С++ там нет рефакторинга "Encapsulate field", VS2005 для С++ не является сколько-нибудь приличной.
Для вас.
M>Чтобы сделать VS2003/2005 более приличной для С++, рекомендую отличную тулзу — Ref++, где есть "Encapsulate member variable..."
Я про нее знаю, спасибо.
M>Отчего же, продолжайте. Какие именно слова Александреску должны убедить меня догматично следовать вышеуказанному правилу?
Ладно, это я на личности уже перехожу, похоже — извините. Меня просто покоробило сравнение с детьми, особенно с учетом того, что очень многие переходят на .Net с C++. Большинство из них не может сразу сдвинуть мозг так, чтобы он воспринял рефакторинг как нечто само-собой разумеющееся.
Александреску с Саттером, если я правильно помню, говорили о том, что поля должны быть открытыми только у классов без поведения. Если класс имеет поведение, то поля должны быть приватными и поведение эти поля должно использовать. При этом делать для полей геттеры/сеттеры совершенно необязательно, больше того делать это не рекомендуется, потому как наружу выносится информацию о состоянии, для инкапсуляции которой и был создан класс.
If a shark stops swimming, it will die. Don't stop swimming, Mr. Mulder.
Every epic equalizer is iso (c)
Здравствуйте, 2garin, Вы писали:
M>>Статья написана в достаточно провокационной и бросающей вызов форме. Однако для того чтобы начать работать в духе agile, надо ломать многие из устоявшихся стереотипов, и такая форма призвана облегчить отказ от порочных практик, которые себя не оправдывают, и привить использование других, более надежных практик.
2>Меня возмутила эта вызывающая форма. Хотя, возможно, это один из немногих способов продвинуть идеи eXtreme Programming среду существующих методик.
M>>Перевод не является вольным. Он действителньно содержал много вольностей в том варианте, что мы использовали для себя. Но благодаря редколлегии все вольности в переводе были устранены еще до публикации.
2>Да я согласен с переводом, да и сам не нашел более подходящего перевода для sucks, соответствующего духу статьи.
В варианте для нашего личного использования у нас был прямой глагольный перевод, который звучал так — "Почуму ваш код сосёт". Или даже — "Почему твой код сосёт". Но такая грубость, конечно, неприемлема на " the best russian-languaged resource for developers", как я описал RSDN в письме с запросом к автору на публикацию перевода.
Скорее всего и этот вариант будет опубликован.
В моём блоге.
Если ничто не помешает этому.
В частности, если не будет возражать The RSDN Group. А она скорее всего не будет возражать.
Когда и если это случится, я обязательно объявлю это здесь. Приходите ругаться.
Здравствуйте, moudrick, Вы писали:
M>>>Перевод не является вольным. Он действителньно содержал много вольностей в том варианте, что мы использовали для себя. Но благодаря редколлегии все вольности в переводе были устранены еще до публикации.
2>>Да я согласен с переводом, да и сам не нашел более подходящего перевода для sucks, соответствующего духу статьи.
M>В варианте для нашего личного использования у нас был прямой глагольный перевод, который звучал так — "Почуму ваш код сосёт". Или даже — "Почему твой код сосёт".
Нормальная реакция нормального человека на такое обращение "а не пошел бы ты на*** со своим поучениями"
M>>В варианте для нашего личного использования у нас был прямой глагольный перевод, который звучал так — "Почуму ваш код сосёт". Или даже — "Почему твой код сосёт".
FR>Нормальная реакция нормального человека на такое обращение "а не пошел бы ты на*** со своим поучениями"
Предложи, пожалуйста, свой вариант перевода "Why Your Code Sucks"
M>>>>В любой мало-мальски приличной среде программирования для любого мало-мальски приличного ОО языка имеются средства сделать это немедленно в одно движение. K>>>Visual Studio 2005 — мало-мальски приличная? M>>Мне очень жаль, но, учитывая то, что для С++ там нет рефакторинга "Encapsulate field", VS2005 для С++ не является сколько-нибудь приличной. K>Для вас.
Боюсь, что не только для меня, но я для всех, у кого рефактринг является постоянной практикой.
M>>Отчего же, продолжайте. Какие именно слова Александреску должны убедить меня догматично следовать вышеуказанному правилу?
K>Ладно, это я на личности уже перехожу, похоже — извините. Меня просто покоробило сравнение с детьми, особенно с учетом того, что очень многие переходят на .Net с C++. Большинство из них не может сразу сдвинуть мозг так, чтобы он воспринял рефакторинг как нечто само-собой разумеющееся.
Прошу извиненияу всех, кого задели мои слова и/или текст перевода статьи.
Я искренне уважаю каждого человека, каждого разработчика, каждую методику разработки.
Но иногда все-таки нужен хороший пинок, чтобы увидеть очевидное.
А чтобы его дать — нужно некое дерзновение, не все на него отваживаются.
Вот также цитата из детской книжки, которая частично применима и в нашей ситуации... хотя там все намного хуже...
K>Александреску с Саттером, если я правильно помню, говорили о том, что поля должны быть открытыми только у классов без поведения. Если класс имеет поведение, то поля должны быть приватными и поведение эти поля должно использовать. При этом делать для полей геттеры/сеттеры совершенно необязательно, больше того делать это не рекомендуется, потому как наружу выносится информацию о состоянии, для инкапсуляции которой и был создан класс.
Я не читал Александреску/Саттера. Не знаю даже, к сожалению или к счастью.
Наверняка имеется в виду очень хорошая и полезная книга.
Но я сильно подозреваю, что там описаны рекомендации для написания кода,
которому никогда не потребуется мало-мальски заметный рефакторинг.
Но в реальной жизни так не бывает. Опять таки, не знаю — к сожалению или к счастью.
M>>>>Перевод не является вольным. Он действителньно содержал много вольностей в том варианте, что мы использовали для себя. Но благодаря редколлегии все вольности в переводе были устранены еще до публикации.
2>>>Да я согласен с переводом, да и сам не нашел более подходящего перевода для sucks, соответствующего духу статьи.
M>>В варианте для нашего личного использования у нас был прямой глагольный перевод, который звучал так — "Почуму ваш код сосёт". Или даже — "Почему твой код сосёт".
FR>Нормальная реакция нормального человека на такое обращение "а не пошел бы ты на*** со своим поучениями"
Смотрите линку на цитату из детской книги в моём посте
Здравствуйте, moudrick, Вы писали:
M>Боюсь, что не только для меня, но я для всех, у кого рефактринг является постоянной практикой.
У большей части программистов на С++, имхо, такая практика не является постоянной...
M>Прошу извиненияу всех, кого задели мои слова и/или текст перевода статьи.
И статья тут не причем В статье правильно все.
M>Я не читал Александреску/Саттера. Не знаю даже, к сожалению или к счастью.
Если писали на С++, то к сожалению.
M>Но я сильно подозреваю, что там описаны рекомендации для написания кода, M>которому никогда не потребуется мало-мальски заметный рефакторинг.
Это, собственно говоря, одна из целей, к которой стремится любой уважающий себя разработчик ПО
M>Но в реальной жизни так не бывает. Опять таки, не знаю — к сожалению или к счастью.
"Но иногда все-таки нужен хороший пинок" (с), чтобы начать писать такой код Рефакторинг позволяет приводить существующий код к такому виду. Конечная цель использования рефакторинга — осутствие в нем необходимости.
If a shark stops swimming, it will die. Don't stop swimming, Mr. Mulder.
Every epic equalizer is iso (c)
M>>Но я сильно подозреваю, что там описаны рекомендации для написания кода, M>>которому никогда не потребуется мало-мальски заметный рефакторинг.
K>Это, собственно говоря, одна из целей, к которой стремится любой уважающий себя разработчик ПО
M>>Но в реальной жизни так не бывает. Опять таки, не знаю — к сожалению или к счастью.
K>"Но иногда все-таки нужен хороший пинок" (с), чтобы начать писать такой код Рефакторинг позволяет приводить существующий код к такому виду. Конечная цель использования рефакторинга — осутствие в нем необходимости.
Перепрошую. В реальной жизни начиная с некоторого момента требования к ПО изменяются быстрее, чем пишется его код. Потому имхо будущее большинства успешных продуктов — перманентный рефакторинг, ибо единственный приемлемый способ учитывать изменяющиеся требования к продукту. Каждый раз все с самого начала не напишешь.
Т.е. рефакторить придется не потому что плохо рабоатет, а потому что надо быстро сделать так, чтобы учесть изменившиеся требования.
Вопрос по неотстойному написанию: допустим мне нужно написать код перемножения двух матриц.
Я могу его написать 4 функциями, соответствующими AijBjk; AjiBjk; AijBkj; AjiBkj;
Но это будет дублирование кода, причём почти copy-paste — то есть код — отстой
Я могу написать его 1 функцией, с такими параметрами MatrixMul(A, B, TransposeA, TransposeB), заставив передавать в функцию параметры транспонирования матрицы — но это не удобно для использования
Можно вообще написать только внутреннее произведение и транспонировать матрицу — это не эффективно.
А теперь представим себе, что это не просто матрица, а часть другой матрицы (это не надуманная задача). Тогда к каждой функции ещё надо будет прибавлять по два параметра —
начальные и конечные индексы суммирования.
Этот код будет не читаемым и трудно написуемым — убедился на собственном опыте. И как это сделать не отстойно?
В итоге я прихожу к самому удобному (я не шучу, я так и делал) варианту — когда нужно что-то перемножать я просто пишу код этого перемножения (цикл с двукратной вложенностью) прямо в код, без всяких вызовов. Получается, что с небольшими комментариями этот код — самый удобный для написания и чтения (ну, лично для меня) и вызывает наименьшее число ошибок в использовании (собственно, ошибки в использовании функции перемножения перестали появляться вообще).
Дык, во всех вариантах код — отстой. Во всех, я сам убедился (судя по этой статье). Может кто знает другой вариант?
Здравствуйте, anvaka, Вы писали:
A>Здравствуйте, FDSC, Вы писали:
FDS>>[..] Вот что с этим кодом делать — вот вопрос. [..]
A>Вопрос риторический ?
Это не вопрос. А если принимать как вопрос, то самый серьёзный, который обсуждается, с тех пор, как появился процесс кодирования.
A>Я извиняюсь, что лезу с банальным ответом.
За ответы всегда спасибо. Для меня банальные ответы иногда очень ценны.
A>Предлагаю не панацею, но хорошее средство: Совершенный код
. Уверяю, мне помогло и продолжает помагать, хотя... все равно мой код несовершенен
Тут вопрос в том, что никогда не получается следовать этим рекомендациям. К тому же, для разных языков не получается это по разному . Поэт., такие книги обычно бесполезны, по крайней мере для меня — я остро чуствую что пишу плохой код сам, а когда читаю такие книги — начинаю просто заваливать задания, потому что там нужно искать компромис между тем, что написано в книге и реальной жизнью, а тому, кто может его удачно найти такие книги уже не нужны.
К тому же в одних проектах эти рекомендации могут оказаться прекрасными, а в других — ужасными. Важно ведь ещё и сроки выполнения и то, что код, возможно, всё равно придётся потом сильно переделывать и т.п.
Здравствуйте, 2garin, Вы писали:
M>>>В варианте для нашего личного использования у нас был прямой глагольный перевод, который звучал так — "Почуму ваш код сосёт". Или даже — "Почему твой код сосёт".
FR>>Нормальная реакция нормального человека на такое обращение "а не пошел бы ты на*** со своим поучениями"
2>Предложи, пожалуйста, свой вариант перевода "Why Your Code Sucks"
Не знаю
Может на западе у них нормально человека поучать через оскорбление, но мы похоже для таких высот демократии еще не дозрели.
Здравствуйте, moudrick, Вы писали:
FR>>Нормальная реакция нормального человека на такое обращение "а не пошел бы ты на*** со своим поучениями"
M>Смотрите линку на цитату из детской книги в моём посте
Здравствуйте, FR, Вы писали:
FR>Может на западе у них нормально человека поучать через оскорбление, но мы похоже для таких высот демократии еще не дозрели.
Да, у нас за такие способы и по морде можно получить. И вообще, это не хорошо — получается автор статьи сразу ставит себя очень высоко — никто этого не любит, поэтому можно ждать очень много неконструктивной критики (в частности).
— он излил все то, что говорит про его код его начальство. Я в корне не согласен с таким кодовоззрением. Да, иногда, а может даже часто, приходится делать так, как описано в этой статье. Но если код выполняет свою задачу — то он уже не отстой!
. Поэт., такие книги обычно бесполезны, по крайней мере для меня — я остро чуствую что пишу плохой код сам, а когда читаю такие книги — начинаю просто заваливать задания, потому что там нужно искать компромис между тем, что написано в книге и реальной жизнью, а тому, кто может его удачно найти такие книги уже не нужны.