Аннотация:
Если Вы программируете как большинство, и даже, вероятно, все программисты (скромненько включая автора этой статьи), то ваш код — отстой. Возможно, не целиком; возможно, не всегда, но наверняка какая-то его часть и в какой-то момент времени.
Первое — тестирование. Банальности. Да, мы все отлично знаем, что код, не подвергаемый систематическому тестированию с большой вероятностью содержит кладезь багов. Да, понятно, что для того, чтобы код "тестировался", его нужно тестировать. Понятно, что нужны соответствующие инструменты и т.п. В результате: с умным видом ткнули читателя носом в банальность, т.е. — косвенно предположили его априорную тупость.
Второе — читабельность. Апелляция к субъективному. То, что прекрасно читается одними вызывает оторопь у других. Где критерии оценки читабельности? И уж тем более, что это за хрень такая: "понятность"?
Третье — framework. Сплошная риторика. Действенные критерии выбора не приведены, в результате рекомендации можно повернуть и так и эдак — зависит от способностей к риторике. В самом деле: и лёгкий и тяжёлый framework делают одну и ту же работу, но и тот и другой имеют свои плюсы и минусы. И надо же! Действительно, нужно взвешивать плюсы и минусы перед принятием решения. Падаю ниц!
Очередная констатация очевидного: если можно чего-то не делать, то это и не обязательно делать. Спасибо, автор, просветил!
Рассуждения про business-value лишены обоснования: что такое business-valued-код? Создаётся впечатление, что автор владеет каким-то мегазнанием, которым не делится с читателями. Отсюда вопрос: а что это за знание? Или это опять buzzword, вставленное для придания веса своим рассужденям?
Четвёртое — дублирование. Мегабанальная вещь, ибо это есмь альфа и омега программирования. Если бы люди не боролись с дублированием, языков высокого уровня попросту бы не было. Такая борьба должна быть в ДНК у програмистов. Ша! Я сказал — у программистов! К тому же в противовес рассужденям о вреде дублирования можно привести не менее абстрактные рассуждения, что, мол, иногда дублирование необходимо, поскольку не ясно, как программа будет развиваться дальше: порой преждевременное склеивание абстракций приносит не меньше головной боли, чем copy&paste.
Вывод: незачёт. Много слов, почти ни одно собственного. Осторожненько так пнули большие framework-и, да и всё. На пересказе общеизвестных истин можно до некоторой степени прославиться, ну и что?
Вопрос к RSDN Team: такого добра в блогах — пруд пруди, на фига было тратить время на перевод? Эти рассуждения вполне приемлемы для блоготворчества, где можно быстро вычислить контекст, но в качестве отдельной статьи... Прежде всего — очевидное неуважение к читателям: читатели должны мысленно разбираться со стереотипами и buzzwords, свойственными приверженцам определённого стиля разработки, которые при очередной "смене парадигмы" узнали, что 2x2=4 и несут окружающим сокровенный свет этого знания.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Владислав Сивяков, Алексей Мудрик (перевод), Вы писали:
Просто убийственная статья. Очень напоминает по стилю одну книжку по XP которая мне попалась(названия я не помню). Авторы пытаются сказать — дядька, там хорошо. Там коммунизъм, кисельные берега, молочные реки, серебрянные пули летают. Делай так как тебе сказали, и все будет. Будешь лежать на солнышке в районе Гавайев, не то что остальные. Остальные просто не понимают счастья. Остальные это просто Succs. Забыли просто одну маленькую весчь, доказать. Я хоть и не апологет XP, имел счатье поработать на нем немного времени, и в целом этот подход мне нравится. Хотя он и не без недостатков.
Немного пройдусь по статье:
Первая же глава: ваш код не работает потому что нет тестов. Пурга еще та. Утверждение что если код не работает это плохо, я скромно не буду оспаривать. Но то что если нет тестов то следовательно код не работает, то тут уж позвольте. Большая часть кода используемая в мире написана без тестов. Следовательно они не работают. Не всегда возможно построить тесты, и нельзя построить полные тесты. Тесты нельзя построить если есть зависимость от внешней среды которой нет под рукой. То следовательно, получается что для таких случаев нельзя построить работающий код.
Есть и другой аспект для того же утверждения. Если есть тесты, то все равно нет гарантии что код работает. Нельзя построить полные тесты потому что для это огромная задача значительно более сложная чем написание самого кода. Возьмем тестирование черного ящика. У нас есть функция, которая имеет 10 параметров, в которых может быть 10 значений. Соответсвенно для полного тестирования нам нужно выполнить 10 в 10 степени тестов. Сомневаюсь что это возможно. А если параметр вещественный, то вообще беда. Для этого можно построить вероятностные тесты с граничными условиями, но говорить о том, что оно точно и доказанно все работает — нельзя. С тестированием белого ящика, все не менее худо. Там вероятностное тестирование путей выполнения. Единственное исключение, для "чистых функциональных" языков можно доказать то, что код полностью работающий. Но это статья не о "чистых функциональных" языках, это статья пропогандирующая TDD. Тесты могут повысить работоспособность кода, но не решить полностью проблему. Тесты также помогают пониманию задачи. Но такое сильно утверждение как в статье не более чем пропаганда.
Глава про то, что код отстой если он не поддается тестированию — уже объяснил, если бы не одно но. Что подразумевается под кодом поддающимся тестированию. Фактически, код может быть подвергнуть тестированию, если он имеет адекватный интерфейс в котором каждый класс(модуль, функция) выполняет одну логическую единицу функциональности. У классов эта единица функциональности потолще, у функций эта единица потоньше. Если код не поддается тестированию, то его можно смело отнести к категории бардака. А существуют в реальности на него тесты, или не существуют — это дело десятое.
Главы о трудности прочитки кода. Ну да. Стремление к простым решениям за счет потери эффективности похвально, но не показано почему. (хотя обычно простые решения наиболее эффективны, вся сложность найти именно это простое решение). На сайте уже есть прекрасная статья Оптимизация – ваш злейший враг
.
Главу про framework даже комментировать не стану. Это глава ни о чем.
Глава про дублирование. Интересная зарисовка, уж не знаю откуда они взяли такую классификацию. Особенно временное дублирование. Судя по всему, упомянутую книжку Рефакторинг Фаулера они не читали. Там временное дублирование функций — очень даже нормальная практика. Оптимизация выполнения — только в конце, а понятность кода первична.
Про выводы — пропаганда. Вобщем, мое личное IMHO тесты делать очень даже полезно, писать понятный, сопровождаемый код тоже весьма полезная вещь, читать такие статьи — бесполезно и вредно. Лучше прочитать нормальную книжку по ООD + refactoring.
ВСА>Авторы: ВСА>Владислав Сивяков, Алексей Мудрик (перевод)
ВСА>Аннотация: ВСА>Если Вы программируете как большинство, и даже, вероятно, все программисты (скромненько включая автора этой статьи), то ваш код — отстой. Возможно, не целиком; возможно, не всегда, но наверняка какая-то его часть и в какой-то момент времени.
Медузы, — сказала она горько. — Скользкие глупые медузы. Копошатся, ползают, стреляют, сами не знают чего хотят, ничего не умеют, ничего по-настоящему не любят... как черви в сортире...
...Сегодня уже все знают, что есть человек. Что с человеком делать — вот вопрос. Да и то, признаться, уже навяз на зубах
(братья Стругацкие)
Переформулируя можно сказать — мы все уже давно знаем, что наш код — отстой. Вот что с этим кодом делать — вот вопрос. Да и то, признаться, уже навяз на зубах
ВСА>Авторы: ВСА>Владислав Сивяков, Алексей Мудрик (перевод)
ВСА>Аннотация: ВСА>Если Вы программируете как большинство, и даже, вероятно, все программисты (скромненько включая автора этой статьи), то ваш код — отстой. Возможно, не целиком; возможно, не всегда, но наверняка какая-то его часть и в какой-то момент времени.
Набор слов без пояснения, доказательств, выводов... Цена такой статье = 0.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>.. должна быть в ДНК у програмистов. Ша! Я сказал — у программистов!
хм, т.е. родился программистом и учиться уже ничему не надо? класс...
ГВ>Вопрос к RSDN Team: такого добра в блогах — пруд пруди, на фига было тратить время на перевод?
ну, RSDN Team её и не переводил, и без нас нашлись желающие. А опубликовали потому что статья эта — хороший пинок в направлении к дяденьке Макконнеллу
.
ГВ>Прежде всего — очевидное неуважение к читателям: читатели должны мысленно разбираться со стереотипами и buzzwords, свойственными приверженцам определённого стиля разработки, которые при очередной "смене парадигмы" узнали, что 2x2=4 и несут окружающим сокровенный свет этого знания.
ну и почему мы должны руководствоваться именно этим мнением, а не мнением двух десятков (сейчас) человек, которые не поленились поставить статье положительную оценку
Здравствуйте, Владислав Сивяков, Алексей Мудрик (перевод), Вы писали:
ИМХО совершенно идиотская статья. Идиотская по многим причинам.
Во-первых, автор ничему не учит, ничего не доказывает, не объясняет. Нет. Он говорит — "Вы все дебилы, один я умный. Айда за мной!". Мне не очень нравится когда мне такое говорят
Во-вторых, автор глубоко убеждён что тестирование это панацея. Ну можно было бы отшутится на тему, "серебрянных пуль нет" или ещё что-нибудь такое банальное сказать, но в данном случае можно и конкретне. Всерьёз считать, что тестирование кода действительно улучшает код это полный бред. Начать с того, что очень маленький объём кода поддаётся автоматическому тестированию. Например, недавний мой баг — в текстовом редаторе, если выделять строку и следующая строка короче выделяемой, то выделение рисуется неправильно. Может я что-то в этой жизни упустил, но я себе совершенно не представляю как можно отследить подобную ошибку автоматически. Зато человеком она была найдена меньше чем за минуту. Хотя нет, можно было бы в момент отрисовки заполнять некоторой массив параметрами форматирования символов и потом проверять, что выделенные символы отформатированные правильно. А проверяли бы мы это той самой неправильной функцией, которая до этого неправильно эти параметры установила. Вот мы и подошли к следующему тезису — юнит-тесты должны быть крайне простыми иначе нам потребуются юнит-тесты для юнит-тестов. Более того, даже написание простых тестов отнимает время и силы.
Пользуюсь ли я юнит-тестами? Конечно нет! Правильно ли я сложил два числа я проверять не буду, я в себе уверен. А найти и исправить руками действительно сложную ошибку гораздо проще и быстрее, чем ломать голову над написанием теста. Многие скажут, а если ошибка вернётся? Ведь придётся заново её искать и исправлять. Ну что же, если у вас в проекте не ошибки, а птицы-фениксы, значит у вас серьёзные проблемы с архитектурой. Правильная архитектура в гораздо большей степени способствует уменьшению количества ошибком, нежели юнит-тесты, а неправильную никакие юнит-тесты не спасут.
В-третьих, про фреймворки идёт совершенно бессмысленный набор слов. Автор просто не знал что хочет сказать, но очень хотелось на эту тему поговорить. Слово "модный" полностью раскрыло полное непонимание механизма выбора библиотек. Модный это не аргумент для программиста, оставьте это маркетологам. Распространённый, документированный — вот аргументы. Меня совершенно не интересует мода, но между плохой библиотекой, которую знаю 100 человек и хорошей, которую знает 3 лучше выбрать плохую. Лучше, потому что когда и о второй библиотеке будут знать 100 человек она тоже будет казаться нам плохой. Но уже как-то по своему. А про глюки первой библиотеки мы уже хорошо знаем. Извечный пример MFC — библиотека по современным меркам так себе, но зато какой накоплен опыт!
Здравствуйте, moudrick, Вы писали:
FR>>>Может на западе у них нормально человека поучать через оскорбление, но мы похоже для таких высот демократии еще не дозрели.
FDS>>Да, у нас за такие способы и по морде можно получить. И вообще, это не хорошо — получается автор статьи сразу ставит себя очень высоко — никто этого не любит, поэтому можно ждать очень много неконструктивной критики (в частности).
M>Не ставит. Читай преамбулу:
M>
ВСА>>Аннотация:
ВСА>>Если Вы программируете как большинство, и даже, вероятно, все программисты (скромненько включая автора этой статьи), то ваш код — отстой. Возможно, не целиком; возможно, не всегда, но наверняка какая-то его часть и в какой-то момент времени.
Если этот человек бросился учить кого-то, значит он ставит себя выше других. По крайней мере, если он это делает такими методами. И преамбулы тут не помогут.
Обратите внимание на забавную вещь. Содержание статьи — банальные мысли, которые высказывались не раз, в контексте рефакторинга, в контексте методологии XP, и в общих работах по разработке ПО. Но там против них никто не протестовал (наверное даже многие их не заметили). А стоило обернуть их в такую форму, как поднялась жаркая дискуссия Поздравляю, старый способ привлечь внимание сработал на вас. По такому же принципу работает передача "Окна", куча рекламы, полит.агитации, желтая пресса, психологические тренинги т.д.
a>Он говорит — "Вы все дебилы, один я умный. Айда за мной!".
Давай перефразируем по пунктам:
— код должен работать
— надо стараться разбивать систему так, чтобы как можно больше её частей тестировались автоматически
— код должен быть читабельным
— код должен быть понятным
— надо думать своей головой, а не тупо следовать методологии
— устраняйте дублирование (рефакторинг)
Разве тут что-то странное или новое? Но напиши статью по этим пунктам, и все скажут "ну и что? мы это и так знаем".
SS>>Согласен, мой код — отстой, согласно определениям статьи. И что дальше?
ANS>Дочитать статью до конца? Ответ в разделе "Итог".
Читал. Похоже на то, как если бы мне сосед сказал: "Знаешь, у тебя проблема с женой".
Не его это дело, какой у меня код, потому что у него нет проблем с моим кодом.
А то, что мой код — отстой, согласно определениям статьи, я не считаю своей проблемой.
>Если Вы программируете как большинство, и даже, вероятно, все программисты (скромненько включая автора этой статьи), то ваш код — отстой. Возможно, не целиком; возможно, не всегда, но наверняка какая-то его часть и в какой-то момент времени.
про статью можно сказать цитатой из неё же самой: "этот код — отстой"
Здравствуйте, moudrick, Вы писали:
M>>>Перевод не является вольным. Он действителньно содержал много вольностей в том варианте, что мы использовали для себя. Но благодаря редколлегии все вольности в переводе были устранены еще до публикации.
2>>Да я согласен с переводом, да и сам не нашел более подходящего перевода для sucks, соответствующего духу статьи.
M>В варианте для нашего личного использования у нас был прямой глагольный перевод, который звучал так — "Почуму ваш код сосёт". Или даже — "Почему твой код сосёт".
Нормальная реакция нормального человека на такое обращение "а не пошел бы ты на*** со своим поучениями"
Здравствуйте, S-SH, Вы писали:
SS>>>Согласен, мой код — отстой, согласно определениям статьи. И что дальше?
ANS>>Дочитать статью до конца? Ответ в разделе "Итог".
SS>Читал. Похоже на то, как если бы мне сосед сказал: "Знаешь, у тебя проблема с женой". SS>Не его это дело, какой у меня код, потому что у него нет проблем с моим кодом. SS>А то, что мой код — отстой, согласно определениям статьи, я не считаю своей проблемой.
Да, это не его проблема. Это проблема того, кто Ваш код будет сопровождать/дорабатывать/изменять. Возможно, им окажетесь со временем Вы.
Если вы на 101,74% уверены, что Ваш код никогда не будет подвергаться сопровождению/доработке/изменению, то тогда статья и её контент не касаются этого кода.
Здравствуйте, adontz, Вы писали:
IT>>Но, в тоже самое время, есть задачи, которые просто немыслимы без юнит тестов, даже если их наличие существенно влияет на стоимость проекта.
A>Чисто для самообразования , это какие, например?
Код, на котором базируется другой код. Всякие движки, фреймворки, библиотеки. Порой, казалось бы, совершенно невинное изменение такого кода может привести к самым причудливым результатам у конечного пользователя.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Судя по этому абзацу у тебя у самого неверное представление зачем нужны юнит тесты. Их задача не найти ошибку в твоём коде, а не дать возможности сломать уже работающий и отлаженный код при будущих его модификациях. И чем больше покрытие кода юнит тестами, тем больше шансов уберечься от подобных проблем.
Это один из подходов. В XP на юнит-тестах именно отлаживаются. Но это всё не важно, это мелочи.
Вопрос в том как проверять работоспособность произвольного кода? И что гораздо важнее где грань после которой написание и поддержка автоматического тестирования более трудоёмко, чем ручное тестирование?
Если бы юнит-тесты были панацеей, то профессия тестировщика (QA Engineer) уже давно канула бы в лету, но нет, они живы-здоворы и неплохо зарабатывают Что, тестеров нанимают только те, кто не умеет пользоватся юнит-тестами? А может надо признать что тезис "код не проходящий регулярное юнит-тестирование — отстой" сам является отстоем?
Здравствуйте, Odi$$ey, Вы писали:
OE>ну и почему мы должны руководствоваться именно этим мнением, а не мнением двух десятков (сейчас) человек, которые не поленились поставить статье положительную оценку
Здравствуйте, moudrick, Вы писали:
L_S>>Набор слов без пояснения, доказательств, выводов... Цена такой статье = 0.
M>А свои мозги, чтобы делать выводы, мы уже не умеем применять?
M>Пояснений же в статье достаточно, только они достаточно компактны, и оттого производят на непосвященного впечатление их отсутствия.
M>Статья призвана обнажить проблему во всей ее красе, а выбрать путь ее разрешения — это дело целой серии книг. И не одной серии.
Статья отстой, цена == 0.
Какой то сборник прописных истин и не более того. Какую проблему она поднимает, какую проблему может поднять заповедь не укради . Может сдесь, кто-то и нашел для себя в этой статье, что-то стоящее, но, как-то мало вериться. А потом, вот на таком отстое начинаеться целая пляска по раскрутке серий отстояный книг типа "как завоевать друзей и при этом остаться настоящей подругой " а философию пытаться развести на пустом месте, это первый признак не проффесионализма, так как профессионал делает, а специалист думает как ему сделать лучше и пока он думает, профессионал уже все сделал, и не важно в принципе как он сделал, главное чтобы это работало и полностью удовлетворяло заказчика, так как программирование уже давно из искуство превратилось в ремесло. Еще Генри Форд сказал: "Если я захочу нагадить конкурентам, то я им проплачу сто спечиалистов, которые приведут 1000 причин почему это нельзя делать или почему это необходимо делать именно так." Читайте классиков госпада
ВН>>>предпочитаю догматично следовать господам Саттеру и Александреску, которые утверждают что public-поля могут иметь только классы "без поведения".
M>>мы немедленно применяем рефакторинг Encapsulate Field M>>В любой мало-мальски приличной среде программирования для любого мало-мальски приличного ОО языка имеются средства сделать это немедленно в одно движение.
K>Visual Studio 2005 — мало-мальски приличная?
Мне очень жаль, но, учитывая то, что для С++ там нет рефакторинга "Encapsulate field", VS2005 для С++ не является сколько-нибудь приличной.
Чтобы сделать VS2003/2005 более приличной для С++, рекомендую отличную тулзу — Ref++, где есть "Encapsulate member variable..."
K>C++ — мало-мальски приличный OO-язык?
Это отличный мультипарадигменный (в т.ч. и объектно-ориентрированный) язык.
K>C учетом упоминания Саттера и Александреску, дальше можно не продолжать?
Отчего же, продолжайте. Какие именно слова Александреску должны убедить меня догматично следовать вышеуказанному правилу?
Здравствуйте, S-SH, Вы писали:
SS>А то, что мой код — отстой, согласно определениям статьи, я не считаю своей проблемой.
Совершенно верно. Это не ваша проблема. Вы просто создаете проблему другим. Вы сможете знаете что делает ваш код, и это не дано другим.
Сколько хороших идей было выброшено на помойку из-за плохой несопровождаемой реализации. Статья плохо объясняет что-такое плохой код, но хотя бы по тем параметрам которые даны: понятность, тестируемость, дублирование — можно сразу сказать что это плохой код.
С уважением, Gleb.
Re[3]: Тривиальная задача - как неотстойно написать?
Здравствуйте, moudrick, Вы писали:
FDS>>Можно вообще написать только внутреннее произведение и транспонировать матрицу — это не эффективно. M>Первейший вопрос от меня как работающего с тобой в паре — имеет ли значение эффективность на текущем этапе работы над задачей, учитывая ВСЁ? очень много проблеми возникает, когда начинаешь заниматься эффективностью раньше, чем она того заслуживает.
Очень много проблем (причём зачастую фатальных) возникает, когда эффективностью начинают заниматься слишком поздно.
Она заслуживает заниматься её ровно с того момента, когда в ТЗ появляется первое требование к ней, ровно как и другие требования.
ВСА>Авторы: ВСА> moudrick
ВСА>Аннотация: ВСА>Если Вы программируете как большинство, и даже, вероятно, все программисты (скромненько включая автора этой статьи), то ваш код — отстой. Возможно, не целиком; возможно, не всегда, но наверняка какая-то его часть и в какой-то момент времени.
Слепо и бездумно надерганная из классиков статья.
Лучше и полезней прочесть того же Макконнелла.
ВСА>Авторы: ВСА> moudrick
ВСА>Аннотация: ВСА>Если Вы программируете как большинство, и даже, вероятно, все программисты (скромненько включая автора этой статьи), то ваш код — отстой. Возможно, не целиком; возможно, не всегда, но наверняка какая-то его часть и в какой-то момент времени.
В конце оригинальной статьи указано "Comments are disabled" — всяких ругательств изначально ожидалось много, но у нас-то комменты enabled!!!
Мое мнение такое:
У автора статьи злое начальство. — он излил все то, что говорит про его код его начальство. Я в корне не согласен с таким кодовоззрением. Да, иногда, а может даже часто, приходится делать так, как описано в этой статье. Но если код выполняет свою задачу — то он уже не отстой!
Все, о чем говориться в этой статье, давно известно, но ради выполнения поставленных задач приходится чем-то жертвовать.
Часто ругают Microsoft за их изобретения, но также часто ими и пользуются. И если взглянуть на код, написанный программерами Microsoft, то он также часто несовершенен.
А переводчики в своем вольном переводе могли бы употребить вместо "отстой" — "несовершенен" — статья была бы более логична. А получилось, что то вроде "Весь мир г..но, все быба б..ди и солнце е...ный фонарь"
З.Ы: Извиняюсь за выражения
Здравствуйте, FR, Вы писали:
FR>Может на западе у них нормально человека поучать через оскорбление, но мы похоже для таких высот демократии еще не дозрели.
Да, у нас за такие способы и по морде можно получить. И вообще, это не хорошо — получается автор статьи сразу ставит себя очень высоко — никто этого не любит, поэтому можно ждать очень много неконструктивной критики (в частности).
Здравствуйте, moudrick, Вы писали:
ВН>>Интересная статья. Однако предпочитаю догматично следовать господам Саттеру и Александреску, которые утверждают что public-поля могут иметь только классы "без поведения". У них достаточно подробно расписано, почему лучше делать так. В частности, для целей отладки/тестирования и соблюдения инвариантов.
M>Господа, ну что вы прям как дети, извините...
M>Как только public/protected (or other non-private) поле M>становится непрозрачным для чтения и/или записи, M>мы немедленно применяем рефакторинг Encapsulate Field
M>В любой мало-мальски приличной среде программирования для любого мало-мальски приличного ОО языка имеются средства сделать это немедленно в одно движение.
Ага, в одно движение оббегаете несколько отделов. Спрашиваете у каждого, а не использует ли он Ваш класс в своём проекте. Переспрашиваете его ещё раз, что бы повысить достоверность. Потом в одно движение выкачиваете все эти проекты. В одно движение check-out'ите половину файлов проекта. В одно вдижение проводите рефакторинг. В одно движение заливаете всё это на обратно.
На следующий день всё равно получаете люлей за несобравшиееся проекты. Потому как всё равно никто не стал думать на вопрос "А используете ли в своём проекте...".
Причём это не единичный случай. Это — просто Ваш стиль работы.
... или просто меняете реализацию getter/setter. Решать каждому самому.
Здравствуйте, Геннадий Васильев, Вы писали:
IT>>Судя по этому абзацу у тебя у самого неверное представление зачем нужны юнит тесты. Их задача не найти ошибку в твоём коде, а не дать возможности сломать уже работающий и отлаженный код при будущих его модификациях.
ГВ>Вернее — сразу диагностировать поломку. Предотвратить её юнит-тесты не могут.
Это не их задача предотвращать. И диагноз они тоже ставить не умеют. Их задача показать является ли код после очередных изменений всё ещё работоспособным или нет.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, moudrick, Вы писали:
ВН>>предпочитаю догматично следовать господам Саттеру и Александреску, которые утверждают что public-поля могут иметь только классы "без поведения".
M>Господа, ну что вы прям как дети, извините...
M>мы немедленно применяем рефакторинг Encapsulate Field M>В любой мало-мальски приличной среде программирования для любого мало-мальски приличного ОО языка имеются средства сделать это немедленно в одно движение.
Visual Studio 2005 — мало-мальски приличная? C++ — мало-мальски приличный OO-язык? 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 среду существующих методик.
Здравствуйте, Коваленко Дмитрий, Вы писали:
IT>>Их задача не найти ошибку в твоём коде, а не дать возможности сломать уже работающий и отлаженный код при будущих его модификациях. И чем больше покрытие кода юнит тестами, тем больше шансов уберечься от подобных проблем.
КД>Для аналогичных целей также используют assert'ы. В огромных количествах.
Чтобы тебе помогли асёрты так же как юнит тесты, ты должен прогнать через них свой код. И не просто прогнать, а сделать это для разных сценариев. Юнит тесты специально этим и занимаются. Внёс какие-то изменения в базовый код, запустил тесты, всё зелёненькое, значит повезло. С асёртами же твоя ошибка легко может уехать в продакшин (уже без асёртов), т.к. прогон через них всего кода никто не делает. Разве что случайно на них нарвёшься.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
ГВ>>>Рассуждения про business-value лишены обоснования: что такое business-valued-код? Создаётся впечатление, что автор владеет каким-то мегазнанием, которым не делится с читателями. Отсюда вопрос: а что это за знание? Или это опять buzzword, вставленное для придания веса своим рассужденям? M>>Business-value есть то, что Вы считаете business value.
ГВ>Десять! Тогда весь код, который написан для тяжёлого framework — business-valued-код, ergo, автор сильно не прав. Нет уж, давайте-ка без субъектных терминов. Либо нечто существует только в голове наблюдателя (мираж, он же — сфероконь), либо его можно выделить по каким-то объективным признакам.
M>>Ни более, ни менее. Дао, названное словом, не есть истинное дао (с) Лао Цзы, M>>Но почему же оно тогда называется Дао? Наверное для того, чтобы как-то дать понять непосвящённым, что оно все-таки существует?
ГВ>Осталось только обсудить значение термина "существование".
...По дороге художник Миккель Анжело встречает Комарова, хватает его за
руку и кричит:
— Смотри!
Комаров смотрит и видит шар.
«Что это?» — шепчет Комаров.
А с неба грохочет: «Это шар».
— Какой такой шар? — шепчет Комаров.
А с неба грохот: «Шар гладкоповерхностный!»
...Но с другой стороны, обратите внимание на следующее: если мы говорим,
что ничего не существует ни изнутри, ни снаружи, то является вопрос: изнутри
и снаружи чего? Что-то, видно, все же существует? А может, и не существует.
Тогда для чего же мы говорим изнутри и снаружи? Нет, тут явно тупик. И мы сами не знаем, что сказать.
До свидания.
Даниил Дандан
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Владислав Сивяков, Алексей Мудрик (перевод), Вы писали:
ВСА>>Статья: ВСА>>Dave Astels. Почему ваш код – отстой
Что ж, спасибо Вам за развернутый и искренний ответ.
К постам, показывающим обоснованность написния этой статьи и её тут появленияя Вас отсылать не буду, т.к. надеюсь Вы внимательно просмотрели тред, который на текущеий момент совесм невелик.
ГВ>Набор банальностей, риторики и пересказов.
Вы, наверное, очень умный. Не все, к сожалению, настолько таковы.
Скажите четсно, встречается ли среди Вашего кода отстойный, согласно признакам, указанным в статье?
[....поскипано много умных вещей.......]
ГВ>Рассуждения про business-value лишены обоснования: что такое business-valued-код? Создаётся впечатление, что автор владеет каким-то мегазнанием, которым не делится с читателями. Отсюда вопрос: а что это за знание? Или это опять buzzword, вставленное для придания веса своим рассужденям?
Business-value есть то, что Вы считаете business value.
Ни более, ни менее. Дао, названное словом, не есть истинное дао (с) Лао Цзы,
Но почему же оно тогда называется Дао? Наверное для того, чтобы как-то дать понять непосвящённым, что оно все-таки существует?
ГВ>Четвёртое — дублирование. Мегабанальная вещь, ибо это есмь альфа и омега программирования. Если бы люди не боролись с дублированием, языков высокого уровня попросту бы не было. Такая борьба должна быть в ДНК у програмистов. Ша! Я сказал — у программистов! К тому же в противовес рассужденям о вреде дублирования можно привести не менее абстрактные рассуждения, что, мол, иногда дублирование необходимо, поскольку не ясно, как программа будет развиваться дальше: порой преждевременное склеивание абстракций приносит не меньше головной боли, чем copy&paste.
Зравая мысль. Но — в любом случае это Ваш выбор. Выбирайте с умом (с) сабжевая статья.
ГВ>Вывод: незачёт. Много слов, почти ни одно собственного. Осторожненько так пнули большие framework-и, да и всё. На пересказе общеизвестных истин можно до некоторой степени прославиться, ну и что?
ГВ>Вопрос к RSDN Team: такого добра в блогах — пруд пруди, на фига было тратить время на перевод? Эти рассуждения вполне приемлемы для блоготворчества, где можно быстро вычислить контекст, но в качестве отдельной статьи...
Судя по тому, что как Вы сказали, "пруд пруди", прошу — линки в студию
Причем не меньше пяти разных, их же пруд пруди...
Зачем надо было переводить статью — я ни до, ни после, нигде не видел настолько компактного изложения и описания порочных практик, которые надо искоренять у себя и, по возможности, у окружающих. Подобно тому, как Чехов, русский классик, призывал "по капле выдавливать из себя раба".
А то, что это описание предельно персонализовано, — дык это достоинство, а не недостаток. К постам, показывающим, что это это достоинство, а не недостаток, я Вас отсылать не буду, т.к. надеюсь Вы внимательно просмотрели тред, который на текущеий момент совесм невелик.
ГВ>Прежде всего — очевидное неуважение к читателям: читатели должны мысленно разбираться со стереотипами и buzzwords, свойственными приверженцам определённого стиля разработки, которые при очередной "смене парадигмы" узнали, что 2x2=4 и несут окружающим сокровенный свет этого знания.
К постам, показывающим безосновательноть обвинений в оскорблении читателей, я Вас отсылать не буду, т.к. надеюсь Вы внимательно просмотрели тред, который на текущеий момент совесм невелик.
Если Вы верно поняли миссию этой статьи, то, вероятно, догадались, что никто не предлагает Вам всерьёз сменить парадигму. Лишь пересмотреть (возможно, еще один лишний раз, если Вы очень умный и начинанный) то, с чем Вы имеете дело в реальности.
Кстати, будем искать спонсора для перевода этой статьи на индийский?
FDS>Если этот человек бросился учить кого-то, значит он ставит себя выше других. По крайней мере, если он это делает такими методами. И преамбулы тут не помогут.
Не согласен. "Поучений" здесь меньше всего. Это лишь констатация факта. Вы это можете признать, а можете не признать. Это Ваш выбор. Выбирайте с умом.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Вернее — сразу диагностировать поломку. Предотвратить её юнит-тесты не могут.
Как-то вы странно понимаете TDD.. Это не автоматическое тестирование
TDD и юниттесты — это
1. способ описать, что конкретно будет делать код. Не в терминах классов, domain models etc, а в совершенно конкретных вещах — берем на входе a,b,c — получаем на выходе d,e,f. Не больше, но и не меньше. Не надо писать "на будущее", надо только то, что надо.
2. юниттесты — это не способ тестить приложение, этим занимаются тестеры. Юниттесты — это снапшот кода, работающего по описанным правилам.
3. Не тесты пишутся под код, а код под тесты. Это заставляет тщательно продумывать, чего, собственно, должен делать код, на совершенно конкретных примерах и ситуациях.
А то в большинстве случаев программирование сводится к
"Высоко-высоко над Небесным Градом, на небольшой площадке, венчающей
собою верхушку Шпиля Высотою в Милю, стоял Владыка Иллюзий, Мара-Сновидец.
Одет он был в плащ всех цветов — и не только радуги. Воздел он над головой
руки, и, сливаясь воедино с собственной силой, хлынула через его тело мощь
всех остальных богов.
В уме его обретала форму греза. И излил он ее наружу, как разливается
по пляжу накатившаяся на берег высокая волна." (c) понятно кто
Изливаем в редактор грезу вместо того, чтобы сделать работу.
ВН>Интересная статья. Однако предпочитаю догматично следовать господам Саттеру и Александреску, которые утверждают что public-поля могут иметь только классы "без поведения". У них достаточно подробно расписано, почему лучше делать так. В частности, для целей отладки/тестирования и соблюдения инвариантов.
Господа, ну что вы прям как дети, извините...
Как только public/protected (or other non-private) поле становится непрозрачным для чтения и/или записи,
мы немедленно применяем рефакторинг Encapsulate Field
В любой мало-мальски приличной среде программирования для любого мало-мальски приличного ОО языка имеются средства сделать это немедленно в одно движение.
Непрозначное для чтения-записи — это значит, что для считывания/записи значения свойства требуется нетривиальная логика, отличная от простого сохранения-считывания private-поля.
Если свойство прозрачно для чтения-записи, реализация его public полем не окажит никакого влияния на отладку/тестирование и соблюдение инвариантов.
(Если конечно соближение инвариантов не требует нетривиальной логики чтения-записи).
Если мы видим public поле, это сигнал — на текущий момент использование свойства, представляемого этим полем — тривиально.
Здравствуйте, moudrick, Вы писали:
FR>>Нормальная реакция нормального человека на такое обращение "а не пошел бы ты на*** со своим поучениями"
M>Смотрите линку на цитату из детской книги в моём посте
Здравствуйте, Кодёнок, Вы писали:
Кё>- код должен работать Кё>- надо стараться разбивать систему так, чтобы как можно больше её частей тестировались автоматически
Нет. Он говорит, что если тестов нет, то код нельзя считать работающим. А это бред, потому что есть дофига кода не тестируемого автоматически.
Кё>- надо думать своей головой, а не тупо следовать методологии
Ага. 20 человек в команде и каждый подумал своей головой Зашибись.
ГВ>Хорошо , временно снимаю свою апелляцию к "пруд пруди", оставляю только ту часть, которая относится к потере контекста.
ГВ>Не понял, что Вы имеете ввиду под "персонализацией". Я вижу, что автор высказывает своё собственное мнение, по большей части являющееся компиляцией уже достаточно известных суждений. Недостаток здесь не в "присутствии автора", а в компиляции и отсутствии контекста.
Отсутствие контекста — и есть контекст. Глобальный контекст.
Ото всей души желаем вам
Счастья, благополучия и глобальности.
Глобальные лампочки, глобальные девочки.
Хей, закрываешь ли ты свое обнаженное лицо,
Когда плачешь за кирпичным окном на пятом этаже?
Здравствуйте, adontz, Вы писали:
A>Пользуюсь ли я юнит-тестами? Конечно нет! Правильно ли я сложил два числа я проверять не буду, я в себе уверен. А найти и исправить руками действительно сложную ошибку гораздо проще и быстрее, чем ломать голову над написанием теста. Многие скажут, а если ошибка вернётся? Ведь придётся заново её искать и исправлять. Ну что же, если у вас в проекте не ошибки, а птицы-фениксы, значит у вас серьёзные проблемы с архитектурой. Правильная архитектура в гораздо большей степени способствует уменьшению количества ошибком, нежели юнит-тесты, а неправильную никакие юнит-тесты не спасут.
Судя по этому абзацу у тебя у самого неверное представление зачем нужны юнит тесты. Их задача не найти ошибку в твоём коде, а не дать возможности сломать уже работающий и отлаженный код при будущих его модификациях. И чем больше покрытие кода юнит тестами, тем больше шансов уберечься от подобных проблем.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, moudrick, Вы писали:
M>Тиражы на рынках, в магазинах и инет магазинах закончились ((.
Проверил, так и есть...
M>А мне надо.
Нашел! второе сообщение сверху, вторая ссылка !
Здравствуйте, moudrick, Вы писали:
M>>>Тем более это повод к стремлению и умению выражать правильные вещи компактно.
FR>>Да кстати как относишся к языку J? FR>>(Re[4]: Размер класса
)
FR>>Мне кажется ты должен быть (или стать) его фанатом
M>Все смеетесь надо мной?
чуть-чуть
M>Нет, я не стал бы его фанатом. M>И даже не важно, действительно ли это некий язык или стёб, коих в том числе на РСДН обсуждалось немало...
Тут даже есть его поклоники, не стоит их обижать.
M>После беглого просмотра я понял, что код на этом языке (или стёбе на тему языка) будет отстоем. M>Потому что он не понятен и его трудно прочитать...
По второй ссылке хорошо объясняется почему его сначал трудно читать
(Re[3]: Немного о J
ГВ>>>>>Набор банальностей, риторики и пересказов. M>>>>Вы, наверное, очень умный. Не все, к сожалению, настолько таковы. M>>>>Скажите четсно, встречается ли среди Вашего кода отстойный, согласно признакам, указанным в статье? ГВ>>>Зачем Вам это? M>>От этого зависит Ваш ответ? ГВ>Нет, это был вежливый уход от ответа на личный вопрос.
Он немедленно перестает быть личным, когда с Вашим кодом работает еще кто-то кроме Вас.
А это типичный случай и абсолютно обычное дело, если Вы работаете в команде или контрибутите опен-сорц.
M>>На самом деле если Вы понимаете, что часть Вашего кода — отстой, но продолжаете тисать такой же отстойный код, и при этом не хотите в этом признаться хотя бы самому себе, то разве это правильно? И в статье ещё раз подчеркивается, что это неправильно. ГВ>Такая постановка вопроса ставит оппонента в безвыходное положение: что бы он ни возразил, его высказывание можно свести к тому, что он, мол, не хочет признаться самому себе в том-то и том-то (есть тут у нас мастера по этой части ). А исходный тезис при этом ставится в положение абсолютной истины(???). Это не смешно, поверьте.
ставится в положение абсолютной истины(???)
В положение абсолютной истины — не ставится. А видимость его абсолютной истинности — это всего лишь, говоря Вашими же словами, метафора.
M>>И спрашиваю я по банальной причине — хочу узнать, настолько ли Вы идеальны, как это может следовать из Ваших постов. ГВ>Возможно, что Вы не знаете: апелляция к личности есть некорректный приём полемики. Вот потому я и не отвечаю на такие вопросы. Суть нашей беседы, как я понимаю, всё-таки не в обсуждении [не]совершеств оппонентов, а в обсуждении статьи, не правда ли?
Перегнул палку. Примите, пожалуйста, извинения.
Но у любой статьи есть целевая аудитория.
И если Вы полагаете, что к ней не относитесь, Вы можете её попросту игнорировать.
Я, почему-то, не оскорбился, читая эту статью, а наоборот развеселился выше всякой меры.
Развеселился настолько, что даже поучаствовал в переводе.
Чтобы поделиться ощущениями с теми, кто по тем или иным причинам не может адекватно оценить его на языке оригинала.
Развеселился, потому что мне легче стало видеть, где в моем коде отстой, не читая толстенные талмуды.
Ибо все книги все равно не прочтёшь, потому я очень ценю компактность.
Даже если она достигается ценою потерей политкоррекности.
Re[2]: Как спроектировать для автомат. тестирования?
Здравствуйте, Constructor, Вы писали:
C>Здравствуйте, C>А кто-нибудь подскажет, как писать код, приспособленный для автоматического тестирования. У меня нет автоматических тестов (соответственно, все, что я понаписал -... ). Тем не менее, наверняка, этот вопрос уже хорошо проработан и есть методические рекомендации с примерами?
Если начинаешь с нуля проект, либо какую-то его мало-мальски независимую часть, то все просто.
TDD
Test Driven Development. Можно посмотреть здесь, ищи также треду на RSND по этому ключевому слову.
Одноименный основополагающий труд Кент Бек на эту тему — здесь. Тиражы на рынках, в магазинах и инет магазинах закончились ((. А мне надо. В том числе как раздаточный материал для начинающих, ибо расскзать это невозможно (показать можно — если практикуется парное программирование). Это небывалая книга по соотношению "объем — время прочтения". Короткие и точные формулировки, проверенные практикой, воспринимаются с трудом, но когда становятся частью мировоззрения, удивляешься — почему это могло быть непонятно... Там описан сам процесс TDD, отдельные ситуации, возникающие в практике (паттерны) с их разбором. А также пошаговое описание создания framework-а для автоматического тестирования на (ОО) языке, который автор изучал в процессе написания этого фреймворка. К вопросу о самоприменимости и о том, что было раньше — яйцо или курица...
Здравствуйте, Constructor, Вы писали:
C>Блин, а я много раз проходил мимо этой книги, когда она еще лежала на полках, и даже не брал в руки. Т.к., первая появившаяся книжка Бека "экстремальное программирования" восторга не вызвала. Не думал я, что разработка через тестирование окажется нормальной технологией. Думал это из разряда "программирование парами".
Не расстраивайтесь.
Многие считают, что программирование парами — это очень полезно. Может вам и разработка через тестирование тоже не понравится
Здравствуйте, moudrick, Вы писали:
ГВ>>>>>>Набор банальностей, риторики и пересказов. M>>>>>Вы, наверное, очень умный. Не все, к сожалению, настолько таковы. M>>>>>Скажите четсно, встречается ли среди Вашего кода отстойный, согласно признакам, указанным в статье? ГВ>>>>Зачем Вам это? M>>>От этого зависит Ваш ответ? ГВ>>Нет, это был вежливый уход от ответа на личный вопрос.
M>Он немедленно перестает быть личным, когда с Вашим кодом работает еще кто-то кроме Вас. M>А это типичный случай и абсолютно обычное дело, если Вы работаете в команде или контрибутите опен-сорц.
Ни йоты возражений. Но! Мы сейчас не работаем в команде и не контрибутим опен-сорц.
M>>>На самом деле если Вы понимаете, что часть Вашего кода — отстой, но продолжаете тисать такой же отстойный код, и при этом не хотите в этом признаться хотя бы самому себе, то разве это правильно? И в статье ещё раз подчеркивается, что это неправильно. ГВ>>Такая постановка вопроса ставит оппонента в безвыходное положение: что бы он ни возразил, его высказывание можно свести к тому, что он, мол, не хочет признаться самому себе в том-то и том-то (есть тут у нас мастера по этой части ). А исходный тезис при этом ставится в положение абсолютной истины(???). Это не смешно, поверьте.
M>ставится в положение абсолютной истины(???) M>В положение абсолютной истины — не ставится. А видимость его абсолютной истинности — это всего лишь, говоря Вашими же словами, метафора.
Дело вот в чём: формально код может вполне соответствовать критериям "отстойного" кода, но фактически, к нему может быть не уместно применять ругательство "отстой", потому что причины, по которым он стал и сохраняется таким вполне могут оправдывать существование "отстойного" кода.
Возникает, казалось бы, парадоксальная ситуация: код "отстойный", но его держат именно в таком виде, не переделывают. Но парадокс этот неизбежно мнимый, поскольку поставить правильную оценку исходникам можно только исходя из контекста, в котором они появились. Скажем, фрагменты могут быть типовыми и короткими (vs. тезисы о дублировании), легко проверяемыми визуально (vs. тезисы о тестах), быть резервом для планируемых расширений (vs. тезисы о закрытых членах класса); они могли появиться в периоды цейтнота (снова vs. тезисы о дублировании). framework, в свою очередь, может быть выбран по политическим соображениям (vs. тезисы о framework).
Соответственно, нет никакого смысла требовать от разработчиков соглашаться с резко негативной оценкой такого кода. И тем более, апеллировать к тому, что, мол, они сами не хотят себе признаться в том, что делают отстой.
Разработчики тоже ставятся в сложное положение, поскольку должны, по сути, признать "отстойность" своего кода и в общем, сойти с ума от внутреннего противоречия, поскольку идеология, которую исповедует Dave говорит одно, практические нужды — совершенно другое, а воспитание вторит идеологическим напевам.
А ключ к противоречию в заклинании: "признайтесь хотя бы самому себе..." и неправомерном связывании банальных потенциальных источников неприятностей с жестким: "отстой!"
Вывод? Наглая попытка манипуляции.
M>>>И спрашиваю я по банальной причине — хочу узнать, настолько ли Вы идеальны, как это может следовать из Ваших постов. ГВ>>Возможно, что Вы не знаете: апелляция к личности есть некорректный приём полемики. Вот потому я и не отвечаю на такие вопросы. Суть нашей беседы, как я понимаю, всё-таки не в обсуждении [не]совершеств оппонентов, а в обсуждении статьи, не правда ли?
M>Перегнул палку. Примите, пожалуйста, извинения.
Принимаю!
M>Но у любой статьи есть целевая аудитория. M>И если Вы полагаете, что к ней не относитесь, Вы можете её попросту игнорировать.
По сути я следую примерно тем же правилам, но почерпнуты они не из этой статьи. Так что, правильнее всего сказать, что "она ко мне примазывается". Ничего личного, разумеется.
Как читателя, меня и в самом деле привлекло название. Следовательно, оно может привлечь и тех, кто не является целевой аудиторией.
M>Я, почему-то, не оскорбился, читая эту статью, а наоборот развеселился выше всякой меры.
Собственно, я не об оскорблении вёл речь. Скорее, это чувство можно назвать изумлением от пафоса, с которым преподносятся очевидные вещи. Естественная реакция на такой пафос, вопросить: "он что нас, за тупиц держит?" Вопрос адресован не Вам, конечно, а автору, Dave Astels.
M>Развеселился настолько, что даже поучаствовал в переводе. M>Чтобы поделиться ощущениями с теми, кто по тем или иным причинам не может адекватно оценить его на языке оригинала.
Ну что же, благодарная аудитория у Вас имеется. Критически настроенная судя по всему — тоже.
M>Развеселился, потому что мне легче стало видеть, где в моем коде отстой, не читая толстенные талмуды. M>Ибо все книги все равно не прочтёшь, потому я очень ценю компактность. M>Даже если она достигается ценою потерей политкоррекности.
С этим не могу не согласиться.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ВСА>Авторы: ВСА>Владислав Сивяков, Алексей Мудрик (перевод)
ВСА>Аннотация: ВСА>Если Вы программируете как большинство, и даже, вероятно, все программисты (скромненько включая автора этой статьи), то ваш код — отстой. Возможно, не целиком; возможно, не всегда, но наверняка какая-то его часть и в какой-то момент времени.
Интересная статья. Однако предпочитаю догматично следовать господам Саттеру и Александреску, которые утверждают что public-поля могут иметь только классы "без поведения". У них достаточно подробно расписано, почему лучше делать так. В частности, для целей отладки/тестирования и соблюдения инвариантов.
Здравствуйте, Трурль, Вы писали:
Т>Тема не раскрыта. Не объясняется, почему же ваш код – отстой. Т>Было бы мило, если бы автор закончил в духе "Ваш код – отстой, потому что вы все — ..."
Так не интересно, любой дурак такое напишет. Автор интеллигентно намекает, давая ясно понять, что вокруг одни 1_3.14здяи.
Здравствуйте, 2garin, Вы писали:
M>>>В варианте для нашего личного использования у нас был прямой глагольный перевод, который звучал так — "Почуму ваш код сосёт". Или даже — "Почему твой код сосёт".
FR>>Нормальная реакция нормального человека на такое обращение "а не пошел бы ты на*** со своим поучениями"
2>Предложи, пожалуйста, свой вариант перевода "Why Your Code Sucks"
Не знаю
Может на западе у них нормально человека поучать через оскорбление, но мы похоже для таких высот демократии еще не дозрели.
FR>>Может на западе у них нормально человека поучать через оскорбление, но мы похоже для таких высот демократии еще не дозрели.
FDS>Да, у нас за такие способы и по морде можно получить. И вообще, это не хорошо — получается автор статьи сразу ставит себя очень высоко — никто этого не любит, поэтому можно ждать очень много неконструктивной критики (в частности).
Не ставит. Читай преамбулу:
ВСА>Аннотация:
ВСА>Если Вы программируете как большинство, и даже, вероятно, все программисты (скромненько включая автора этой статьи), то ваш код — отстой. Возможно, не целиком; возможно, не всегда, но наверняка какая-то его часть и в какой-то момент времени.
FR>>>Нормальная реакция нормального человека на такое обращение "а не пошел бы ты на*** со своим поучениями"
M>>Смотрите линку на цитату из детской книги в моём посте
этого же треда
FR>совершенно другая тема, там про "заставить для его же блага", а тут "научить оскорбляя".
Вашими же словами и отвечу.
Статья ничему не учит, а "заставить..." читателя "...для его же блага" оторвать свою ... от уютного лона привычных представлений, ошибок и граблей, и начать искать пути эффективной борьбы с отстоем.
Здравствуйте, moudrick, Вы писали:
M>Перепрошую. В реальной жизни начиная с некоторого момента требования к ПО изменяются быстрее, чем пишется его код. Потому имхо будущее большинства успешных продуктов — перманентный рефакторинг, ибо единственный приемлемый способ учитывать изменяющиеся требования к продукту. Каждый раз все с самого начала не напишешь.
У нас с вами разные реальности, похоже В нашей реальности, например, есть зафиксированный спискок фич, которые должны войти в текущую версию. Если в процессе разработки резко возникает необходимость в неизвестной ранее фиче, это всего лишь означает, что ПМ ее проворонил на стадии формирования списка фич. Далее, эта фича либо откладывается на следующую версию (если получится), либо поступает в разработку со сдвигом сроков сдачи. В любом случае, это проблема менеджемента — не разработчиков. Но я прекрасно понимаю, что в реальности довольно часто сдвига сроков не бывает, и что разгребать все это приходится разработчикам. То есть, хорошим разработчикам однозначно стоит быть к этому готовыми, да и получается частенько само (с TDD, рефакторингами и пр.). Но это совершенно не означает, что ПМ должен перманентно подкидывать такие задачки.
M>Т.е. рефакторить придется не потому что плохо рабоатет, а потому что надо быстро сделать так, чтобы учесть изменившиеся требования.
В хорошо спроектированном приложении эти изменения вносятся либо добавлением нового кода, либо незначительной модификацией существующего. А архитектуру на ходу рефакторить... Мы сейчас именно этим и занимаемся. Тот еще экстрим, уж поверьте. Да и не рефакторинг это уже, а тренировка саперов на настоящем минном поле.
If a shark stops swimming, it will die. Don't stop swimming, Mr. Mulder.
Every epic equalizer is iso (c)
M>>Перепрошую. В реальной жизни начиная с некоторого момента требования к ПО изменяются быстрее, чем пишется его код. Потому имхо будущее большинства успешных продуктов — перманентный рефакторинг, ибо единственный приемлемый способ учитывать изменяющиеся требования к продукту. Каждый раз все с самого начала не напишешь. K>У нас с вами разные реальности, похоже В нашей реальности, например, есть зафиксированный спискок фич, которые должны войти в текущую версию.
Реальность у всех одинаковая. Восприятие разное. У некоторых ограничивается собственным рабочим столом. У некоторых своим рабочим кабинетом. А некоторые все-таки стремятся к большему.
K>Если в процессе разработки резко возникает необходимость в неизвестной ранее фиче, это всего лишь означает, что ПМ ее проворонил на стадии формирования списка фич.
Ага, давайте спишем все на ПМ.
Насколько часто формируется этот список фич?
K>Далее, эта фича либо откладывается на следующую версию (если получится), либо поступает в разработку со сдвигом сроков сдачи.
На сколько?
K>В любом случае, это проблема менеджемента — не разработчиков.
Ага, давайте опять все спишем на ПМ. У него голова (читай — зарплата) большая — пусть думает. А ты сам не боишься оказаться на его месте?
K>Но я прекрасно понимаю, что в реальности довольно часто сдвига сроков не бывает, и что разгребать все это приходится разработчикам. То есть, хорошим разработчикам однозначно стоит быть к этому готовыми, да и получается частенько само (с TDD, рефакторингами и пр.).
Ну вот вы же сами и показали, что мое восприятие ближе к реальности, чем Ваше.
K>Но это совершенно не означает, что ПМ должен перманентно подкидывать такие задачки.
Традиционная методика разработки ПО. Существует и дает иногда неплохие результаты. Имеет право на существование. Не является гибкой и потому неспособна решать "гибкие" задачи.
Кстати, в XP тоже есть некий порядок в планировании имплементации фич. Но в силу "Small Releases" ими можно гибче управлять, чаще добавлять/изменять без ущера качеству разрабатываемого продукта. Частота зависит от длительности итерации. Итерации обычно короткие — неделя или две. Подкидывать можно перманентно, где перманентно означает — в начале итерации.
M>>Т.е. рефакторить придется не потому что плохо рабоатет, а потому что надо быстро сделать так, чтобы учесть изменившиеся требования. K>В хорошо спроектированном приложении эти изменения вносятся либо добавлением нового кода, либо незначительной модификацией существующего.
А где гарантия, что эти изменения/добавления ничего существующего не сломали?
Это бывает даже при хорошем проектировании. Вспомните законы Мерфи, это обязательно случится.
Что делать? После cosmetic improvements отдавать всё армии тестеров, чтобы еще раз все прогнали по графу use-case-ов?
Поверьте, в agile-технологиях не брезгуют хорошим проектированием. Agile-методики не отрицают, а дополняют хорошее проектирование. А хорошее проектирование, кстати, включает в себя Unit-тестирование. Как правило — в виде неотъемлемой части.
K>А архитектуру на ходу рефакторить... Мы сейчас именно этим и занимаемся. Тот еще экстрим, уж поверьте. Да и не рефакторинг это уже, а тренировка саперов на настоящем минном поле.
Самое время рассмотреть возможность применения методик XP. Я серьёзно.
Здравствуйте, moudrick, Вы писали:
K>>Если в процессе разработки резко возникает необходимость в неизвестной ранее фиче, это всего лишь означает, что ПМ ее проворонил на стадии формирования списка фич. M>Насколько часто формируется этот список фич?
После выпуска каждой версии.
K>>Далее, эта фича либо откладывается на следующую версию (если получится), либо поступает в разработку со сдвигом сроков сдачи. M>На сколько?
Зависит от фичи.
K>>В любом случае, это проблема менеджемента — не разработчиков. M>Ага, давайте опять все спишем на ПМ. У него голова (читай — зарплата) большая — пусть думает. А ты сам не боишься оказаться на его месте?
Я уже на его месте Хоть формально и не ПМ.
K>>Но я прекрасно понимаю, что в реальности довольно часто сдвига сроков не бывает, и что разгребать все это приходится разработчикам. То есть, хорошим разработчикам однозначно стоит быть к этому готовыми, да и получается частенько само (с TDD, рефакторингами и пр.). M>Ну вот вы же сами и показали, что мое восприятие ближе к реальности, чем Ваше.
Гм. Это и мое восприятие тоже
K>>Но это совершенно не означает, что ПМ должен перманентно подкидывать такие задачки. M>Традиционная методика разработки ПО. Существует и дает иногда неплохие результаты. Имеет право на существование. Не является гибкой и потому неспособна решать "гибкие" задачи.
Значит, у нас работает некая комбинация традиционной разработки и Agile Programming. Что есть, имхо, хорошо, потому что устраивает как разработчиков (которые мотивированы и готовы писать надежный и тестируемый код с частыми релизами), так и менеджмент (задачи которого выполняются в предсказуемые и не слишком большие сроки). Истина — она всегда где-то посередине
M>Кстати, в XP тоже есть некий порядок в планировании имплементации фич. Но в силу "Small Releases" ими можно гибче управлять, чаще добавлять/изменять без ущера качеству разрабатываемого продукта. Частота зависит от длительности итерации. Итерации обычно короткие — неделя или две. Подкидывать можно перманентно, где перманентно означает — в начале итерации.
У нас так и происходит. И для этого совсем не обязательно внедрять XP. Хотя, апологеты XP думают иначе, конечно
M>А где гарантия, что эти изменения/добавления ничего существующего не сломали?
В юнит-тестах для кода, написанного с помощью TDD (которое включает в себя рефакторинг).
M>Поверьте, в agile-технологиях не брезгуют хорошим проектированием. Agile-методики не отрицают, а дополняют хорошее проектирование. А хорошее проектирование, кстати, включает в себя Unit-тестирование. Как правило — в виде неотъемлемой части.
А я нигде и не отрицал положительного влияния TDD на архитектуру и юнит-тестов на надежность кода.
K>>А архитектуру на ходу рефакторить... Мы сейчас именно этим и занимаемся. Тот еще экстрим, уж поверьте. Да и не рефакторинг это уже, а тренировка саперов на настоящем минном поле. M> Самое время рассмотреть возможность применения методик XP. Я серьёзно.
Не поможет тут XP. Оно поможет, если мы выкинем старое, и начнем делать новое. Сейчас рефакторинг помогает привести существующий код в такое состояние, при котором изменение архитектуры скажется на работе системы как можно менее безболезненно. Но совсем безболезненно — не получится. Это реальность. Те же законы Мерфи.
If a shark stops swimming, it will die. Don't stop swimming, Mr. Mulder.
Every epic equalizer is iso (c)
Здравствуйте, adontz, Вы писали:
Кё>>- надо думать своей головой, а не тупо следовать методологии A>Ага. 20 человек в команде и каждый подумал своей головой Зашибись.
Эх, если бы так было всегда!
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, moudrick, Вы писали:
M>>>Ни более, ни менее. Дао, названное словом, не есть истинное дао (с) Лао Цзы, M>>>Но почему же оно тогда называется Дао? Наверное для того, чтобы как-то дать понять непосвящённым, что оно все-таки существует?
ГВ>>Осталось только обсудить значение термина "существование".
M>
Можно с уверенностью сказать: мой оппонент, безусловно, начитанный человек. Респект!
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, IT, Вы писали:
A>>Пользуюсь ли я юнит-тестами? Конечно нет!
IT>Их задача не найти ошибку в твоём коде, а не дать возможности сломать уже работающий и отлаженный код при будущих его модификациях. И чем больше покрытие кода юнит тестами, тем больше шансов уберечься от подобных проблем.
Для аналогичных целей также используют assert'ы. В огромных количествах.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, IT, Вы писали:
IT>Судя по этому абзацу у тебя у самого неверное представление зачем нужны юнит тесты. Их задача не найти ошибку в твоём коде, а не дать возможности сломать уже работающий и отлаженный код при будущих его модификациях.
Вернее — сразу диагностировать поломку. Предотвратить её юнит-тесты не могут.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Кодёнок, Вы писали:
a>>Он говорит — "Вы все дебилы, один я умный. Айда за мной!". Кё>Давай перефразируем по пунктам:
Там перефразируем, сям додумаем, здесь прочтём справа налево, тут вообще читать не будем... Это в корне не верно. Напоминает анекдот про кипу чертежей и три вагона изменений и дополнений.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, adontz, Вы писали:
Кё>>>- надо думать своей головой, а не тупо следовать методологии A>>Ага. 20 человек в команде и каждый подумал своей головой Зашибись.
ГВ>Эх, если бы так было всегда!
То некоторые фирмы уже бы разорились, так как:
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
M>Но у любой статьи есть целевая аудитория. M>И если Вы полагаете, что к ней не относитесь, Вы можете её попросту игнорировать.
Я например не желаю быть в такой целевой аудитории, которой плюют в лицо, а она улыбается и говорит спасибо.
M>Я, почему-то, не оскорбился, читая эту статью, а наоборот развеселился выше всякой меры.
M>Развеселился настолько, что даже поучаствовал в переводе. M>Чтобы поделиться ощущениями с теми, кто по тем или иным причинам не может адекватно оценить его на языке оригинала.
M>Развеселился, потому что мне легче стало видеть, где в моем коде отстой, не читая толстенные талмуды. M>Ибо все книги все равно не прочтёшь, потому я очень ценю компактность.
M>>Но у любой статьи есть целевая аудитория. M>>И если Вы полагаете, что к ней не относитесь, Вы можете её попросту игнорировать.
FR>Я например не желаю быть в такой целевой аудитории, которой плюют в лицо, а она улыбается и говорит спасибо.
Умейте быть смиренными.
А Я говорю вам: не противься злому. Но кто ударит тебя в правую щеку твою, обрати к нему и другую
M>>Я, почему-то, не оскорбился, читая эту статью, а наоборот развеселился выше всякой меры.
M>>Развеселился настолько, что даже поучаствовал в переводе. M>>Чтобы поделиться ощущениями с теми, кто по тем или иным причинам не может адекватно оценить его на языке оригинала.
M>>Развеселился, потому что мне легче стало видеть, где в моем коде отстой, не читая толстенные талмуды. M>>Ибо все книги все равно не прочтёшь, потому я очень ценю компактность.
FR>Талмуды гораздо полезней.
Читаю. Да за работой за всеми не поспеваю.
Даже если успеваю поверхностно проыесть, то не всегда успеваю вникнуть.
Много Вы прочли талмудов? А много ли осталось непрочтёнными?
Что будете делать с теми, которые не успели прочесть?
Там ведь тоже полезные нужные знания!
Здравствуйте, moudrick, Вы писали:
FR>>У тебя на все случаи в жизни есть ссылки с мыслями до конца понятными только тебе?
M>Не на все. Но я к этому стремлюсь. M>У меня и сюда есть линка с мыслями, но не буду её приводить. M>Боюсь составить о себе мнение как о излишне нудном типе.
поздно боятся
FR>>Хотя это конечно сильно приплести сюда алгебру логики, может мне в ответ дать ссылки на теорию кодирования, чтобы ты почитал о минимальной избыточности?
M> А, так Вы — специалист, а я прислал линку с контентом для начинающих? Сорри M>О минимальной избыточности читал, даже вроде изучал и сдавал когда-то... M>Если вы дадите ссылки M>а в них будет быстро заметно нечто существенное, чего раньше не видел или не обращал внимания — поставлю хорошую оценку месаге
Нет я тоже "сдавал когда-то", просто склероз иногда отступает
Я всё понял. Давайте всё писать на RegExp-ах, это же предельная компактность
А за линку — спасибо
M>>Хотя я мог неправильно его понять... Если так — поправьте меня
FR>Как я понял сначала нужно долго учится, зато "потом за пять минут долетишь" FR>А ты что хочешь краткости на халяву?
"Нет царских путей в геометрию, о великий Птолемей". (Евклид, отсюда)
R>Ага, в одно движение оббегаете несколько отделов. Спрашиваете у каждого, а не использует ли он Ваш класс в своём проекте. Переспрашиваете его ещё раз, что бы повысить достоверность. Потом в одно движение выкачиваете все эти проекты. В одно движение check-out'ите половину файлов проекта. В одно вдижение проводите рефакторинг. В одно движение заливаете всё это на обратно. R>На следующий день всё равно получаете люлей за несобравшиееся проекты. Потому как всё равно никто не стал думать на вопрос "А используете ли в своём проекте...".
Возражение из серии: "а если завтра война?"
Библиотечный (публичный) код, используемый одновременно со своим развитием во многих проектах встречается не часто, и по отношению к нему применяются совершенно другие правила, чем к прикладному коду в контексте некоторой задачи. Причем этот самый прикладной код (не пуличный) по объему составляет подавляющую часть проектов и именно в этом коде геттеры/сеттеры совершенно не нужны (если понадобятся, они могут быть автоматически созданы одним нажатием на шорткат). То есть выходит, что геттеры/сеттеры не нужны в подавляющей части кода, следовательно, они там будут только мешаться.
A>Если бы юнит-тесты были панацеей, то профессия тестировщика (QA Engineer) уже давно канула бы в лету, но нет, они живы-здоворы и неплохо зарабатывают Что, тестеров нанимают только те, кто не умеет пользоватся юнит-тестами? А может надо признать что тезис "код не проходящий регулярное юнит-тестирование — отстой" сам является отстоем?
Ваше суждение исходит из непонимания того, что есть unit-testы
Темы для чтения:
unit-testы, их определение, назначение и ограничения.
ВСА>Если Вы программируете как большинство, и даже, вероятно, все программисты (скромненько включая автора этой статьи), то ваш код — отстой. Возможно, не целиком; возможно, не всегда, но наверняка какая-то его часть и в какой-то момент времени.
Согласен, мой код — отстой, согласно определениям статьи. И что дальше?
Здравствуйте,
А кто-нибудь подскажет, как писать код, приспособленный для автоматического тестирования. У меня нет автоматических тестов (соответственно, все, что я понаписал -... ). Тем не менее, наверняка, этот вопрос уже хорошо проработан и есть методические рекомендации с примерами?
Re[3]: Как спроектировать для автомат. тестирования?
Спасибо!
M>Одноименный основополагающий труд Кент Бек на эту тему — здесь. Тиражы на рынках, в магазинах и инет магазинах закончились ((. А мне надо.
Блин, а я много раз проходил мимо этой книги, когда она еще лежала на полках, и даже не брал в руки. Т.к., первая появившаяся книжка Бека "экстремальное программирования" восторга не вызвала. Не думал я, что разработка через тестирование окажется нормальной технологией. Думал это из разряда "программирование парами".
Re[2]: Как спроектировать для автомат. тестирования?
Здравствуйте, Constructor, Вы писали:
C>Здравствуйте, C>А кто-нибудь подскажет, как писать код, приспособленный для автоматического тестирования. У меня нет автоматических тестов (соответственно, все, что я понаписал -... ). Тем не менее, наверняка, этот вопрос уже хорошо проработан и есть методические рекомендации с примерами?
С разрешрения участников процитирую небольшой IM-диалог, который может прояснить ситуацию при недопонимании..
6/20/2006 3:11:39 PM Ozzy wrote:
мне вот только не понятно как сделать код поддающийся тестированию? Что имелось ввиду? 6/20/2006 3:13:01 PM moudrick wrote:
писать его так, чтобы основной функционал можно было вызывать не только из прикрученного интрерфейса, но и из тестового framework-а. 6/20/2006 3:13:20 PM moudrick wrote:
причем так, чтобы из тестового фреймворка можно было проверить результат... 6/20/2006 3:32:26 PM Ozzy wrote:
в общем каждый модуль типа должен быть независим и выдавать нужный результат на необходимые тесты 6/20/2006 3:32:38 PM moudrick wrote:
да 6/20/2006 3:32:44 PM moudrick wrote:
точно сказал.
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)
M>>Перевод не является вольным. Он действителньно содержал много вольностей в том варианте, что мы использовали для себя. Но благодаря редколлегии все вольности в переводе были устранены еще до публикации.
2>Да я согласен с переводом, да и сам не нашел более подходящего перевода для sucks, соответствующего духу статьи.
В варианте для нашего личного использования у нас был прямой глагольный перевод, который звучал так — "Почуму ваш код сосёт". Или даже — "Почему твой код сосёт". Но такая грубость, конечно, неприемлема на " the best russian-languaged resource for developers", как я описал RSDN в письме с запросом к автору на публикацию перевода.
Скорее всего и этот вариант будет опубликован.
В моём блоге.
Если ничто не помешает этому.
В частности, если не будет возражать The RSDN Group. А она скорее всего не будет возражать.
Когда и если это случится, я обязательно объявлю это здесь. Приходите ругаться.
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>Предлагаю не панацею, но хорошее средство: Совершенный код
. Уверяю, мне помогло и продолжает помагать, хотя... все равно мой код несовершенен
Тут вопрос в том, что никогда не получается следовать этим рекомендациям. К тому же, для разных языков не получается это по разному . Поэт., такие книги обычно бесполезны, по крайней мере для меня — я остро чуствую что пишу плохой код сам, а когда читаю такие книги — начинаю просто заваливать задания, потому что там нужно искать компромис между тем, что написано в книге и реальной жизнью, а тому, кто может его удачно найти такие книги уже не нужны.
К тому же в одних проектах эти рекомендации могут оказаться прекрасными, а в других — ужасными. Важно ведь ещё и сроки выполнения и то, что код, возможно, всё равно придётся потом сильно переделывать и т.п.
Re[2]: Тривиальная задача - как неотстойно написать?
FDS>Вопрос по неотстойному написанию: допустим мне нужно написать код перемножения двух матриц.
Вообще всегда критерием является практика. Если задача разовая и сделать надо быстро — можно и забить.
Но если этот исходник будет потом меняться — тут начинаются траблы, и чтобы написать правильно
— могут понадобиться еще одни мозги на 100% загрузки, что в широком обиходе называется "парное программирование". Чтобы двое полноценных можгов воспринимали задачу во всей ее полноте и стремились получить максимальную пользу (business value).
FDS>Я могу его написать 4 функциями, соответствующими AijBjk; AjiBjk; AijBkj; AjiBkj; FDS>Но это будет дублирование кода, причём почти copy-paste — то есть код — отстой
На чем пишем? Обобщенное программирование, вполне возможно, спасет отца русской демократии
FDS>Я могу написать его 1 функцией, с такими параметрами MatrixMul(A, B, TransposeA, TransposeB), заставив передавать в функцию параметры транспонирования матрицы — но это не удобно для использования
FDS>Можно вообще написать только внутреннее произведение и транспонировать матрицу — это не эффективно.
Первейший вопрос от меня как работающего с тобой в паре — имеет ли значение эффективность на текущем этапе работы над задачей, учитывая ВСЁ? очень много проблеми возникает, когда начинаешь заниматься эффективностью раньше, чем она того заслуживает.
Можно переформулировать вопрос — мы учимся писать эффективный код, используя эффективные численные методы, или мы решаем бизнес задачу?
Инами словами — что мы экономим — такты процессора или человеко-часы?
Вспомним IBM с его принципом "Машина должна работать, человек — думать".
FDS>А теперь представим себе, что это не просто матрица, а часть другой матрицы (это не надуманная задача). Тогда к каждой функции ещё надо будет прибавлять по два параметра — FDS>начальные и конечные индексы суммирования.
Первое, что приходит в голову — Граничный объект. Рефакторинг "Введение граничного объекта (объекта параметров)"
FDS>Этот код будет не читаемым и трудно написуемым — убедился на собственном опыте. И как это сделать не отстойно?
точно вторые мозги. хотя бы на 50% загрузки, если мало человек и часов...
FDS>В итоге я прихожу к самому удобному (я не шучу, я так и делал) варианту — когда нужно что-то перемножать я просто пишу код этого перемножения (цикл с двукратной вложенностью) прямо в код, без всяких вызовов. Получается, что с небольшими комментариями этот код — самый удобный для написания и чтения (ну, лично для меня) и вызывает наименьшее число ошибок в использовании (собственно, ошибки в использовании функции перемножения перестали появляться вообще).
FDS>Дык, во всех вариантах код — отстой. Во всех, я сам убедился (судя по этой статье). Может кто знает другой вариант?
Бороться и искать. Найти и рассказать всем (выложить в блог, если не лень ).
Re[3]: Тривиальная задача - как неотстойно написать?
Здравствуйте, moudrick, Вы писали:
FDS>>Вопрос по неотстойному написанию: допустим мне нужно написать код перемножения двух матриц.
M>Вообще всегда критерием является практика. Если задача разовая и сделать надо быстро — можно и забить. M>Но если этот исходник будет потом меняться — тут начинаются траблы, и чтобы написать правильно M>- могут понадобиться еще одни мозги на 100% загрузки, что в широком обиходе называется "парное программирование". Чтобы двое полноценных можгов воспринимали задачу во всей ее полноте и стремились получить максимальную пользу (business value).
К чему это?
FDS>>Я могу его написать 4 функциями, соответствующими AijBjk; AjiBjk; AijBkj; AjiBkj; FDS>>Но это будет дублирование кода, причём почти copy-paste — то есть код — отстой M>На чем пишем? Обобщенное программирование, вполне возможно, спасет отца русской демократии
Это "обобщённое программирование" и есть. Мне приходилось это реализовывать на Delphi, C++ и C#.
FDS>>Я могу написать его 1 функцией, с такими параметрами MatrixMul(A, B, TransposeA, TransposeB), заставив передавать в функцию параметры транспонирования матрицы — но это не удобно для использования
FDS>>Можно вообще написать только внутреннее произведение и транспонировать матрицу — это не эффективно. M>Первейший вопрос от меня как работающего с тобой в паре — имеет ли значение эффективность на текущем этапе работы над задачей, учитывая ВСЁ? очень много проблеми возникает, когда начинаешь заниматься эффективностью раньше, чем она того заслуживает.
M>Можно переформулировать вопрос — мы учимся писать эффективный код, используя эффективные численные методы, или мы решаем бизнес задачу? M>Инами словами — что мы экономим — такты процессора или человеко-часы? M>Вспомним IBM с его принципом "Машина должна работать, человек — думать".
Мы экономим человеко-часы сотрудника, который будет ждать, пока задача посчитается, то есть решаем реальную бизнес-задачу.
FDS>>А теперь представим себе, что это не просто матрица, а часть другой матрицы (это не надуманная задача). Тогда к каждой функции ещё надо будет прибавлять по два параметра — FDS>>начальные и конечные индексы суммирования. M>Первое, что приходит в голову — Граничный объект. Рефакторинг "Введение граничного объекта (объекта параметров)"
Честно говоря, не понимаю, как это сделать так, что бы написать неотстойны код. Поясните, пожалуйста, на примере (в смысле — код на естетсвенном языке)
FDS>>Этот код будет не читаемым и трудно написуемым — убедился на собственном опыте. И как это сделать не отстойно? M>точно вторые мозги. хотя бы на 50% загрузки, если мало человек и часов...
Зачем лишние мозги? если код трудночитаемый — он отстой, и лишние мозги тут не причём. Вы неправильно понимаете концепцию парного программирования — второй человек, фактически контроллёр и только потом — помошник
FDS>>В итоге я прихожу к самому удобному (я не шучу, я так и делал) варианту — когда нужно что-то перемножать я просто пишу код этого перемножения (цикл с двукратной вложенностью) прямо в код, без всяких вызовов. Получается, что с небольшими комментариями этот код — самый удобный для написания и чтения (ну, лично для меня) и вызывает наименьшее число ошибок в использовании (собственно, ошибки в использовании функции перемножения перестали появляться вообще).
FDS>>Дык, во всех вариантах код — отстой. Во всех, я сам убедился (судя по этой статье). Может кто знает другой вариант? M>Бороться и искать. Найти и рассказать всем (выложить в блог, если не лень ).
Вы хотели сказать — бороться и писать
Блога нет Я уже несколько лет разными способами пишу эту задачу и каждый раз не удовлетворён тем, что получилось.
ANS>Это так, но твоей проблемой будет чей-то код, с которым тебе прийдётся поработать и который отстойный по определениям этой статьи.
Интересно, являлся ли отстойным по определениям этой статьи код Chrysler Comprehensive Compensation, когда ее выкинули на помойку?
Предполагаю, что нет.
Хотя вопрос можно считать риторическим.
Здравствуйте, moudrick, Вы писали:
M>В варианте для нашего личного использования у нас был прямой глагольный перевод, который звучал так — "Почуму ваш код сосёт". Или даже — "Почему твой код сосёт". Но такая грубость, конечно, неприемлема на " the best russian-languaged resource for developers", как я описал RSDN в письме с запросом к автору на публикацию перевода.
А что такое "прямой глагольный перевод"? Может все же стоило поискать информацию об этимологии идиомы suck?
В тех же Проблемах перевода, по-моему уже обсуждали.
Re[4]: Тривиальная задача - как неотстойно написать?
M>>Вообще всегда критерием является практика. Если задача разовая и сделать надо быстро — можно и забить. M>>Но если этот исходник будет потом меняться — тут начинаются траблы, и чтобы написать правильно M>>- могут понадобиться еще одни мозги на 100% загрузки, что в широком обиходе называется "парное программирование". Чтобы двое полноценных можгов воспринимали задачу во всей ее полноте и стремились получить максимальную пользу (business value).
FDS>К чему это?
Что именно?
FDS>>>А теперь представим себе, что это не просто матрица, а часть другой матрицы (это не надуманная задача). Тогда к каждой функции ещё надо будет прибавлять по два параметра — FDS>>>начальные и конечные индексы суммирования. M>>Первое, что приходит в голову — Граничный объект. Рефакторинг "Введение граничного объекта (объекта параметров)" FDS>Честно говоря, не понимаю, как это сделать так, что бы написать неотстойны код. Поясните, пожалуйста, на примере (в смысле — код на естетсвенном языке)
К сожалению, не получилось найти готового примера. Но хорошие примеры точно есть в книге «Рефакторинг» Мартина Фаулера
(Fowler's "Refactoring"). Если где-то поблизости от Вас имеется экземпляр, рекомендую обратиться именно к нему.
FDS>>>Этот код будет не читаемым и трудно написуемым — убедился на собственном опыте. И как это сделать не отстойно? M>>точно вторые мозги. хотя бы на 50% загрузки, если мало человек и часов...
FDS>Зачем лишние мозги? если код трудночитаемый — он отстой, и лишние мозги тут не причём. Вы неправильно понимаете концепцию парного программирования — второй человек, фактически контроллёр и только потом — помошник
Это где же такое написано и/или сказано?
Второй человек — активный участник, который может в нужный момент перехватить управление на себя и стать первым.
Или Вы считаете штурмана папссивным контролером?
В реальном парном программировании далеко не всегда получается так, что тот, кто за рулём, тот и тормозит...
FDS>>>В итоге я прихожу к самому удобному (я не шучу, я так и делал) варианту — когда нужно что-то перемножать я просто пишу код этого перемножения (цикл с двукратной вложенностью) прямо в код, без всяких вызовов. Получается, что с небольшими комментариями этот код — самый удобный для написания и чтения (ну, лично для меня) и вызывает наименьшее число ошибок в использовании (собственно, ошибки в использовании функции перемножения перестали появляться вообще).
FDS>>>Дык, во всех вариантах код — отстой. Во всех, я сам убедился (судя по этой статье). Может кто знает другой вариант? M>>Бороться и искать. Найти и рассказать всем (выложить в блог, если не лень ). FDS> Вы хотели сказать — бороться и писать
Именно искать. В процессе написания, естественно
M>>В варианте для нашего личного использования у нас был прямой глагольный перевод, который звучал так — "Почуму ваш код сосёт". Или даже — "Почему твой код сосёт". Но такая грубость, конечно, неприемлема на " the best russian-languaged resource for developers", как я описал RSDN в письме с запросом к автору на публикацию перевода.
B>А что такое "прямой глагольный перевод"?
Это мой экспромт-неологизм. Термин не является общепринятым даже среди меня, но надеюсь, он понятен и понят однозначно
>Может все же стоило поискать информацию об этимологии идиомы suck? B>В тех же Проблемах перевода, по-моему уже обсуждали.
Здравствуйте, moudrick, Вы писали:
M>>>Вообще всегда критерием является практика. Если задача разовая и сделать надо быстро — можно и забить. M>>>Но если этот исходник будет потом меняться — тут начинаются траблы, и чтобы написать правильно M>>>- могут понадобиться еще одни мозги на 100% загрузки, что в широком обиходе называется "парное программирование". Чтобы двое полноценных можгов воспринимали задачу во всей ее полноте и стремились получить максимальную пользу (business value).
FDS>>К чему это? M>Что именно?
То, что выше Кстати, есть проекты в которых парное программирование не приемлемо технически (или экономически)
FDS>>>>А теперь представим себе, что это не просто матрица, а часть другой матрицы (это не надуманная задача). Тогда к каждой функции ещё надо будет прибавлять по два параметра — FDS>>>>начальные и конечные индексы суммирования. M>>>Первое, что приходит в голову — Граничный объект. Рефакторинг "Введение граничного объекта (объекта параметров)" FDS>>Честно говоря, не понимаю, как это сделать так, что бы написать неотстойны код. Поясните, пожалуйста, на примере (в смысле — код на естетсвенном языке)
M>К сожалению, не получилось найти готового примера. Но хорошие примеры точно есть в книге «Рефакторинг» Мартина Фаулера
(Fowler's "Refactoring"). Если где-то поблизости от Вас имеется экземпляр, рекомендую обратиться именно к нему.
Где-то поблизости нету. Я имею ввиду — представьте своё видение решения описанной мной задачи на естественном языке, оформелнном в виде кода. Я думаю, Фаулер об этой задаче и не заикался, к тому же я и сам могу привести примеры к этому правилу, только я не понимаю, как вы собираетесь его применять к моей задаче.
Есть группа параметров, естественным образом связанных друг с другом.
Замените их объектом.
Где тут группа параметров?
FDS>>>>Этот код будет не читаемым и трудно написуемым — убедился на собственном опыте. И как это сделать не отстойно? M>>>точно вторые мозги. хотя бы на 50% загрузки, если мало человек и часов...
FDS>>Зачем лишние мозги? если код трудночитаемый — он отстой, и лишние мозги тут не причём. Вы неправильно понимаете концепцию парного программирования — второй человек, фактически контроллёр и только потом — помошник M>Это где же такое написано и/или сказано? M>Второй человек — активный участник, который может в нужный момент перехватить управление на себя и стать первым. M>Или Вы считаете штурмана папссивным контролером? M>В реальном парном программировании далеко не всегда получается так, что тот, кто за рулём, тот и тормозит...
1. Я и не говорю, что второй программист не может стать в некоторый момент первым, а потом отдать кодирование назад, и так постоянно
2. Второй программист — не штурман. Второй программист не пассивный контролёр, а активный, Смысл правила заключается в том, что второй человек помогает оформить задумку первого и выявляет в ней ошибки и неточности. В любом случае, парное программирование существует для предотвращения ошибок, а не для того, что бы решать более трудные задачи
3. Да, тормозит обычно тот, кто за клавиатурой, и только по мнению тех, кто не за ней
Здравствуйте, moudrick, Вы писали:
FDS>>Если этот человек бросился учить кого-то, значит он ставит себя выше других. По крайней мере, если он это делает такими методами. И преамбулы тут не помогут.
M>Не согласен. "Поучений" здесь меньше всего. Это лишь констатация факта. Вы это можете признать, а можете не признать. Это Ваш выбор. Выбирайте с умом.
1. Я не употреблял слово "поучения" — у него другой смысловой оттенок.
2. Это статья пытается подействовать на читателя обучающе — то есть пытается научить его писать не отстойный код или, по крайней мере, научить его понимать, что код отстойный.
Re[6]: Тривиальная задача - как неотстойно написать?
M>>>>Вообще всегда критерием является практика. Если задача разовая и сделать надо быстро — можно и забить. M>>>>Но если этот исходник будет потом меняться — тут начинаются траблы, и чтобы написать правильно M>>>>- могут понадобиться еще одни мозги на 100% загрузки, что в широком обиходе называется "парное программирование". Чтобы двое полноценных можгов воспринимали задачу во всей ее полноте и стремились получить максимальную пользу (business value). FDS>>>К чему это? M>>Что именно? FDS>То, что выше Кстати, есть проекты в которых парное программирование не приемлемо технически (или экономически)
Там много всего краями упмянуто. Если речь только о парном программировании и его невозможности — что ж. Придется работать одному. За двоих. Как — Вам решать самому.
Re[6]: Тривиальная задача - как неотстойно написать?
FDS>>>>>Этот код будет не читаемым и трудно написуемым — убедился на собственном опыте. И как это сделать не отстойно? M>>>>точно вторые мозги. хотя бы на 50% загрузки, если мало человек и часов... FDS>>>Зачем лишние мозги? если код трудночитаемый — он отстой, и лишние мозги тут не причём. Вы неправильно понимаете концепцию парного программирования — второй человек, фактически контроллёр и только потом — помошник M>>Это где же такое написано и/или сказано? M>>Второй человек — активный участник, который может в нужный момент перехватить управление на себя и стать первым. M>>Или Вы считаете штурмана папссивным контролером? M>>В реальном парном программировании далеко не всегда получается так, что тот, кто за рулём, тот и тормозит... FDS>1. Я и не говорю, что второй программист не может стать в некоторый момент первым, а потом отдать кодирование назад, и так постоянно FDS>2. Второй программист — не штурман. Второй программист не пассивный контролёр, а активный, Смысл правила заключается в том, что второй человек помогает оформить задумку первого и выявляет в ней ошибки и неточности. В любом случае, парное программирование существует для предотвращения ошибок, а не для того, что бы решать более трудные задачи
Для того, чтобы подать идею юнит-теста к тому, что пишет рулевой — что именно и как именно следует затестить.
Простая задача? Тогда скажите, как надо юнит-тестить код к Вашей задаче?
Какие еще более трудые задачи Вы имели в виду?
Кроме того, есть такое понятие code review, Если практикуется парное программирование, практика code review становится перманентной, не мешая при этом всем тем задачам, которые отметили Вы в качестве задач, решаемых парным программированием.
FDS>3. Да, тормозит обычно тот, кто за клавиатурой, и только по мнению тех, кто не за ней Каждый мнит себя стратегом, видя бой со стороны (с) знаменитый поэт.
Re[7]: Тривиальная задача - как неотстойно написать?
FDS>>>>>А теперь представим себе, что это не просто матрица, а часть другой матрицы (это не надуманная задача). Тогда к каждой функции ещё надо будет прибавлять по два параметра — начальные и конечные индексы суммирования. M>>>>Первое, что приходит в голову — Граничный объект. Рефакторинг "Введение граничного объекта (объекта параметров)" FDS>>>Честно говоря, не понимаю, как это сделать так, что бы написать неотстойны код. Поясните, пожалуйста, на примере (в смысле — код на естетсвенном языке)
M>>К сожалению, не получилось найти готового примера. Но хорошие примеры точно есть в книге «Рефакторинг» Мартина Фаулера
(Fowler's "Refactoring"). Если где-то поблизости от Вас имеется экземпляр, рекомендую обратиться именно к нему.
FDS>Где-то поблизости нету. Я имею ввиду — представьте своё видение решения описанной мной задачи на естественном языке, оформелнном в виде кода. Я думаю, Фаулер об этой задаче и не заикался, к тому же я и сам могу привести примеры к этому правилу, только я не понимаю, как вы собираетесь его применять к моей задаче.
FDS>
Есть группа параметров, естественным образом связанных друг с другом.
FDS>Замените их объектом.
FDS>Где тут группа параметров?
Вы сами их назвали в описании деталей Вашей задачи.
1й очевидный проход — группа параметров выделена жирным в Вашей цитате.
Два параметра — начальные и конечные индексы суммирования — превращаются в один — диапазон суммирования.
Если по прежнему отстой — 2й проход — граничный объект выделен жирным курсивом
Часть другой матрицы (MatrixPart) — это матрица с диапазоном суммирования.
Наш организм может позволить и дальнейшие абстракции.
Сложнее будет. если функция Ваша уже является членом Вашего класса матриц. но и это излечимо. Всё излечимо.
Что это нам даёт или может нам дать в дальнейшем, а также что делать, если опять отстой — об это лучше говорить на языке паттернов проектования...
Рекомендую однакомиться с паттернами проектирования Go4:
online (примеры на C#) anoter online (просто список, среди других групп паттернов) book (примеры на С++) another book (этого издания я в руках еще не держал. Судя по оглавлению — перепечатка book)
Re[8]: Тривиальная задача - как неотстойно написать?
Здравствуйте, moudrick, Вы писали:
FDS>>>>>>А теперь представим себе, что это не просто матрица, а часть другой матрицы (это не надуманная задача). Тогда к каждой функции ещё надо будет прибавлять по два параметра — начальные и конечные индексы суммирования. M>>>>>Первое, что приходит в голову — Граничный объект. Рефакторинг "Введение граничного объекта (объекта параметров)" FDS>>>>Честно говоря, не понимаю, как это сделать так, что бы написать неотстойны код. Поясните, пожалуйста, на примере (в смысле — код на естетсвенном языке) FDS>>
Есть группа параметров, естественным образом связанных друг с другом.
FDS>>Замените их объектом.
FDS>>Где тут группа параметров?
M>Вы сами их назвали в описании деталей Вашей задачи.
M>1й очевидный проход — группа параметров выделена жирным в Вашей цитате. M>Два параметра — начальные и конечные индексы суммирования — превращаются в один — диапазон суммирования.
Это даже ещё неудобней — мне придётся создавать структуру или даже объект, который будет хранить эти диапазоны — лишний код, к тому же ещё более загромождённый.
M>Если по прежнему отстой — 2й проход — граничный объект выделен жирным курсивом M>Часть другой матрицы (MatrixPart) — это матрица с диапазоном суммирования.
Нельзя: матрица — неделимый объект. Опять же по вопросам экономии памяти и эффективности.
M>Наш организм может позволить и дальнейшие абстракции.
Хм...
M>Сложнее будет. если функция Ваша уже является членом Вашего класса матриц. но и это излечимо. Всё излечимо.
M>Что это нам даёт или может нам дать в дальнейшем, а также что делать, если опять отстой — об это лучше говорить на языке паттернов проектования...
M>Рекомендую однакомиться с паттернами проектирования Go4:
Хм. Не понял, чем они помогут... Тут в том то и прикол, что задачка в общем то функциональная с одной стороны, а с другой стороны — в объекты её запихивать 1. довольно не эффектино, 2. Нечитаемо, так как задачка всё-таки именно для функционального стиля и добавление классов получается надуманным (пока я не увидел другого).
M>>1й очевидный проход — группа параметров выделена жирным в Вашей цитате. M>>Два параметра — начальные и конечные индексы суммирования — превращаются в один — диапазон суммирования.
FDS>Это даже ещё неудобней — мне придётся создавать структуру или даже объект, который будет хранить эти диапазоны — лишний код, к тому же ещё более загромождённый.
Если класс устранит дублирование, лишний небольшой код при его определении
обязательно компенсируется большей понячтностью и местами сокращением кода
1. в местах вызова метода с граничным объектом
2. в теле фунции при использовании параметров.
Загроможденности представить не могу. Это надо натуру смотреть.
M>>Если по прежнему отстой — 2й проход — граничный объект выделен жирным курсивом M>>Часть другой матрицы (MatrixPart) — это матрица с диапазоном суммирования. FDS>Нельзя: матрица — неделимый объект. Опять же по вопросам экономии памяти и эффективности.
Как же так? Вы же пишете на С++? (Думаю, да, перед Вами же Дамокловым мечом висит требование эффективности)
Дык а С++ ведь позиционирует себя как язык, в котором парадигмы ООП можно применить на практике при требовании бескомпромиссной эффективности (неточная перефразировка слов из книги Б.Страуструпа "Дизайн и эволюция С++". Если надо — поищу точную цитату)
Для этого в языке предусмотрен целый ряд средств и соглашений,
вполне согласованных с реализацией ООП в С++, как-то: ссылочные типы (references, &), шаблоны (templates), inline-методы, указатели на члены. всего сразу и не вспомнишь...
Если ваш компилятор неэффективно компилирует эффективный код — что ж.
Возможно Вы неверно написали Ваш код и ошибочно считаете его эффективным.
А возможно Вам енадо сменить компилятор.
Я предполагаю первое с большей вероятностью.
Либо Вы совсем не пишете этот код, не знаю, как ег онаписать эффективно.
Вас никто не заставляет делить Ваш объект. Вам всего лишь надо его инкапсулировать.
С++ при правильном его использовании позволит Вам это сделать без потери эффективности как по сокости выполнения, так и по занимаемой памяти.
M>>Что это нам даёт или может нам дать в дальнейшем, а также что делать, если опять отстой — об это лучше говорить на языке паттернов проектования...
M>>Рекомендую однакомиться с паттернами проектирования Go4:
FDS>Хм. Не понял, чем они помогут... Тут в том то и прикол, что задачка в общем то функциональная с одной стороны, а с другой стороны — в объекты её запихивать 1. довольно не эффектино, 2. Нечитаемо, так как задачка всё-таки именно для функционального стиля и добавление классов получается надуманным (пока я не увидел другого).
Если Вы видите задачу как функциональную — так и решайте.
Однако, об избавлении кода от отстойности в рамках функционального стиля мне ничего неизвестно...
Кстати, Вы натолкнули меня на мысль (возможно. неверную), что функциональный стиль местами не в состоянии бороться с отстойностью кода...
Если это так — тогда перед Вами выбор. Выбирайте с умом (с) Dave Astels
фK>>>Если в процессе разработки резко возникает необходимость в неизвестной ранее фиче, это всего лишь означает, что ПМ ее проворонил на стадии формирования списка фич. M>>Насколько часто формируется этот список фич?
K>После выпуска каждой версии.
[........поскипано.........]
M>>Кстати, в XP тоже есть некий порядок в планировании имплементации фич. Но в силу "Small Releases" ими можно гибче управлять, чаще добавлять/изменять без ущера качеству разрабатываемого продукта. Частота зависит от длительности итерации. Итерации обычно короткие — неделя или две. Подкидывать можно перманентно, где перманентно означает — в начале итерации.
K>У нас так и происходит. И для этого совсем не обязательно внедрять XP. Хотя, апологеты XP думают иначе, конечно
Я апологет XP. Я с Вами согласен — не обязательно. Но прошу согласиться со мной в том, что можно.
А я бы даже добавил — рекомендательно.
Кроме того. Вы не уточнили размер итерации.
XP характеризуется предельно кортокими итерациями.
Чаще всего это 1 неделя или 2 недели — Small releases.
Потому добавка фичи у Вас и добавка фичи при использовании XP по срокам могут отличаться на месяцы.
Re[2]: Тривиальная задача - как неотстойно написать?
Здравствуйте, FDSC, Вы писали:
FDS>Дык, во всех вариантах код — отстой. Во всех, я сам убедился (судя по этой статье). Может кто знает другой вариант?
Еще есть вариант ипользовать стиль "литературное программирование", когда код пишется как прийдется, а подстрочником человеческим языком объясняется что он делает, зачем и почему. Для любых хоть сколько-то математических алгоритмов самое то.
Здравствуйте, anvaka, Вы писали:
A>Здравствуйте, FDSC, Вы писали:
FDS>> [..] допустим мне нужно написать код перемножения двух матриц [..] FDS>> Может кто знает другой вариант?
A>На самом верхнем уровне, код выглядит примрено так:
A>
A = B * C;
Это он в C++ так выглядит. И даже там он так не выглядит: как мне записать не внутреннее произведение матриц, например AjiBjk?
A>Как выдлеить подматрицу из матрицы? A>
A> B1 = B.GetMinor(i, j);
A>
Ну и, то есть в B1 мне нужно копировать часть матрицы?
Или там будут только указатели на нужные данные? Это конечно, приемлемо.
Re[9]: Тривиальная задача - как неотстойно написать?
Здравствуйте, moudrick, Вы писали:
M>>>1й очевидный проход — группа параметров выделена жирным в Вашей цитате. M>>>Два параметра — начальные и конечные индексы суммирования — превращаются в один — диапазон суммирования.
FDS>>Это даже ещё неудобней — мне придётся создавать структуру или даже объект, который будет хранить эти диапазоны — лишний код, к тому же ещё более загромождённый.
M>Если класс устранит дублирование, лишний небольшой код при его определении M>обязательно компенсируется большей понячтностью и местами сокращением кода M>1. в местах вызова метода с граничным объектом M>2. в теле фунции при использовании параметров.
M>Загроможденности представить не могу. Это надо натуру смотреть.
Хм. Тут в "тривиальном ответе" нечто подобное предложили. Я кажется понял, хотя это только пол решения
M>>>Если по прежнему отстой — 2й проход — граничный объект выделен жирным курсивом M>>>Часть другой матрицы (MatrixPart) — это матрица с диапазоном суммирования. FDS>>Нельзя: матрица — неделимый объект. Опять же по вопросам экономии памяти и эффективности.
M>Как же так? Вы же пишете на С++? (Думаю, да, перед Вами же Дамокловым мечом висит требование эффективности)
В плане создания временного объекта "матрица", который только указывает на данные решение сойдёт.
M>Если ваш компилятор неэффективно компилирует эффективный код — что ж. M>Возможно Вы неверно написали Ваш код и ошибочно считаете его эффективным.
То есть вы считаете, что если код медленно работает, то он просто не эффективный? Значит, вы не встречались с вычислительно трудоёмкими задачами.
M>Если Вы видите задачу как функциональную — так и решайте. M>Однако, об избавлении кода от отстойности в рамках функционального стиля мне ничего неизвестно...
M>Кстати, Вы натолкнули меня на мысль (возможно. неверную), что функциональный стиль местами не в состоянии бороться с отстойностью кода...
С мыслью согласен. Хотя ещё не всё решено и в ООП
Re[3]: Тривиальная задача - как неотстойно написать?
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, FDSC, Вы писали:
FDS>>Дык, во всех вариантах код — отстой. Во всех, я сам убедился (судя по этой статье). Может кто знает другой вариант? M>Еще есть вариант ипользовать стиль "литературное программирование", когда код пишется как прийдется, а подстрочником человеческим языком объясняется что он делает, зачем и почему. Для любых хоть сколько-то математических алгоритмов самое то.
Я очень не люблю этот стиль, хотя часто я так и делаю (стараясь, что бы и код был понятен).
Но ведь тут вся загвоздка, что писать его то же не удобно
Да и потом — это же только пример, как трудно написать неотстойный код даже в такой лёгкой задаче
Re[10]: Тривиальная задача - как неотстойно написать?
M>>Если ваш компилятор неэффективно компилирует эффективный код — что ж. M>>Возможно Вы неверно написали Ваш код и ошибочно считаете его эффективным.
FDS>То есть вы считаете, что если код медленно работает, то он просто не эффективный? Значит, вы не встречались с вычислительно трудоёмкими задачами.
Встречался. Правда, крайним разом это было на моей дипломной работе, т.е. достаточно давно.
В бизнес-практике мне не приходилось сталкиваться с такими задачами, либо же они так или иначе решались без участия моего кода.
Я хотел сказать, что в С++ можно выбрать достаточно много разных вариантов представления,
И чтобы выбрать наиболее эффективный для решения Вашей задачи, надо очень хорошо представлять, что Вы делаете, и что потом будет делать компилятор с Вашим кодом. А для этого нужно очень хорошо знать философию языка.
А насчёт вычислительной трудоёмкости — мне известны не только вычислительно трудоёмнкие задачи, но и вообще неразрешимые (алгоритмически)
Re[4]: Тривиальная задача - как неотстойно написать?
Здравствуйте, FDSC, Вы писали:
FDS>Вопрос по неотстойному написанию: допустим мне нужно написать код перемножения двух матриц.
FDS>Я могу его написать 4 функциями, соответствующими AijBjk; AjiBjk; AijBkj; AjiBkj; FDS>Но это будет дублирование кода, причём почти copy-paste — то есть код — отстой
[...]
Не отстоем будет макра, которая сгенерит хороший и оптимальный код в зависимости от параметров.
И в ней, понятное дело, никакого "почти copy&paste" не будет.
FDS>В итоге я прихожу к самому удобному (я не шучу, я так и делал) варианту — когда нужно что-то перемножать я просто пишу код этого перемножения (цикл с двукратной вложенностью) прямо в код, без всяких вызовов.
А я в этой ситуации использую макрос. Который, конечно же, компилируется в тот же самый код, что у вас. Только мой код читабельней и сопровождабельней вашего на пару порядков.
FDS>Дык, во всех вариантах код — отстой. Во всех, я сам убедился (судя по этой статье). Может кто знает другой вариант?
Мой вариант — не отстой. Легко тестируемый, хорошо комментируемый, никакого дублирования функциональности.
А, ну ещё проблемка — не во всех языках это возможно. К некоторым особенно ущербным языкам даже внешних макропроцессоров не полагается. Хорошо, что для Java такой макропроцессор имеется в наличии!
Re[3]: Тривиальная задача - как неотстойно написать?
Здравствуйте, Miroff, Вы писали:
M>Еще есть вариант ипользовать стиль "литературное программирование", когда код пишется как прийдется, а подстрочником человеческим языком объясняется что он делает, зачем и почему. Для любых хоть сколько-то математических алгоритмов самое то.
Код пишется не как попало, а с чёткой структурой и с разделением на функциональные единицы. Для этого в большинстве средтсв литературного программирования есть простенькая макпроподстановка, так что можно писать:
Функция делающая бла-бла-бла по растакому-то алгоритму, оценка производительности делалась так-то, и вообще, вот вам цитата из Пушкина:...
void thefunction(blabla bubu) {
Тело этой функции полностью совпадает с телом функций такой-то, так что здесь мы это комментировать не будем...
@<FunctionCode>
}
Здравствуйте, moudrick, Вы писали:
M>>>Кстати, в XP тоже есть некий порядок в планировании имплементации фич. Но в силу "Small Releases" ими можно гибче управлять, чаще добавлять/изменять без ущера качеству разрабатываемого продукта. Частота зависит от длительности итерации. Итерации обычно короткие — неделя или две. Подкидывать можно перманентно, где перманентно означает — в начале итерации. K>>У нас так и происходит. И для этого совсем не обязательно внедрять XP. Хотя, апологеты XP думают иначе, конечно M>Я апологет XP. Я с Вами согласен — не обязательно. Но прошу согласиться со мной в том, что можно. M>А я бы даже добавил — рекомендательно.
Я бы порекомендовал изучить несколько методик разработки ПО. Потом хорошенько подумать. Потом еще раз хорошенько подумать и решить, какие принципы этих методик удовлетворяют внутриконторной планке "цена внедрения/отдача". Потом еще раз хорошенько подумать и начинать по одному их внедрять, внимательно наблюдая за эффектом. После внедрения, хорошенько подумав, решить, а принесут ли другие, "забытые" принципы методик схожий эффект? При утвердительном ответе, хорошенько подумав, повторить.
Это я к тому, что XP — не панацея. Где-то оно сработает, а где-то совсем нет. Где-то оно могло бы сработать без парного программирования, но из-за того, что апологет был апологетом, он не стал его внедрять. Think different!
M>Кроме того. Вы не уточнили размер итерации.
От двух недель до месяца.
If a shark stops swimming, it will die. Don't stop swimming, Mr. Mulder.
Every epic equalizer is iso (c)
M>>>>Кстати, в XP тоже есть некий порядок в планировании имплементации фич. Но в силу "Small Releases" ими можно гибче управлять, чаще добавлять/изменять без ущера качеству разрабатываемого продукта. Частота зависит от длительности итерации. Итерации обычно короткие — неделя или две. Подкидывать можно перманентно, где перманентно означает — в начале итерации. K>>>У нас так и происходит. И для этого совсем не обязательно внедрять XP. Хотя, апологеты XP думают иначе, конечно M>>Я апологет XP. Я с Вами согласен — не обязательно. Но прошу согласиться со мной в том, что можно. M>>А я бы даже добавил — рекомендательно.
K>Я бы порекомендовал изучить несколько методик разработки ПО. Потом хорошенько подумать. Потом еще раз хорошенько подумать и решить, какие принципы этих методик удовлетворяют внутриконторной планке "цена внедрения/отдача". Потом еще раз хорошенько подумать и начинать по одному их внедрять, внимательно наблюдая за эффектом. После внедрения, хорошенько подумав, решить, а принесут ли другие, "забытые" принципы методик схожий эффект? При утвердительном ответе, хорошенько подумав, повторить.
K>Это я к тому, что XP — не панацея. Где-то оно сработает, а где-то совсем нет. Где-то оно могло бы сработать без парного программирования, но из-за того, что апологет был апологетом, он не стал его внедрять. Think different!
Парное программирование — лишь одна из практик. Как и любая другая практика XP.
И применять ее надо, если есть основания полагать, что она даст эффект.
Практики XP всегда применяются целыми пучками, и есть масса проверенных рекомендаций, когда как и почему следует комбинировать практики.
Потому — надо применять практику или нет — каждый раз решается отдельно.
Полагаешь, что она не будет эффективна — не применяй.
А чтобы парное программирование дало эффект, надо чтобы каждый участник пары понимал, как оно работает.
И учился у напарника тому, в чем тот более опытный и знающий, не стесняясь делиться с напарником тем, в чем сам более сведущ.
M>>Кроме того. Вы не уточнили размер итерации.
K>От двух недель до месяца.
Э, да Вы похоже работаете в духе agile. Учитывая то что Вы писали выше по треду.
Здравствуйте, moudrick, Вы писали:
M>>>Я апологет XP. Я с Вами согласен — не обязательно. Но прошу согласиться со мной в том, что можно. M>>>А я бы даже добавил — рекомендательно.
M>Парное программирование — лишь одна из практик. Как и любая другая практика XP. M>И применять ее надо, если есть основания полагать, что она даст эффект.
M>Э, да Вы похоже работаете в духе agile. Учитывая то что Вы писали выше по треду.
Цитата по памяти, кажется из одной из многих книг по организации проектов разработки ПО — книжка сейчас дома, позже, если надо, могу уточнить название:
Есть несколько шагов обучения воинскому рукопашному исскуству:
Новичка обучают узкому списку приемов. На каждую ситуацию ему говорят — делай так-то. И новичок оттачивает эти приемы до филигранной точности.
Ученику показывают, как известные ему приемы можно объединять, переходить от одной технике к другой и получать новые приемы
...
Мастер о следовании конкретным приемам не заботится. Он в каждый момент анализирует ситуацию, видит множество путей ее решения (и все они правильные), и сосредотачивает свои усилия на максимальном достижении выбранной цели.
А новичок, глядя на мастера, не может взять в толк, почему тот не использует ни один из известных приемов.
Здравствуйте, S-SH, Вы писали:
SS>Здравствуйте, moudrick, Вы писали:
M>>>>Я апологет XP. Я с Вами согласен — не обязательно. Но прошу согласиться со мной в том, что можно. M>>>>А я бы даже добавил — рекомендательно.
M>>Парное программирование — лишь одна из практик. Как и любая другая практика XP. M>>И применять ее надо, если есть основания полагать, что она даст эффект.
M>>Э, да Вы похоже работаете в духе agile. Учитывая то что Вы писали выше по треду.
SS>Цитата по памяти, кажется из одной из многих книг по организации проектов разработки ПО — книжка сейчас дома, позже, если надо, могу уточнить название: SS>
SS>Есть несколько шагов обучения воинскому рукопашному исскуству:
SS>
SS>Новичка обучают узкому списку приемов. На каждую ситуацию ему говорят — делай так-то. И новичок оттачивает эти приемы до филигранной точности.
SS>Ученику показывают, как известные ему приемы можно объединять, переходить от одной технике к другой и получать новые приемы
SS>...
SS>Мастер о следовании конкретным приемам не заботится. Он в каждый момент анализирует ситуацию, видит множество путей ее решения (и все они правильные), и сосредотачивает свои усилия на максимальном достижении выбранной цели.
SS>
SS>А новичок, глядя на мастера, не может взять в толк, почему тот не использует ни один из известных приемов.
Здравствуйте, Кодёнок, Вы писали:
Кё>Обратите внимание на забавную вещь. Содержание статьи — банальные мысли, которые высказывались не раз, в контексте рефакторинга, в контексте методологии XP, и в общих работах по разработке ПО.
Эк мы с тобой почти одновременно-то!
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
M>Что ж, спасибо Вам за развернутый и искренний ответ.
M>К постам, показывающим обоснованность написния этой статьи и её тут появленияя Вас отсылать не буду, т.к. надеюсь Вы внимательно просмотрели тред, который на текущеий момент совесм невелик.
Да, просмотрел. Кроме того, Вашего ответ и ответ Odi$$ey дают пищу для размышлений.
ГВ>>Набор банальностей, риторики и пересказов. M>Вы, наверное, очень умный. Не все, к сожалению, настолько таковы. M>Скажите четсно, встречается ли среди Вашего кода отстойный, согласно признакам, указанным в статье?
Зачем Вам это?
M>[....поскипано много умных вещей.......]
ГВ>>Рассуждения про business-value лишены обоснования: что такое business-valued-код? Создаётся впечатление, что автор владеет каким-то мегазнанием, которым не делится с читателями. Отсюда вопрос: а что это за знание? Или это опять buzzword, вставленное для придания веса своим рассужденям? M>Business-value есть то, что Вы считаете business value.
Десять! Тогда весь код, который написан для тяжёлого framework — business-valued-код, ergo, автор сильно не прав. Нет уж, давайте-ка без субъектных терминов. Либо нечто существует только в голове наблюдателя (мираж, он же — сфероконь), либо его можно выделить по каким-то объективным признакам.
M>Ни более, ни менее. Дао, названное словом, не есть истинное дао (с) Лао Цзы, M>Но почему же оно тогда называется Дао? Наверное для того, чтобы как-то дать понять непосвящённым, что оно все-таки существует?
Осталось только обсудить значение термина "существование".
ГВ>>Четвёртое — дублирование. Мегабанальная вещь, ибо это есмь альфа и омега программирования. Если бы люди не боролись с дублированием, языков высокого уровня попросту бы не было. Такая борьба должна быть в ДНК у програмистов. Ша! Я сказал — у программистов! К тому же в противовес рассужденям о вреде дублирования можно привести не менее абстрактные рассуждения, что, мол, иногда дублирование необходимо, поскольку не ясно, как программа будет развиваться дальше: порой преждевременное склеивание абстракций приносит не меньше головной боли, чем copy&paste.
M>Зравая мысль. Но — в любом случае это Ваш выбор. Выбирайте с умом (с) сабжевая статья.
Не имеет значения, какой именно выбор я сделаю. От этого банальность не перестаёт быть банальностью.
M>Судя по тому, что как Вы сказали, "пруд пруди", прошу — линки в студию M>Причем не меньше пяти разных, их же пруд пруди...
Хорошо , временно снимаю свою апелляцию к "пруд пруди", оставляю только ту часть, которая относится к потере контекста.
M>Зачем надо было переводить статью — я ни до, ни после, нигде не видел настолько компактного изложения и описания порочных практик, которые надо искоренять у себя и, по возможности, у окружающих. Подобно тому, как Чехов, русский классик, призывал "по капле выдавливать из себя раба".
Понятно. Но статью это от недостатков не освобождает.
M>А то, что это описание предельно персонализовано, — дык это достоинство, а не недостаток. К постам, показывающим, что это это достоинство, а не недостаток, я Вас отсылать не буду, т.к. надеюсь Вы внимательно просмотрели тред, который на текущеий момент совесм невелик.
Не понял, что Вы имеете ввиду под "персонализацией". Я вижу, что автор высказывает своё собственное мнение, по большей части являющееся компиляцией уже достаточно известных суждений. Недостаток здесь не в "присутствии автора", а в компиляции и отсутствии контекста.
ГВ>>Прежде всего — очевидное неуважение к читателям: читатели должны мысленно разбираться со стереотипами и buzzwords, свойственными приверженцам определённого стиля разработки, которые при очередной "смене парадигмы" узнали, что 2x2=4 и несут окружающим сокровенный свет этого знания.
M>К постам, показывающим безосновательноть обвинений в оскорблении читателей, я Вас отсылать не буду, т.к. надеюсь Вы внимательно просмотрели тред, который на текущеий момент совесм невелик.
Да, просмотрел, разумеется, но для таких выводов статья даёт основания сама по себе безотносительно наличия комментариев к ней. Или уже стало нормой требовать от читателя прочесть статью, а потом сотню комментариев, в которых раскрывается смысл?
M>Если Вы верно поняли миссию этой статьи, то, вероятно, догадались, что никто не предлагает Вам всерьёз сменить парадигму. Лишь пересмотреть (возможно, еще один лишний раз, если Вы очень умный и начинанный) то, с чем Вы имеете дело в реальности.
Нет, я не понял миссии этой статьи. Но легко могу представить миссию блог-постинга такого содержания.
M>Кстати, будем искать спонсора для перевода этой статьи на индийский?
Думаю, что перевод жизнеописания Бодхидхармы на Бенгали принесёт больше дивидендов.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Odi$$ey, Вы писали:
ГВ>>.. должна быть в ДНК у програмистов. Ша! Я сказал — у программистов! OE>хм, т.е. родился программистом и учиться уже ничему не надо? класс...
Метафора. Это всего лишь метафора.
ГВ>>Вопрос к RSDN Team: такого добра в блогах — пруд пруди, на фига было тратить время на перевод? OE>ну, RSDN Team её и не переводил, и без нас нашлись желающие. А опубликовали потому что статья эта — хороший пинок в направлении к дяденьке Макконнеллу
А... Вон оно что.
ГВ>>Прежде всего — очевидное неуважение к читателям: читатели должны мысленно разбираться со стереотипами и buzzwords, свойственными приверженцам определённого стиля разработки, которые при очередной "смене парадигмы" узнали, что 2x2=4 и несут окружающим сокровенный свет этого знания.
OE>ну и почему мы должны руководствоваться именно этим мнением, а не мнением двух десятков (сейчас) человек, которые не поленились поставить статье положительную оценку
А знаете, я не навязываю своего мнения. Считаете, что публикация таблицы умножения под видом откровения безусловно полезна — я не против. Но и не удивляйтесь ответной иронии и сарказму.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, moudrick, Вы писали:
ГВ>>Хорошо , временно снимаю свою апелляцию к "пруд пруди", оставляю только ту часть, которая относится к потере контекста.
ГВ>>Не понял, что Вы имеете ввиду под "персонализацией". Я вижу, что автор высказывает своё собственное мнение, по большей части являющееся компиляцией уже достаточно известных суждений. Недостаток здесь не в "присутствии автора", а в компиляции и отсутствии контекста.
M>Отсутствие контекста — и есть контекст. Глобальный контекст.
M>
M>Ото всей души желаем вам
M>Счастья, благополучия и глобальности.
M>Глобальные лампочки, глобальные девочки.
M>Хей, закрываешь ли ты свое обнаженное лицо,
M>Когда плачешь за кирпичным окном на пятом этаже?
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>>>Набор банальностей, риторики и пересказов. M>>Вы, наверное, очень умный. Не все, к сожалению, настолько таковы. M>>Скажите четсно, встречается ли среди Вашего кода отстойный, согласно признакам, указанным в статье?
ГВ>Зачем Вам это?
От этого зависит Ваш ответ?
- Очень! Сегодня был лучший день в моей жизни! — сказала она, поднялась на цыпочки и дружески поцеловала его в щеку.
От этого поцелуя он осмелел и обнял ее.
— Ты что? — удивилась она. — Зачем тебе все это?
— Выходи за меня замуж! — сказал он.
— Мы слишком мало с тобой знаем друг друга! — Она попыталась отстраниться.
— Неправда! То, что я узнал сегодня о тебе, мне очень нравится, и я уверен, что мы подходим друг другу!
Любителям подколоть и поострить сообщаю — никакого ахтунга.
Просто вопросы типа "зачем" немедленно вызывают у меня ассоциацию с этим произведением.
На самом деле если Вы понимаете, что часть Вашего кода — отстой, но продолжаете тисать такой же отстойный код, и при этом не хотите в этом признаться хотя бы самому себе, то разве это правильно? И в статье ещё раз подчеркивается, что это неправильно.
И спрашиваю я по банальной причине — хочу узнать, настолько ли Вы идеальны, как это может следовать из Ваших постов.
Здравствуйте, moudrick, Вы писали:
ГВ>>>>Набор банальностей, риторики и пересказов. M>>>Вы, наверное, очень умный. Не все, к сожалению, настолько таковы. M>>>Скажите четсно, встречается ли среди Вашего кода отстойный, согласно признакам, указанным в статье?
ГВ>>Зачем Вам это? M>От этого зависит Ваш ответ?
Нет, это был вежливый уход от ответа на личный вопрос.
M>На самом деле если Вы понимаете, что часть Вашего кода — отстой, но продолжаете тисать такой же отстойный код, и при этом не хотите в этом признаться хотя бы самому себе, то разве это правильно? И в статье ещё раз подчеркивается, что это неправильно.
Такая постановка вопроса ставит оппонента в безвыходное положение: что бы он ни возразил, его высказывание можно свести к тому, что он, мол, не хочет признаться самому себе в том-то и том-то (есть тут у нас мастера по этой части ). А исходный тезис при этом ставится в положение абсолютной истины. Это не смешно, поверьте.
M>И спрашиваю я по банальной причине — хочу узнать, настолько ли Вы идеальны, как это может следовать из Ваших постов.
Возможно, что Вы не знаете: апелляция к личности есть некорректный приём полемики. Вот потому я и не отвечаю на такие вопросы. Суть нашей беседы, как я понимаю, всё-таки не в обсуждении [не]совершеств оппонентов, а в обсуждении статьи, не правда ли?
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, IT, Вы писали:
IT>>>Их задача не найти ошибку в твоём коде, а не дать возможности сломать уже работающий и отлаженный код при будущих его модификациях. И чем больше покрытие кода юнит тестами, тем больше шансов уберечься от подобных проблем.
КД>>Для аналогичных целей также используют assert'ы. В огромных количествах.
IT>Чтобы тебе помогли асёрты так же как юнит тесты, ты должен прогнать через них свой код. И не просто прогнать, а сделать это для разных сценариев. Юнит тесты специально этим и занимаются.
Ну, это. Я стараюсь и то и другое . И третье. Там есть еще четвертое и пятое. А потом оказывается, что пока ты тщательно проектировал, кодировал, тестировал твоя программа становится уже никому не нужна
Напрягает также другое. То что наши программы являются юнит-тестами для разработчиков компиляторов
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, IT, Вы писали:
IT>>>Судя по этому абзацу у тебя у самого неверное представление зачем нужны юнит тесты. Их задача не найти ошибку в твоём коде, а не дать возможности сломать уже работающий и отлаженный код при будущих его модификациях. ГВ>>Вернее — сразу диагностировать поломку. Предотвратить её юнит-тесты не могут. IT>Это не их задача предотвращать. И диагноз они тоже ставить не умеют. Их задача показать является ли код после очередных изменений всё ещё работоспособным или нет.
Они умеют ставить диагноз, для постановки которого создавались.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: Тривиальная задача - как неотстойно написать?
Здравствуйте, moudrick, Вы писали:
FDS>>Но ведь тут вся загвоздка, что писать его то же не удобно M>Код должно быть удобно читать, а не удобно писать. (цитата иитаты из сабжевой статьи)
Здравствуйте, Kolhoz, Вы писали:
K>Здравствуйте, Miroff, Вы писали:
M>>Еще есть вариант ипользовать стиль "литературное программирование", когда код пишется как прийдется, а подстрочником человеческим языком объясняется что он делает, зачем и почему. Для любых хоть сколько-то математических алгоритмов самое то.
K> Код пишется не как попало, а с чёткой структурой и с разделением на функциональные единицы. Для этого в большинстве средтсв литературного программирования есть простенькая макпроподстановка, так что можно писать:
Причём тут макроподстановки?
K> Функция делающая бла-бла-бла по растакому-то алгоритму, оценка производительности делалась так-то, и вообще, вот вам цитата из Пушкина:...
K> void thefunction(blabla bubu) { K> Тело этой функции полностью совпадает с телом функций такой-то, так что здесь мы это комментировать не будем... K> @<FunctionCode> K> }
Copy-Paste — ни за что! Даже если это не прямой copy-paste.
Re[3]: Тривиальная задача - как неотстойно написать?
Здравствуйте, Kolhoz, Вы писали:
K>Здравствуйте, FDSC, Вы писали:
FDS>>Вопрос по неотстойному написанию: допустим мне нужно написать код перемножения двух матриц.
FDS>>Я могу его написать 4 функциями, соответствующими AijBjk; AjiBjk; AijBkj; AjiBkj; FDS>>Но это будет дублирование кода, причём почти copy-paste — то есть код — отстой
K>[...]
K> Не отстоем будет макра, которая сгенерит хороший и оптимальный код в зависимости от параметров. K>И в ней, понятное дело, никакого "почти copy&paste" не будет.
FDS>>В итоге я прихожу к самому удобному (я не шучу, я так и делал) варианту — когда нужно что-то перемножать я просто пишу код этого перемножения (цикл с двукратной вложенностью) прямо в код, без всяких вызовов.
K> А я в этой ситуации использую макрос. Который, конечно же, компилируется в тот же самый код, что у вас. Только мой код читабельней и сопровождабельней вашего на пару порядков.
Макрос — та же функция — в плане чтения и написания. И она так же неудобна
Здравствуйте, adontz, Вы писали:
A>А может надо признать что тезис "код не проходящий регулярное юнит-тестирование — отстой" сам является отстоем?
Это сколько угодно. Я даже больше скажу, есть задачи (ты сам только что приводил пример), которые человечество пока ещё не научилось тестировать автоматически. Есть задачи, в которых применение юнит тестов в разы увеличивает стоимость проекта. Например, это касается задач работающих с базами данных, где помимо самого юнит теста нужно ещё подготовить данные для каждого сценария. Но, в тоже самое время, есть задачи, которые просто немыслимы без юнит тестов, даже если их наличие существенно влияет на стоимость проекта.
Если нам не помогут, то мы тоже никого не пощадим.
КД>Напрягает также другое. То что наши программы являются юнит-тестами для разработчиков компиляторов
Причём только потому что они не делают юнит-тесты сами, потому что:
КД>что пока ты тщательно проектировал, кодировал, тестировал твоя программа становится уже никому не нужна
Я атеист.
FR>>Талмуды гораздо полезней.
M>Читаю. Да за работой за всеми не поспеваю. M>Даже если успеваю поверхностно проыесть, то не всегда успеваю вникнуть.
Некторые необходимо прочесть не один раз.
M>Много Вы прочли талмудов? А много ли осталось непрочтёнными?
Много, и очень много осталось непрочитанных, сейчас есть список примерно из 10 штук которые хотелось бы прочитать.
M>Что будете делать с теми, которые не успели прочесть? M>Там ведь тоже полезные нужные знания!
Ну за всем не успеть, стараюсь читать полезное и интересное.
Здравствуйте, moudrick, Вы писали:
M>>>И если Вы полагаете, что к ней не относитесь, Вы можете её попросту игнорировать. FR>>Я например не желаю быть в такой целевой аудитории, которой плюют в лицо, а она улыбается и говорит спасибо. M>Умейте быть смиренными.
То есть, Вы констатируете, что правильная реакция на эту статью — смирение? Лихо!
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
M>>А Я говорю вам: не противься злому. Но кто ударит тебя в правую щеку твою, обрати к нему и другую
M>>Евангелие от Матфея, 5:39
FR>Я атеист.
Это не мешает уметь быть смиренным в случае необхошдимости.
FR>>>Талмуды гораздо полезней. M>>Читаю. Да за работой за всеми не поспеваю. M>>Даже если успеваю поверхностно проыесть, то не всегда успеваю вникнуть. FR>Некторые необходимо прочесть не один раз.
Тем более это повод к стремлению и умению выражать правильные вещи компактно.
Сравним хотя бы (для иллюстрации) по объему Библию либо сам Талмуд (как имя собственное) с Дао Дэ Цзином.
Библия (христианство) — 66 или 77 книг в зависимости от редакции
Талмуд (иудаизм) — 6 томов + 1 том комментариев. (видел давеча в продаже) Каждый том размером примерно с Библию.
Дао Дэ Цзин (даосизм) — 81 штука достаточно коротких стихов.
Оттветьте, кем лучше быть — христианином, иудеем или даосом? Вариант "атеистом" не предлагать.
Почему — тема отдельной дискуссии и не в этом треде.
M>>Много Вы прочли талмудов? А много ли осталось непрочтёнными? FR>Много, и очень много осталось непрочитанных, сейчас есть список примерно из 10 штук которые хотелось бы прочитать.
M>>Что будете делать с теми, которые не успели прочесть? M>>Там ведь тоже полезные нужные знания! FR>Ну за всем не успеть, стараюсь читать полезное и интересное.
Здравствуйте, moudrick, Вы писали:
FR>>Я атеист.
M>Это не мешает уметь быть смиренным в случае необхошдимости.
Но и не помогает, в отличии от.
FR>>>>Талмуды гораздо полезней. M>>>Читаю. Да за работой за всеми не поспеваю. M>>>Даже если успеваю поверхностно проыесть, то не всегда успеваю вникнуть. FR>>Некторые необходимо прочесть не один раз.
M>Тем более это повод к стремлению и умению выражать правильные вещи компактно.
Так я не против чтобы компактно. Только что бросилась в глаза подпись WolfHound'а
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Слово "просто" там вполне можно заменить на "компактно"
M>Сравним хотя бы (для иллюстрации) по объему Библию либо сам Талмуд (как имя собственное) с Дао Дэ Цзином.
M> M> Библия (христианство) — 66 или 77 книг в зависимости от редакции M> Талмуд (иудаизм) — 6 томов + 1 том комментариев. (видел давеча в продаже) Каждый том размером примерно с Библию. M> Дао Дэ Цзин (даосизм) — 81 штука достаточно коротких стихов. M>
M>Оттветьте, кем лучше быть — христианином, иудеем или даосом? Вариант "атеистом" не предлагать. M>Почему — тема отдельной дискуссии и не в этом треде.
Почему ты мою "религию" обижаешь?
Вообще ты думаешь истина зависит от краткости формулировки?
FR>>Ну за всем не успеть, стараюсь читать полезное и интересное.
M>Время — тоже ресурс. Невосполнимый.
Если читать полезное и интересное, то это не работа а отдых
FR>>>>>Талмуды гораздо полезней. M>>>>Читаю. Да за работой за всеми не поспеваю. M>>>>Даже если успеваю поверхностно проыесть, то не всегда успеваю вникнуть. FR>>>Некторые необходимо прочесть не один раз.
M>>Тем более это повод к стремлению и умению выражать правильные вещи компактно.
FR>Так я не против чтобы компактно. Только что бросилась в глаза подпись WolfHound'а FR>
FR>Пусть это будет просто:
FR>просто, как только можно,
FR>но не проще.
FR>(C) А. Эйнштейн
Респект однозначно. +1. FR>Слово "просто" там вполне можно заменить на "компактно"
M>>Оттветьте, кем лучше быть — христианином, иудеем или даосом? Вариант "атеистом" не предлагать. M>>Почему — тема отдельной дискуссии и не в этом треде.
FR>Почему ты мою "религию" обижаешь?
Правда, в отдельный тред. Это — отдельный разговор. (линка, внтури — ничего личного, просто цитата)
И не сейчас.
FR>Вообще ты думаешь истина зависит от краткости формулировки?
Будем вспоминать различия в компактности СДНФ и проблему её минимизации? (линка)
M>>>>На самом деле если Вы понимаете, что часть Вашего кода — отстой, но продолжаете тисать такой же отстойный код, и при этом не хотите в этом признаться хотя бы самому себе, то разве это правильно? И в статье ещё раз подчеркивается, что это неправильно. ГВ>>>Такая постановка вопроса ставит оппонента в безвыходное положение: что бы он ни возразил, его высказывание можно свести к тому, что он, мол, не хочет признаться самому себе в том-то и том-то (есть тут у нас мастера по этой части ). А исходный тезис при этом ставится в положение абсолютной истины(???). Это не смешно, поверьте.
M>>ставится в положение абсолютной истины(???) M>>В положение абсолютной истины — не ставится. А видимость его абсолютной истинности — это всего лишь, говоря Вашими же словами, метафора.
ГВ>Дело вот в чём: формально код может вполне соответствовать критериям "отстойного" кода, но фактически, к нему может быть не уместно применять ругательство "отстой", потому что причины, по которым он стал и сохраняется таким вполне могут оправдывать существование "отстойного" кода.
[...... поскипано множество достойных аргументов ...........]
ГВ>Вывод? Наглая попытка манипуляции.
Но мы же с Вами духовно грамотные люди и умеем не поддаваться манипуляциям и противостоять им, правда?
Кто не боится помирать, тот и не сможет помереть
... Всё что нас не убивает, то нас делает сильней
M>>>Оттветьте, кем лучше быть — христианином, иудеем или даосом? Вариант "атеистом" не предлагать. M>>>Почему — тема отдельной дискуссии и не в этом треде.
FR>>Почему ты мою "религию" обижаешь? M>Правда, в отдельный тред. Это — отдельный разговор. (линка, внтури — ничего личного, просто цитата) M>И не сейчас.
У тебя на все случаи в жизни есть ссылки с мыслями до конца понятными только тебе?
FR>>Вообще ты думаешь истина зависит от краткости формулировки?
M>Будем вспоминать различия в компактности СДНФ и проблему её минимизации? (линка)
Если еще не знаешь, срочно учи язык J мне кажется он создан для тебя
Хотя это конечно сильно приплести сюда алгебру логики, может мне в ответ дать ссылки на теорию кодирования, чтобы ты почитал о минимальной избыточности?
)
FR>Мне кажется ты должен быть (или стать) его фанатом
Все смеетесь надо мной?
Нет, я не стал бы его фанатом.
И даже не важно, действительно ли это некий язык или стёб, коих в том числе на РСДН обсуждалось немало...
После беглого просмотра я понял, что код на этом языке (или стёбе на тему языка) будет отстоем.
Потому что он не понятен и его трудно прочитать...
Хотя я мог неправильно его понять... Если так — поправьте меня
FR>У тебя на все случаи в жизни есть ссылки с мыслями до конца понятными только тебе?
Не на все. Но я к этому стремлюсь.
У меня и сюда есть линка с мыслями, но не буду её приводить.
Боюсь составить о себе мнение как о излишне нудном типе.
FR>>>Вообще ты думаешь истина зависит от краткости формулировки?
M>>Будем вспоминать различия в компактности СДНФ и проблему её минимизации? (линка)
FR>Если еще не знаешь, срочно учи язык J мне кажется он создан для тебя
Ответ есть тут
FR>Хотя это конечно сильно приплести сюда алгебру логики, может мне в ответ дать ссылки на теорию кодирования, чтобы ты почитал о минимальной избыточности?
А, так Вы — специалист, а я прислал линку с контентом для начинающих? Сорри
О минимальной избыточности читал, даже вроде изучал и сдавал когда-то...
Если вы дадите ссылки
а в них будет быстро заметно нечто существенное, чего раньше не видел или не обращал внимания — поставлю хорошую оценку месаге
[die, overquoting, die!]
M>[...... поскипано множество достойных аргументов ...........]
ГВ>>Вывод? Наглая попытка манипуляции. M>Но мы же с Вами духовно грамотные люди и умеем не поддаваться манипуляциям и противостоять им, правда?
Вот я и противостою. Присоединяйтесь!
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
[......... поскипано множество достойных агументов ..........]
Спасибо за подробный ответ.
GZ>Про выводы — пропаганда. Вобщем, мое личное IMHO тесты делать очень даже полезно, писать понятный, сопровождаемый код тоже весьма полезная вещь, читать такие статьи — бесполезно и вредно. Лучше прочитать нормальную книжку по ООD + refactoring.
FR>>>Вообще ты думаешь истина зависит от краткости формулировки?
M>>Будем вспоминать различия в компактности СДНФ и проблему её минимизации? (линка)
FR>Если еще не знаешь, срочно учи язык J мне кажется он создан для тебя FR>Хотя это конечно сильно приплести сюда алгебру логики, может мне в ответ дать ссылки на теорию кодирования, чтобы ты почитал о минимальной избыточности?
Я о том, что есть много способов сказать одно и то же.
Можно написать толстенный талмуд.
А можно коротенький блогпост.
Здравствуйте, IT, Вы писали:
IT>Но, в тоже самое время, есть задачи, которые просто немыслимы без юнит тестов, даже если их наличие существенно влияет на стоимость проекта.
Здравствуйте, FDSC, Вы писали:
FDS>В итоге я прихожу к самому удобному (я не шучу, я так и делал) варианту — когда нужно что-то перемножать я просто пишу код этого перемножения (цикл с двукратной вложенностью) прямо в код, без всяких вызовов. Получается, что с небольшими комментариями этот код — самый удобный для написания и чтения (ну, лично для меня) и вызывает наименьшее число ошибок в использовании (собственно, ошибки в использовании функции перемножения перестали появляться вообще).
Для многих проектов (я не утвержаю, что для этого) такой стиль программирования — смерть.
<< Под музыку: Аквариум — Новая Песня О Родине >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, remark, Вы писали:
R>>Ага, в одно движение оббегаете несколько отделов. Спрашиваете у каждого, а не использует ли он Ваш класс в своём проекте. Переспрашиваете его ещё раз, что бы повысить достоверность. Потом в одно движение выкачиваете все эти проекты. В одно движение check-out'ите половину файлов проекта. В одно вдижение проводите рефакторинг. В одно движение заливаете всё это на обратно. R>>На следующий день всё равно получаете люлей за несобравшиееся проекты. Потому как всё равно никто не стал думать на вопрос "А используете ли в своём проекте...".
V>Возражение из серии: "а если завтра война?" V>Библиотечный (публичный) код, используемый одновременно со своим развитием во многих проектах встречается не часто, и по отношению к нему применяются совершенно другие правила, чем к прикладному коду в контексте некоторой задачи. Причем этот самый прикладной код (не пуличный) по объему составляет подавляющую часть проектов и именно в этом коде геттеры/сеттеры совершенно не нужны (если понадобятся, они могут быть автоматически созданы одним нажатием на шорткат). То есть выходит, что геттеры/сеттеры не нужны в подавляющей части кода, следовательно, они там будут только мешаться.
Здравствуйте, FDSC, Вы писали:
FDS>>>В итоге я прихожу к самому удобному (я не шучу, я так и делал) варианту — когда нужно что-то перемножать я просто пишу код этого перемножения (цикл с двукратной вложенностью) прямо в код, без всяких вызовов.
K>> А я в этой ситуации использую макрос. Который, конечно же, компилируется в тот же самый код, что у вас. Только мой код читабельней и сопровождабельней вашего на пару порядков.
FDS>Макрос — та же функция — в плане чтения и написания. И она так же неудобна
Вы говорите полную чушь. Макрос это функция, которая генерит код. Пожалуйста, никогда больше не пытайтесь писать о том, в чём не разбираетесь.
Re[2]: Тривиальная задача - как неотстойно написать?
Здравствуйте, FDSC, Вы писали:
FDS>Вопрос по неотстойному написанию: допустим мне нужно написать код перемножения двух матриц.
FDS>Я могу его написать 4 функциями, соответствующими AijBjk; AjiBjk; AijBkj; AjiBkj; FDS>Но это будет дублирование кода, причём почти copy-paste — то есть код — отстой
FDS>Можно вообще написать только внутреннее произведение и транспонировать матрицу — это не эффективно.
FDS>А теперь представим себе, что это не просто матрица, а часть другой матрицы (это не надуманная задача). Тогда к каждой функции ещё надо будет прибавлять по два параметра — FDS>начальные и конечные индексы суммирования.
Напрашиваются прокси "подматрица" и "транспонированная матрица", не выполняющие копирования данных, а являющиеся шлюзами к исходной матрице.
Будет ли это на шаблонах или на виртуальных вызовах — дело хозяйское и зависит от языка. На шаблонах эффективность практически гарантирована.
Другое решение — таки написать мега-функцию с дополнительными параметрами (всё равно в цикле они участвуют — ну будет не от 0 до N, а от X1 до X2) и сокращённые формы к ней для типичных случаев использования.
Прежде всего — очевидное неуважение к читателям: читатели должны мысленно разбираться со стереотипами и buzzwords, свойственными приверженцам определённого стиля разработки, которые при очередной "смене парадигмы" узнали, что 2x2=4 и несут окружающим сокровенный свет этого знания.
, это какие, например?
Если нам не помогут, то мы тоже никого не пощадим.
). А исходный тезис при этом ставится в положение абсолютной истины (???). Это не смешно, поверьте.
. Поэт., такие книги обычно бесполезны, по крайней мере для меня — я остро чуствую что пишу плохой код сам, а когда читаю такие книги — начинаю просто заваливать задания, потому что там нужно искать компромис между тем, что написано в книге и реальной жизнью, а тому, кто может его удачно найти такие книги уже не нужны.
Перекуём баги на фичи!
