[@] C/C++, Mono, D

>> Ну да, рефакторинг... В coding style Вашей фирмы не написано, что >при фиксах не надо лезть в те строки, которые не изменялись?

> Не понял вопроса.

Переименуйте частоимпользуемую функцию в классе и посмотрите на diff в вашей rcs. И ужаснитесь над судьбой того, кому после Вас в этих диффах придётся рыться.

> мосье не рефакторит?

Только в Java.

>> Мсье так часто меняет структуру наследования во время работы над проектом? ССЗБ, ибо Rational Rose да и просто бумажку никто не отменял :)

> Мосье не слышал про XP? Итеративне процессы? TTD =) ? Расскажи всем, что рефакторинги не нужны.

Мир существовал и до появления XP.

> Кстати, autocomplititon мне - удобен, например мне UOE<CtrlSpace> быстрее чем UnsupportedOperatorionException =) и это только малу часть всех удобств иде уровня Eclipse/JDT. Ты просто не в курсе =)

В курсе-в курсе. Но реально юзабельна одна фича -- строенный дебаггер. А то, что у Вас не прокачан скилл "скоростной набор текста" -- не повод для гордости.

> Инекрементальная компиляция без ИДЕ не имеет смысла.

А разработчики make и не знают! :)

TDD напрямую к XP отношения не имеет, так же как и рефакторинг.

>Переименуйте частоимпользуемую функцию в классе и посмотрите на diff в вашей rcs. И ужаснитесь над судьбой того, кому после Вас в этих диффах придётся рыться.

Зачем ему в чём-то рыться, если код вполне понятен, есть достаточно unit-тестов, чтобы понять как оно работает?

>А то, что у Вас не прокачан скилл "скоростной набор текста" -- не повод для гордости.

Так же как и скоростной набор текста повод для гордости секретарши, но никак не разработчика. К тому же, это мартышкина работа, делать то, что за тебя может сделать IDE.

>> Переименуйте частоимпользуемую функцию в классе и посмотрите на diff в вашей rcs. И ужаснитесь над судьбой того, кому после Вас в этих диффах придётся рыться.

> Зачем ему в чём-то рыться, если код вполне понятен, есть достаточно unit-тестов, чтобы понять как оно работает?

Чтобы баги править. Или в программе на "божественной" Java не бывает багов?

>> А то, что у Вас не прокачан скилл "скоростной набор текста" -- не повод для гордости.

> Так же как и скоростной набор текста повод для гордости секретарши, но никак не разработчика. К тому же, это мартышкина работа, делать то, что за тебя может сделать IDE.

Мартышкина работа - использовать инструмент(в данном случае - язык), требующий набора лишнего кода, пусть даже оно делается одной кнопкой(кнопка сделана в костыле для неудобного инструмента дабы сделать его удобнее).

>а теперь вопрос: если я пишу на объектно-ориентированном языке d в ооп парадигме, насколько "комфортно" мне будет использовать сишные либы? нужен набор библиотек именно на d. и если язычок продолжит развиваться, то такой набор несомненно в скором времени будет

D не обьектно-ориентированный - в отличие от тех же Java и C#. он поддерживает ряд парадигм, и ООП не является доминирующим стилем. если бы использовать сишные либы на С++ было проблематично, С++ не стал бы таким популярным. в принципе для D сложностей не намного больше. почему нужен набор библиотек именно на D - аргументация, пожалуйста. вы жаловались на отсутствие инфраструктуры - D её имеет уже благодаря совместимостью с C; собственные библиотеки несомненно появятся со временем тоже; впрочем их есть уже и сейчас

>> Зачем ему в чём-то рыться, если код вполне понятен, есть достаточно unit-тестов, чтобы понять как оно работает?

> Чтобы баги править. Или в программе на "божественной" Java не бывает багов?

И забыл самое главное: чтобы отследить, в какой момент возникла ошибка. Порой это единственный способ локализовать её.

>Чтобы баги править. Или в программе на "божественной" Java не бывает багов?

Для этого нужно писать unit-тесты и заниматься рефакторингом, делать код чистым. А Java тут не при чём, это в любом языке так. Пока не будет ясной картины как работает код и хорошего набора тестов дебаггинг бесполезен. Конечно, если ваша задача "впихнуть" проект заказчику - тогда да, дебаггинг плохого кода имеет смысл.

>> Чтобы баги править. Или в программе на "божественной" Java не бывает багов?

> Для этого нужно писать unit-тесты и заниматься рефакторингом, делать код чистым. А Java тут не при чём, это в любом языке так. Пока не будет ясной картины как работает код и хорошего набора тестов дебаггинг бесполезен. Конечно, если ваша задача "впихнуть" проект заказчику - тогда да, дебаггинг плохого кода имеет смысл.

Я ниже привёл более веский довод. И довод был не против жавы а против злоупотребления рефакторингом.

Простите, какой повод? Повод, чтобы не улучшать код?

> Простите, какой повод? Повод, чтобы не улучшать код?

Повод чтобы не лезть туда, где ничего не менял. А то после таких улучшальщиков хрен разберёшься кто что поправил.

И что? это повод для вообще откзазаться от автомотизированных средств рефакторинга?

>Повод чтобы не лезть туда, где ничего не менял. А то после таких улучшальщиков хрен разберёшься кто что поправил.

Для этого есть опять-же тесты и обязательные комментарии при коммите. Нет комментария - расстрел на месте.

Вы плохо представляете себе современные процессы. Ужаснитесь - в гугле вся кодовая база общая, и кто угодно может менять любой код.

> тесты и обязательные комментарии при коммите. Нет комментария - расстрел на месте.

Нет, сначала пытки >:-E

И что, у гугла нет автоматизированных тестов? И если ты поменял что-то, что ломает тест, этот коммит тоже принимают?

> И что? это повод для вообще откзазаться от автомотизированных средств рефакторинга?

Это повод не пользоваться ими ежедневно. А автоматизация процесса, который происходит редко, не является killing feature.

>> Повод чтобы не лезть туда, где ничего не менял. А то после таких улучшальщиков хрен разберёшься кто что поправил.

> Для этого есть опять-же тесты и обязательные комментарии при коммите. Нет комментария - расстрел на месте.

Произведённое изменение не всегда явно связано с возникшей из-за него ошибкой. В таком случае коммент не поможет.

Допустим, нашли ошибку, которой не было в ноябрьской версии, но которая появилась в декабрьской. Причём ошибка оказалась сложной для обнаружения без влезания в код. Отлично, открываем diff ноябрьской и декабрьской версии и смотрим. А там: один человек поменял 1 букву в названии класса, в результате чего изменилось 100 файлов, второй переименовал функцию и поменял разом 10 файлов, третий что-то нарефакторил... И сидишь неделю разбираешься кто чего сломал...

> Ужаснитесь - в гугле вся кодовая база общая, и кто угодно может менять любой код.

Ужаснулся. В полученной помойке разбираться ни за какие коврижки не стану.

А вот у меня проект на 2 человек, при чём там струкура меняется по мере его роста - возникают новые требования, что то учтено не было, что то по скорости не подошло - так что рефакторинга получается куча. Без деатального описания всё равно не понять. У меня есть ощущение, что ты просто споришь ради спора.=) Возможность быстрой навигации сильно спасает. Например перейти к классу по имени можно и не полному - оч часто надо. или к методу по части имеи.

Ну может у них просто 1) Каждый может узнать адрес по нику 2) У них отменён запрет на телесные наказания =)

> И что, у гугла нет автоматизированных тестов? И если ты поменял что-то, что ломает тест, этот коммит тоже принимают?

И давно Вы видели в реальности тесты, покрывающие все ветки развития событий, все error case и все предполагаемые изменения в коде?

Например, каким тестом отследить, что некоторый набор строковых функций будет в будущем работать с юникодом(ситуация высосана из пальца), если он писался с оглядкой на 8битные кодировки и падает только в случае, если в строке содержится прописная буква "Я"? Придумали? А вот теперь скажите, почему в хелпе к window$ 2k этот баг был? Неужели у микрософта не хватило денег на тестеров?

> Отлично, открываем diff ноябрьской и декабрьской версии и смотрим

И что? Пусть diff очень зашумлен - двоичный поиск рулит, совершенно механическая процедура, просмотра diff'ов не требует вообще.

> А вот у меня проект на 2 человек,

Мой текущий - на 10, так что моя пиписька длиннее :)

> при чём там струкура меняется по мере его роста - возникают новые требования, что то учтено не было,

Это недостаток проектирования.

> что то по скорости не подошло - так что рефакторинга получается куча.

Этот пункт - без вопросов.

> Без деатального описания всё равно не понять. У меня есть ощущение, что ты просто споришь ради спора.=) Возможность быстрой навигации сильно спасает. Например перейти к классу по имени можно и не полному - оч часто надо. или к методу по части имеи.

Это присуще не только Java IDEs.

Кстати, переход по имени в vim: '/ClassName'. Правда я всё-таки быдло и пользуюсь kdevelop :)

> Причём ошибка оказалась сложной для обнаружения без влезания в код

Это как? Юниттестами локализовываем ошибку, и исправляем. Всё. Последний раз я видел сложную ошибку, когда писал на С++ - там ссылка на переменную из сдохшего стека плавала туда-сюда, между макросов и шаблонов. А в нормальных языках процесс поиска ошибки тривиален.

>> Отлично, открываем diff ноябрьской и декабрьской версии и смотрим

> И что? Пусть diff очень зашумлен - двоичный поиск рулит, совершенно механическая процедура, просмотра diff'ов не требует вообще.

Корень ошибки может оказаться раньше чем она начала проявляться.

>Неужели у микрософта не хватило денег на тестеров?

Мозгов не хватило. Исключения бывают из любого правила. ни TDD, ни XP, ни BDD, ни паттерны, ни рефакторинг не помогут, если мозгов нет, это не серебряные пули. Это такие же инструменты, как и компилятор и IDE, которыми нужно уметь пользоваться. К тому же методологии TDD,XP появились позже 2000:)

Методологии TDD применялись, если не ошибаюсь, году эдак в 50 или 60, при разработке чего то космического. К сожалению, не помню чего. Ничто не ново под луной :)

> Последний раз я видел сложную ошибку, когда писал на С++ - там ссылка на переменную из сдохшего стека плавала туда-сюда, между макросов и шаблонов. А в нормальных языках процесс поиска ошибки тривиален.

Тронут чистотой Вашей веры в Нормальные Языки. Падаю ниц.

> Корень ошибки может оказаться раньше чем она начала проявляться.

Найди, от чего она стала проявляться - и дальше тебе понадобятся мозги, а не diff'ы.

>> Корень ошибки может оказаться раньше чем она начала проявляться.

> Найди, от чего она стала проявляться - и дальше тебе понадобятся мозги, а не diff'ы.

А для того, чтобы найти потребуются diff-ы. Ну или тупое вчитывание в каждую строку кода, если diff-ы его превышают по размеру(как в случае с рефакторингом).

Но книжка с описанием методологии только в 2004 где-то. А суть TDD, добавление отрицательной обратной связи в процесс разработки, использовалась инженерами ещё лет 150 назад наверное, если не раньше:)

А какого рода ПО вы разрабатываете?

>> Найди, от чего она стала проявляться - и дальше тебе понадобятся мозги, а не diff'ы.

> А для того, чтобы найти потребуются diff-ы.

Еще раз - changeset, в котором ошибка стала проявляться, находится тупым или не очень тупым двоичным поиском (и обычно - внесена ошибка в этом же changeset'е). А дальше нужно начинать думать, и diff'ы вообще не нужны.

> А какого рода ПО вы разрабатываете?

Быдло-веб-морда для быдло-базы быдло-данных. На жаве и в эклипсе. И все мои матюки на рефакторщиков возникли не из теоретических соображений :)

А vim, tcl и прочие сладкие воспоминания остались от старого проекта, девелопмент в котором завершён.

> обычно - внесена ошибка в этом же changeset'е

да даже и в одном ченджсете: сложно просматривать файл, когда его дифф похож на зебру -- постоянные отметки изменений. А всего-то делов: один человек переименовал функцию в классе, а второй - редактировал этот файл и нажал ctrl-alt-f, переформатировал код и получил кучу изменений в rcs.

:) Если человек разбил себе палец молотком, то кто в этом виноват, молоток или человек?

> :) Если человек разбил себе палец молотком, то кто в этом виноват, молоток или человек?

Если человек при этом собирался закрутить шуруп -- то тот, кто выдал ему для этих целей молоток.

>> обычно - внесена ошибка в этом же changeset'е

> да даже и в одном ченджсете: сложно просматривать файл, когда его дифф похож на зебру -- постоянные отметки изменений.

Ну, если у вас в одном changeset у вас и рефакторинг, и семантические изменения... не делайте так :)

Вопрос в том, что человек просил, когда ему поставили задачу закрутить шуруп.

Если изменение имени одного метода требует изменения сотни файлов, то явно что-то не так со структурой приложения и явно нужен рефакторинг:)

> Вопрос в том, что человек просил, когда ему поставили задачу закрутить шуруп.

Человеки повелись на слова "ынтырпрайз", "ajax" и "orm". В результате полпроекта в NativeQuery.

> Если изменение имени одного метода требует изменения сотни файлов, то явно что-то не так со структурой приложения и явно нужен рефакторинг:)

Хм, а если кто-нибудь захочет переименовать strcpy в StringCopy, сколько файлов поменяется? Неужели почти всем программам на C нужен рефакторинг?

эээ, по вашему рефакторинг - это изменение имени метода? тогда срочно читать фаулера до просветления.

потом на имена функций/методов/классов есть соглашения, которые надо выполнять.

> по вашему рефакторинг - это изменение имени метода?

awk '{print $2,$1}'

> потом на имена функций/методов/классов есть соглашения, которые надо выполнять.

Даже если соглашение мешает нормальному восприятию кода?

Вот почитайте недавно появившееся комьюнити
http://community.livejournal.com/ru_anti_cpp/

>Вот почитайте недавно появившееся комьюнити http://community.livejournal.com/ru_anti_cpp/

почитал. даже подписался на него. но в массе своей там - глубокомысленное упоение собственной смелостью - вот взяли, да закидали грязью язык. а что, почему бы и нет ? приятно ж, блин. и покрасоваться можно - кто чего пообидней ввернёт. вот если бы те, кто туда пишет, к примеру, переписали что-то вроде Qt или ACE на "хороших" языках, да и запостили ссылочку на исходники - вот тогда я бы их мог уважать. в текущем же состоянии сообщество вызывает скорей брезгливость

+1

Последние годы стало модно обсирать плюсы , но пока нет достойной альтернативы да и просто по инерции , люди будут писать именно на них .

+2

+1
вот я и пытаюсь хоть как то защищать C++ там

> ... _инкрементальная компиляция_ всё это так, хрень?

Хрень. Отсутствие реальных знаний и умений прикрывается инструментом.

> Инекрементальная компиляция без ИДЕ не имеет смысла.

Вообще-то без среды исполнения.