Eclipse 3.0

Спасибо всем за объяснение...

А Agility и XP - это теперь синонимы горнего и божественного ?

Я понимаю, для оффшоров XP рулит. Но я не знаю ни одной продуктовой компании, где это бы работало.

ARia

> Если клиент толще 85 мегов в архиве то это толстый клиент, иначе тонкий.

Это считая JRE или нет? ;)

>Это, на мой взгляд, минус организации разработки, но это уже совсем
>другой разговор.
Сторонникам руп можно посоветовать смело идти разрабатывать абстрактные системы для сферических заказчиков, работающих в вакууме. Такой рассклад как:
- заказали систему на 40 часов (соотв. требования).
- Система заработала, начала приносить хорошую прибыль.
- Стали заказывать каждый месяц по 160 часов нового функционала... по мере надобности, по мере востребованности.
- постепенно к системе появляются новые требования, которые в начальных 40 часах ну никак не умещаются - где здесь минус организации? разработки? Заказчик доволен. Сложность системы повышается (грубо говоря в первый месяц в 8 раз, дальше в процентах).
- качество кода не снижается, а повыщается.

>Действительно, какая связь между повышением продуктивности и
>ответвенностью?
Ответственностью разработчика? Ответственностью ProjM/ProdM? Ответственностью заказчика? Чьей ответственностью?

>Я понимаю, для оффшоров XP рулит.
Дыкть.

>Но я не знаю ни одной продуктовой
>компании, где это бы работало.
Гм. О том и речь. :).

>Такой рассклад как:

Если это у вас работает - на здоровье.

> Ответственностью разработчика? Ответственностью ProjM/ProdM? > Ответственностью заказчика? Чьей ответственностью? Разработчика. Когда я писал про "...2 минуты..." я писал о том, что рефакторинг повышает продуктивность работы разработчика. И не снимает ответственности.

> Есть кряк для триальной версии

Бл... А как же глубокое убеждение о превосходстве свободного софта перед плантым????

Ошибки проектирования говорите.
Разверну пример про 40+160+160+... которые приводили.

Спроектировали супер-пупер ядро/движок сисnемы, сделали доббержку абстрактной фичи от которой все наследуеться, сделали n-фичей.
Потом не меняем движок и добавляем еще одну фичу, и видим, что ее часть сильно перекликаеться с фичей m-которую мы уже сделаи раньше и когда ее делали, бизнес-среда не предполагала наличия новой.
Возникает необходимость сделать промежуточную абстрактуную фичу, большая часть кода котрой будет взята из фичи m. То есть нужно подвигать метолді вверз, уже пошел рефакторинг.

Не стоит тратить силы на убеждения. Всё равно товарищи утверждающие, что писали нечто большее "Hello Basic" и не нуждающиеся в переработке своего кода лукавят, непонятно только перед кем, и будут продолжать убеждать всех в ненужности рефакторинга. И на XP не стоило разговор переводить, а то может сложиться ложное впечатление, что рефкторинга без XP не существует. Тут некоторые говорили "Значит система плохо спроектирована", что позволяет думать что существую изначально хорошо спроектированные системы, расширение которых является относительно простой задачей? (Ну, если не брать в расчёт действительно простые задачи) Или возьмётесь утверждать, что переделывать существующие задачи, это неправильно и надо заново с нуля всё начинать писать или в расширении никогда необходимости не возникает?

2Svyatogor: спорим, если ты код привидёшь любого проекта объёмами хотя бы в несколько сотен строк тобою написанных, всегда можно будет сказать, где можно было бы получше написать?

2 eRazor: Хотел ответить, потом прочитал... и подумал что нафиг не надо ;-). Когда-нибудь эти товарищи все сами поймут ;-).

Более того... скоро программы буду целиком исаться без участия программистов...

BTW, то, что заказчик меняет требования раз в неделю, обычно обусловлено не коренной сменой его бизнеса (так часто бизнес не меняется), а тем, что заказчик - мудак, и сам толком не знает, чего хочет. Плавали, знаем.

>BTW, то, что заказчик меняет требования раз в неделю, обычно обусловлено не коренной сменой его бизнеса (так часто бизнес не меняется), а тем, что заказчик - мудак, и сам толком не знает, чего хочет. Плавали, знаем.

То что в Украине сначала ввели спец. счета для НДС, а потом их отменили, это тоже заказчики мудаки? Или то что перечень сертифицированых налоговой фискальных регистраторов меняеться, причем не только на добавление, а новые работают существенно по-другому, тоже виноват заказчик?

Вообще-то вышел Eclipse 3.0RC3. Релиза еще нету. Зачем шум поднимать.

Извините за задержку. Поясняю:

Ошибка есть решение, приводящее потом к необходимости править большие куски кода. Вы согласны с таким определением?

Копирование кода - ошибка разработчика. Неугадывание по _кривому_ ТЗ _правильной_ архитектуры под _будущие_ желания клиента - ошибка разработчика (вызваная, обычно, независящими от него причинами - но кого это волнует).

Разработчик отвечает своим временем/деньгами и настроением за допущеные "ошибки" (-:точнее за необходимость их исправлять:-).

2 DonkeyHot
Очень часто так и оказываеться. Но как мне кажеться именно из-за того, что пытаються "угадать" арихитектуру сразу, а не вырастить ее, путем рефакторинга при появление малейшей проблемы. А потом когда уже написанно очень много кода, то сильно и не порефакторишь.

Извините, что не по теме. Изучаю jsp/servlet/sql.
В умной книге говорят нужно создать класс People и методы
getFam(), setFam() и ...
Когда я выбираю select * from people where people.id = id
Нужен метод, который сразу записывает все в переменные
People.fam, People.im или вызывать People.setFam(),People.setIm() ?

select * from people - выбор всех
Дальше копировать в массив классов People?
Напрягает возникающая прослойка между SQL и классами, дублирующими
таблицы базы и отображением в html.

Берем Tapestry или Struts (получаем web framework)

Берем OJB или hibernate (получаем Persistence mapping между DB и обьектами)

А можно ссыклу на книжку Фаулера на русском, если есть

http://w8.platonoff.com/refactoring/ - Мартина Фулера "Refactoring"

http://www.xprogramming.ru - Много всего связанного с XP и agile технологиями на русском

2DonkeyHot
Хочется матом, но пока сдержусь :-)

Вы сами-то писали что-то такое, о чем рассуждаете? Не приходилось иметь
геморроя из-за _переоценки_ будущих желаний клиента, нет? Приходилось
работать в команде и копаться в чужом коде? И как, понравилось?

Вы знаете, что существует такие люди, как архитекторы проекта, чьей
задачей и является построение архитектуры программы? А знаете ли вы, что
существует такое понятие, как сроки и что их устанавливают отнюдь не
сами разработчики, а начальство (в крайнем случае согласовывая с
менеджером проекта)? А ведь еще есть такая замечательная штука как
человеческий фактор. Сдается мне, что не знаете вы, о чем говорите...

ЗЫ: Правка больших кусков кода - это ошибки в архитектуре.
А вот для того, чтобы отражать изменения в т.з., терминологии предметной
области и пр. зачастую требуется множество маленьких изменений по всему
проекту, где и помогает рефакторинг. И не вздумайте говорить, что это
плохо - в противном случае эти несоответствия будут очень долго копиться
и в конце-концов это приведет к полной каше как в коде, так и в головах
разработчиков.

> обычно обусловлено не коренной сменой его бизнеса (так часто бизнес не меняется), а тем, что заказчик - мудак, и сам толком не знает, чего хочет

Если ключевое слово - "обычно", то вынужден согласиться. Только вот... кто платит, тот и танцует. И никуда ты не денешься =(

> Вообще-то вышел Eclipse 3.0RC3. Релиза еще нету. Зачем шум поднимать.

Вообще-то, RC3 вышел пару дней тому назад. А на сайте объявили именно что final-версию... просто ее не выкладывают пока =)

И правильно.

>Сдается мне, что не знаете вы, о чем говорите

Сдается мне, что вы невнимательно читали то, что я писал. Там нет ни одного неверного утверждения.

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

Очевидно, что утверждение "рефакторинг помогает" эквивалентно "несовместимые с архитектурой изменения ТЗ помогают". Докажите. Или формулируйте свои мысли правильнее.

если "объявили" означает "анонсировали", то согласен. Но это не означает, что он (Eclipse) "вышел".

Здесь я не специалист, с бухгалтерией близко пока сталкиваться не приходилось (к счастью). Но что-то мне подсказывает, что наличие количество спец. счетов должно нстраиваться в программе... И всё подобное тоже...

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

Я же говорил про "А нельзя ли вместо 20ти этажного дома построить посёлок из коттеджей, соединённых подземными туннелями?". Сам сталкивался, и неоднократно :(

Кто там говорил, что начальство всё решает? Что же за начальство такое, что ему пофигу - что двадцатиэтажный дом, что коттеджи рабочие делать будут? Которому абсолютно неинтересны реальные возможности рабочих? Может, место работы сменить стоит?

DonkeyHot

>> Ошибка есть решение, приводящее потом к необходимости править
большие куски кода. Вы согласны с таким определением?

Очень расплывчатое определение. Сферическое решение в программном
вакууме. Кто принимал решение, приведшее к этой ситуации? Достаточно
ли было информации для того, чтобы этого избежать? Если нет - кто
виноват, что эта информация отсутствовала? Что-то слишком огульно вы
на разработчиков все вешаете. Вы не менеджер, случаем?


>> Копирование кода - ошибка разработчика.
Согласен. Впрочем, с оговоркой про сроки.

>> Неугадывание по _кривому_ ТЗ _правильной_ архитектуры под _будущие_ желания клиента - ошибка разработчика (вызваная, обычно, независящими от него причинами - но кого это волнует).

Не, ну точно - менеджер :-)) Не согласен категорически (особенно с пометкой в скобках)

>> Разработчик отвечает своим временем/деньгами и настроением за
>> допущеные "ошибки" (-:точнее за необходимость их исправлять:-).

Либо же посылает работодателя куда подальше и ищет контору с более нормальными начальниками. А бывший пускай сам в таких условиях пишет.

>> Очевидно, что утверждение "рефакторинг помогает" эквивалентно
>> "несовместимые с архитектурой изменения ТЗ помогают". Докажите. Или
>> формулируйте свои мысли правильнее.

Это где вы такое углядели??? 8-) Давайте попробуем еще раз:

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

Так лучше?

>> Кто там говорил, что начальство всё решает? Что же за начальство
>> такое, что ему пофигу - что двадцатиэтажный дом, что коттеджи рабочие
>> делать будут? Которому абсолютно неинтересны реальные возможности
>> рабочих? Может, место работы сменить стоит?

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

>Кто принимал решение? Достаточно ли было информации? кто виноват, что эта информация отсутствовала?

Не пытайтесь искать виноватых. Это не имеет _никакого_ отношения к процессу разработки ПО. Расплачивается за это разработчик - значит он и виноват - перед собой в основном.

>Что-то слишком огульно вы на разработчиков все вешаете. Вы не менеджер, случаем?

Нет. Я ?перфекционист? (в смысле люблю совершенство). И считаю, что если приходится двигать куски кода - допущена ошибка на этапе проектирования. _Я_ виноват.

>Либо же посылает работодателя куда подальше и ищет контору с более нормальными начальниками

Это тоже приводит к потере времени, денег и настроения. Я опять прав:-)

>Так лучше?

Не достаточно. Правильно: "В чем, собственно, и помогает то, что называется 'поддержка рефакторинга'". Сам рефакторинг - зло, необходимое во избежание бОльшего зла, вызваного несоответствием принятых решений и ТЗ. Это как прием антибиотиков (или ампутация) - вредно, но иногда необходимо.

Собственно причина спора в том, что некоторые верят в то, что оптимальную архитектуру _можно_ найти сразу, при неполных данных, а некоторые - _нет_. Я не знаю метода доказать первое, но верю в это - несмотря на то, что сам _пока_ не достиг необходимого для этого уровня. Но мне есть к чему стремиться:-)

Прошу прощения за опечатки - клавиатура "разломаная", не привык пока.

2 DonkeyHot:
Можно услышать сколько лет вы занимаетесь програмированием профессионально (если не секрет можно пару проектов)?

>сколько лет вы занимаетесь програмированием профессионально

Мало. Последние 10 я занимаюсь им "любительски":-). Это что-то меняет в данном контексте?

Ну, ну. В течении десяти лет верить в существовануе правильной архитектуры изначально при неполных начальных данных, Уважаемый, Вы лжёте.

Закачал RC3 попробовал, ничё штучка но до Idea не дотягивает. Но как бесплатная альтернатива вполне годится. Вообщем работать можно.

>Есть кряк для триальной версии сликедита 9 под линукс 4049420

Кинь пожалуйста на kiv_guard@sura.ru. Век буду благодарен:)

>2 kiv: >Бесконечную триальную лицензию с окошком, сообщающим о необходимости >купить слик могу дать. вск на это дело похоронил ;-).

Кинь пожалуйсто на kiv_guard@sura.ru. Я тоже както 8-ку пытался обломать :( Не нашел где у них там грабли зарыты.

>Бл... А как же глубокое убеждение о превосходстве свободного софта перед плантым????

Не стал бы так, не стал бы :) Категориями судить это неправильно :)

:-0 Где? Ткните, пожалуйста, чьим либо носом:-)

Вы можете _доказать_ что это невозможно? Скорее всего нет - эмпирическое "я такого не видел" не означает, что это невозможно. Т.о. вы точно так же _верите_ в "невозможность". Мы не лжем друг другу - некоторые из нас лгут сами себе.

Обьективно одно: _правильно_ спроектировать сразу лучше, чем менять архитектуру на ходу, что в свою очередь лучше, чем не менять ее, если она не соответствует задаче.

А причины нечастой реализации первого сценария - offtopic.

>Последние 10 я занимаюсь им "любительски":-). Это что-то меняет в
>данном контексте?
Значит вы не знакомы со словом deadline. Этим все и объясняется.

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

>обычно обусловлено не коренной сменой его бизнеса (так часто бизнес не
>меняется), а тем, что заказчик - мудак, и сам толком не знает, чего
>хочет
Он конечно не знает чего хочет... но это человек, благодаря которому ты востребован. Не будет его - пойдешь улицы подметать. ;-). У всех свои заморочки. У програмистов одни. У заказчика другие. Мудак - это тот, кто старается свои проблемы повешать на другого (заказчик заставляющий разаработчика разбираться в тонкостях своего бизнеса, разработчик - нагружающий заказчика тех. деталями)... но хуже всего ситуация, когда манагер - мудак :-). обычно же мудаков не так уж и много... и все ищут компромис ;-).

На самом деле по поводу проектирования и ошибках в нём полная чушь. Конечно если вы пользуетесь каскадной моделью разработки это наверное справедливо. Но такая модель подходит далекоооо не ко всем задачам. Да и вообще жутко не поворотлива и требует очень серьёзных административных мер. Да и не популярна эта модель сейчас, гораздо больший эфект даёт применение либо возвратного либо спирального метода, где рефакторинг вполне уместен и даже полезен, я уже молчу про ХР. И внимание! Никто ещё не доказал превосходство одного метода над другим, просто они применимы в разных ситуациях.

Где именно? Пожалуйста, объясняю. На вопрос сколько времени вы занимаетесь профессиональным программированием, Вы отвечаете небрежно (слово "мало" и 10 лет), что последние десять лет у Вас это было любительски. Т.е. Вы занимаетесь им значительно больше, а последние 10 лет это было что-то типа развлечения. Сильно настораживает категоричность утверждения ненужности рефакторинга. Т.е. Вы настолько мастерски пишите, что не нуждаетесь в переработке своего кода, да ещё и распространяете это на других. НЕ ВЕРЮ! Человек в отличии от компьютера всегда допускает ошибки. Вы заявили, что верите в существование хорошей архитектуры, но при этом, упомянули, что сами с такой не сталкивались. Какой вывод прикажите делать? Либо странное расхождение слов с действительностью, либо элементарная ложь. Даже в том невероятном случае если Вы сами проектируете абсолютно без ошибок и угадываете на X лет вперёд какие будут возможные изменения, при этом программист кодирует один раз и забывает о коде, т.к. ваша замечательно продуманная архитектура при возникших изменениях спасает от какой-либо переделки кода вообще, распространять это на других, говоря рефакторинг ненужен -- это смешно. В этом случае долгие годы работы и спотыкание на своих ошибках, должно было понимание принести того, что хорошая, удачная архитектура с МИНИМУМОМ переделок впоследствии, это умение доступное немногим, и даже в этом случае рефакторинг используется! Мне очень не нравится переход, на личности, прошу меня извинить, но я пришёл к выводу, что цыфра в 10 лет преувеличена, странная вера в то чего нет и категоричность утверждений свойствены вполне определённому возрасту, а именно лeт до двадцати с чем-то. В этом случае с цыфрой 10 что-то не то.

> последние 10 лет это было что-то типа развлечения.
просто посмотрим 2004 - 10 лет получаем 1994 итого человек если и занимался профессиональным програмированием, то до 1994 года, а это значит либо DOS, либо разработки для науки. То есть с программированием коммерческого софта хорошей степени сложности сталкиваться ему не приходилось. Хотя у меня есть подозрение, что до 1994 года человек вообще не имел отношения к разработке софта :-). Отсюда и максимализм и непонимание сути проблемы меняющихся требований.

>Мало. Последние 10 я занимаюсь им "любительски":-). Это что-то меняет в данном контексте?

10 IMHO уже не мало :) Конечно меняет:) Если вы занимались им "любительски" - значит серьезных проектов не вели и не исполняли. А если не вели серьезных проектов и имеете "любительские" навыки, зачем тогда высказывать свое "любительское мнение" :)

>Сильно настораживает категоричность утверждения ненужности рефакторинга. Т.е. Вы настолько мастерски пишите...

:-0 И где же Вы это прочли? Я писал точно противоположное. Уж очень странно был я Вами понят:-)

>странная вера в то чего нет

Не в то, чего нет, а в то, чего мы еще не видели. Если вы это видели - это уже _факт_, в него нельзя _верить_ :-)

>категоричность утверждений свойствены вполне определённому возрасту

Увы, я старше раза в полтора:-( Категоричные слова мои верны. И Вы не попытались _их_ оспорить.

Давайте не будем судить о мнении по личности человека, его высказывающего:-).

Я в начале намекнул на то, что необходимость "поддержки рефакторинга" в редакторах кода вызвана большим процентом принимаемых при проектировании решений, не соответствующих решаемой задаче. Вы видите какое-либо противоречие в этом утверждении? Я - нет. Тем не менее почему-то это вызвало обсуждение моей непримечательной личности. Почему бы это? Психоаналитик нужен. Подозреваю, что некоторых товарищей уже достал этот $%^$%^ рефакторинг, $%^$%^ иерархические классы с $%^$%^ обьектами, заказчики с дедлайнами, ну, или может быть еще что-то. Но они еще этого не поняли.

Хотя психоаналитик из меня еще хуже, чем программист:-).

Гм :-). О правильности решений.
http://www.phppatterns.com/index.php/article/articleview/103/1/1/
Hello World на php с использованием шаблонов проектирования ;-).

>> Не достаточно. Правильно: "В чем, собственно, и помогает то, что
>> называется 'поддержка рефакторинга'".

Значит, вы меня все же поняли? Вот и ладушки... А то я уже в себе сомневаться начал :-)

>> Сам рефакторинг - зло,
>> необходимое во избежание бОльшего зла, вызваного несоответствием
>> принятых решений и ТЗ. Это как прием антибиотиков (или ампутация) -
>> вредно, но иногда необходимо.

Экая трава у вас вкусная... Зло - это нечто, от чего кому-то или
чему-то потом становится плохо. Кому плохо от рефакторинга?

>> Собственно причина спора в том, что некоторые верят в то, что
>> оптимальную архитектуру _можно_ найти сразу, при неполных данных, а
>> некоторые - _нет_. Я не знаю метода доказать первое, но верю в это
>> - несмотря на то, что сам _пока_ не достиг необходимого для этого
>> уровня. Но мне есть к чему стремиться:-)

Да. Можно. Также можно найти решение теоремы Ферма, ничего не понимая
в математике, или с первого раза получить собрание сочинений Шекспира
от десятка обезьян, посаженных за компьютер. Удачи вам в вашем нелегком труде.

>> [Вера] Не в то, чего нет, а в то, чего мы еще не видели. Если вы
>> это видели - это уже _факт_, в него нельзя _верить_ :-)

Скажите мне, пожалуйста, вот что. Как вы поступаете с теми проектами,
которые перестали удовлетворять вашим требованиям к архитектуре?

>> Тем не менее почему-то это вызвало обсуждение моей непримечательной
>> личности

"Обсуждение вашей непримечательной личности" вызвано не констатацией
факта выше, а необоснованным утверждением, что "рефакторинг - это зло",
и столь же необоснованными наездами на разработчиков.

Тому, кому приходится его делать. Вспомните себя _перед_ прочтением прошлого обновления ТЗ, приведшего к рефакторингу. У Вас есть красиво спроектированая система, большинство кода уже написано и отлажено. И вроде-бы дедлайн еще неблизко. Можно сходить на пляж|пиво|whatewer. И тут нате...

Это ли не зло?

>Значит, вы меня все же поняли

Я то сразу понял. Просто от того, как оно было сказано вначале веяло заучеными рекламными слоганами...

>Как вы поступаете с теми проектами, которые перестали удовлетворять вашим требованиям к архитектуре

"Рефакторю". И немножко матерюсь про себя:-)

--- cut --- Правильно: "В чем, собственно, и помогает то, что называется 'поддержка рефакторинга'". Сам рефакторинг - зло, необходимое во избежание бОльшего зла, вызваного несоответствием принятых решений и ТЗ. Это как прием антибиотиков (или ампутация) - вредно, но иногда необходимо. --- cut ---

>>Сильно настораживает категоричность утверждения ненужности рефакторинга.

>:-0 И где же Вы это прочли? Я писал точно противоположное. Уж очень странно был я Вами понят:-)

Признаю -- невнимательно прочитал. Прошу извинить.

>странная вера в то чего нет

Не в то, чего нет, а в то, чего мы еще не видели. Если вы это видели - это уже _факт_, в него нельзя _верить_ :-)

Давайте признаем аксиому -- изначально идеальной архитектуры не бывает. Бывает набор компромисов, позволяющий добится минимума изменений. Я не согласен с тем, что рефакторинг это зло. Так же я не согласен с рассмотрением рефакторинга только в плоскости архитектуры. Да элементарная вещь -- изменение имени метода, суть рефакторинг. А если среда разработки позволяет сделать это легко, это однозначно хорошо.

>> Тому, кому приходится его делать. Вспомните себя _перед_ прочтением
>> прошлого обновления ТЗ, приведшего к рефакторингу. У Вас есть красиво
>> спроектированая система, большинство кода уже написано и отлажено. И
>> вроде-бы дедлайн еще неблизко. Можно сходить на пляж|пиво|whatewer. И
>> тут нате...
>> Это ли не зло?

Это не зло :-) Это-то, как раз, нормальная и ожидаемая ситуация, к
которой я готов целиком и полностью :-) Поэтому я и не нервничаю
, а просто сажусь и делаю за 5 минут с помощью рефакторинга то, что без
него я сделал бы дня за 2. В сэкономленное время иду на пляж / пиво /
whatever. Красота? А при наличии грамотного менеджера проекта, еще и
сроки отодвигаются + денюжки за это платятся. Все довольны, всем хорошо.

>> "Рефакторю". И немножко матерюсь про себя:-)

Так у кого из нас с настроением плохо? :-)