Скажите это нормально когда архитектор говорит что его не интересует чистота кода и что начальник отдела с ним соглашается и так же говорит (сам начальник) что при разработке не следует занимать рефакторингом а заниматься им только при получении уже результата т.е. контретной версии продукта?
Я с ним с обоими сильно спорю, но доказать нечего не могу. Просто меня вообще не слушают.
При создании большой системы архитектор 4 часа порисовал различных табличек на доске и через 2 недели составил в Visio визуальные формы как он их хочет видеть. Скажите какое участие в разработке новой болшой системы должен принемать архитектор? Может всетаки я неправ.
Буду очень благодерен если вы опишете как у вас обстоят дела с подобными вещами.
Здравствуйте, Disa, Вы писали:
D>Скажите это нормально когда архитектор говорит что его не интересует чистота кода и что начальник отдела с ним соглашается и так же говорит (сам начальник) что при разработке не следует занимать рефакторингом а заниматься им только при получении уже результата т.е. контретной версии продукта? D>Я с ним с обоими сильно спорю, но доказать нечего не могу. Просто меня вообще не слушают.
Не видя твоего кода нельзя сказать нужен ли ему рефакторинг. И что вы там результатом считаете — вопрос. Но вообще это хорошая практика — сначала отладить код, а затем отладить рефакторинг вместо того, чтобы отлаживать сразу 2 вещи.
D>При создании большой системы архитектор 4 часа порисовал различных табличек на доске и через 2 недели составил в Visio визуальные формы как он их хочет видеть. Скажите какое участие в разработке новой болшой системы должен принемать архитектор? Может всетаки я неправ.
Ну какой то более-менее детальный спек как все делать он все таки должен выдать за 2 недели то. Визио тут ни разу не помощник. Хотя, чего у тебя за продукт? Вдруг там уже все мясо заделано, осталось сделать супер-гуй.
В программировании, как и везде, всё зависит от ситуации. Допустим, программист пишет какую-нибудь библиотеку, требования на которую ещё не уточнены. Более, того, эти требования нельзя уточнить, условно говоря, нужно сначала получить хоть что-то, поиграться с этим и только потом их можно будет сформулировать в окончательном виде. При этом, скорее всего, эти требования потребуют значительной переделки всей библиотеки. Как ты думаешь, следует ли программисту тщательно тестировать библиотеку, рефакторить, расставлять комментарии? Может быть, будет эффективнее что-то очень быстро слабать, но именно с целью получить как можно быстрее хоть какой-нибудь feedback?
Что касается роли архитектора, то очень много зависит от квалификации команды. Я видел достаточно команд, где архитектора не было в принципе, что не мешало выпускать качественные продукты в срок.
Здравствуйте, Disa, Вы писали:
D>Скажите это нормально когда архитектор говорит что его не интересует чистота кода и что начальник отдела с ним соглашается и так же говорит (сам начальник) что при разработке не следует занимать рефакторингом а заниматься им только при получении уже результата т.е. контретной версии продукта? D>Я с ним с обоими сильно спорю, но доказать нечего не могу. Просто меня вообще не слушают.
D>При создании большой системы архитектор 4 часа порисовал различных табличек на доске и через 2 недели составил в Visio визуальные формы как он их хочет видеть. Скажите какое участие в разработке новой болшой системы должен принемать архитектор? Может всетаки я неправ.
D>Буду очень благодерен если вы опишете как у вас обстоят дела с подобными вещами.
Быть может
1) Величина сроков, данных на проект, не позволяет заниматься рефакторингом
2) Архитектор не уверен, что вы сможете качественно/без задержек рефакторить код
3) Чтобы осуждать человека, надо сначала побывать в его шкуре.
Здравствуйте, Advertiser, Вы писали:
A>1) Величина сроков, данных на проект, не позволяет заниматься рефакторингом
Я слишком беден, чтобы покупать дешевые вещи.
Нормальность зависит от контекста, скорее всего Ваш архитектор вместе с начальником готовят макет системы. На этом этапе их можно понять, так как макет нужен для того, чтобы его использовать при уточнении требований. Кроме этого рефакторинг -- это изменение содержания без изменения функционала, что подразумевает наличие "неотрефактореного" кода. Возмножно для того, чтобы Вы не чувствовали себя демотивированным, вам необходимо выяснить цели проекта.
ПС
Если фразы такого рода носят постоянный характер, то сие клиника.
Здравствуйте, De-Bill, Вы писали:
DB>Что касается роли архитектора, то очень много зависит от квалификации команды. Я видел достаточно команд, где архитектора не было в принципе, что не мешало выпускать качественные продукты в срок.
Забавно, у нас почти три года не было архитектора. А как раз перед тем, как проект закрылся, назначили архитектором одного товарища... из совершенно другого проекта.
Здравствуйте, Disa, Вы писали:
D>Скажите это нормально когда архитектор говорит что его не интересует чистота кода и что начальник отдела с ним соглашается и так же говорит (сам начальник) что при разработке не следует занимать рефакторингом а заниматься им только при получении уже результата т.е. контретной версии продукта? D>Я с ним с обоими сильно спорю, но доказать нечего не могу. Просто меня вообще не слушают.
И правильно делают
D>При создании большой системы архитектор 4 часа порисовал различных табличек на доске и через 2 недели составил в Visio визуальные формы как он их хочет видеть. Скажите какое участие в разработке новой болшой системы должен принемать архитектор? Может всетаки я неправ.
Он может быть и архитектор, но занимается вопросами бизнес-анализа. Все эти форточки — это то, как пользователь хочет видеть систему. После этого на первых порах никого не е..., что же за красивыми картинками. Спорить о красоте кода за неготовым UI — это проявление жёсткого нубства. Вот когда всё утряслось, тогда уже можно порефакторить и приготовить приложение к последующей поддержке.
К тому же, ты как профессионал должен дожить до первого релиза, после которого тебе скорее всего дадут время на рефакторинг. Но если у тебя код расползается, когда и беты на горизонте нет, то лучше поискать причину в кривизне своих ручек, а не валить всё на архитектора.
Здравствуйте, Disa, Вы писали:
D>Скажите это нормально когда архитектор говорит что его не интересует чистота кода и что начальник отдела с ним соглашается и так же говорит (сам начальник) что при разработке не следует занимать рефакторингом а заниматься им только при получении уже результата т.е. контретной версии продукта? D>Я с ним с обоими сильно спорю, но доказать нечего не могу. Просто меня вообще не слушают.
Рефакторинг это вообще твои проблемы — не получается сразу писать хорошо, приходится затем рефакторить. Я, например, постоянно рефакторю, это, по-моему, составляющая кодирования. И не надо вообще говорить о рефакторинге начальству.
D>При создании большой системы архитектор 4 часа порисовал различных табличек на доске и через 2 недели составил в Visio визуальные формы как он их хочет видеть. Скажите какое участие в разработке новой болшой системы должен принемать архитектор? Может всетаки я неправ.
А что плохого, что он формочки нарисовал? По-моему это хорошо, когда их кто-то рисует, тебе же легче потом их программить
Здравствуйте, captainPower, Вы писали:
P>Здравствуйте, Disa, Вы писали:
D>>Скажите это нормально когда архитектор говорит что его не интересует чистота кода и что начальник отдела с ним соглашается и так же говорит (сам начальник) что при разработке не следует занимать рефакторингом а заниматься им только при получении уже результата т.е. контретной версии продукта? D>>Я с ним с обоими сильно спорю, но доказать нечего не могу. Просто меня вообще не слушают.
И вообще хорошо когда есть еще один крайний на пути к тебе. Но конечно плохо, если этот крайний в случае чего может сделать крайним тебя и от него толку никакого, а только мешается Но зато смотри — все вопросы по соответствию гую требованиям заказчика будет решать он, чем плохо?
Здравствуйте, Mishka, Вы писали:
M>…дожить до первого релиза, после которого тебе скорее всего дадут время на рефакторинг.
К тому времени скапливается столько фич-реквестов, которые боятся вносить в вот-вот готовый релиз, что и не до рефакторинга. Ведь некоторым удобнее поскорее "лечь" под заказчика и удовлетворить его "как-нибудь" по-быстрому в ближайшее время, чем качественно, но позже
Истина, ИМХО, в том, чтоб в коспромисах решать, что надо сделать сразу и с претензиями, а что можно "наклепать" для "потом".
... << RSDN@Home 1.2.0 alpha rev. 652>>
Now playing: «Тихо в лесу…»
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, Mishka, Вы писали:
M>>…дожить до первого релиза, после которого тебе скорее всего дадут время на рефакторинг.
_FR>К тому времени скапливается столько фич-реквестов, которые боятся вносить в вот-вот готовый релиз, что и не до рефакторинга. Ведь некоторым удобнее поскорее "лечь" под заказчика и удовлетворить его "как-нибудь" по-быстрому в ближайшее время, чем качественно, но позже _FR>Истина, ИМХО, в том, чтоб в коспромисах решать, что надо сделать сразу и с претензиями, а что можно "наклепать" для "потом".
Дожить до первого релиза — это не баран чихнул. Потом менеджер сам решит, когда нужно рефакторить (обычно, когда всё падает и малейший шаг влево-вправо вызывает вопли подчинённых). Не программерское это дело решать, когда пора тратить время на изменение кода, ничего не дающего пользователю. Хороший программер сводит количество таких кусков кода к минимуму, хотя их со временем накапливается не мало, и потом, ни чего не объясняя, потихоньку рефакторит. В конце концов, деньги программеру платят за продукт, а не за красивый код. Потому увольняют не за некрасивый код, а за неготовый продукт
Заниматься рефакторингом надо в свободное от работы время. Если больше заняться нечем.... (читаем любую книжку по теме имеющую отношение к реальности).
Здравствуйте, kograt, Вы писали:
K>Заниматься рефакторингом надо в свободное от работы время. Если больше заняться нечем.... (читаем любую книжку по теме имеющую отношение к реальности).
В определении понятия рефакторинг говорится что им нужно заниматься постоянно, а не в свободное время. Поэтому я с вами не согласен.
Здравствуйте, captainPower, Вы писали:
P>Здравствуйте, Disa, Вы писали:
P>Рефакторинг это вообще твои проблемы — не получается сразу писать хорошо, приходится затем рефакторить. Я, например, постоянно рефакторю, это, по-моему, составляющая кодирования. И не надо вообще говорить о рефакторинге начальству.
Здравствуйте, Disa, Вы писали:
D>В определении понятия рефакторинг говорится что им нужно заниматься постоянно, а не в свободное время. Поэтому я с вами не согласен.
Ну да... Пока ты будешь заниматься рефакторингом... А работу за тебя кто делать будет? Совершенно справедливое поведение начальства — ты сначала хоть что-то работающее выдай, а уж потом будем улучшать. И правильно тебе тут сказали: тебе деньги платят за наличие продукта, а не красивость написания его исходников.
Здравствуйте, kograt, Вы писали:
K>Заниматься рефакторингом надо в свободное от работы время. Если больше заняться нечем.... (читаем любую книжку по теме имеющую отношение к реальности).
Можете назвать конкретные книжки, которые по теме и близки к реальности? Мне кажется, что таковых не много.
Здравствуйте, kograt, Вы писали:
K>Заниматься рефакторингом надо в свободное от работы время. Если больше заняться нечем.... (читаем любую книжку по теме имеющую отношение к реальности).
А во время работы бороться с граблями, которые же сам и пораскидывал без рефакторинга
Здравствуйте, Horror_Infinity, Вы писали:
H_I>Здравствуйте, Disa, Вы писали:
D>>В определении понятия рефакторинг говорится что им нужно заниматься постоянно, а не в свободное время. Поэтому я с вами не согласен.
H_I>Ну да... Пока ты будешь заниматься рефакторингом... А работу за тебя кто делать будет? Совершенно справедливое поведение начальства — ты сначала хоть что-то работающее выдай, а уж потом будем улучшать. И правильно тебе тут сказали: тебе деньги платят за наличие продукта, а не красивость написания его исходников.
Неоднократно попадплся на фигню: чувствую, что нужно отрефакторить, ибо потом, если придется изменять что-то в этой области кода, то будет тяжело, но времени нет. Потом и правда приходится менять, а времени еще меньше, заказчику крайне срочно до релиза понадобилась некая фенечка, и он за нее уже доплатил... И начинаешь рвать на голове волосы, потому что тогда, когда ты этим занимался, все было в голове, а сейчас нужно все вспомнить, и как бы не пропустить чего-нибудь...
Сейчас стараюсь убирать косяки по мере их появления.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Но зато смотри — все вопросы по соответствию гую требованиям заказчика будет решать он, чем плохо?
