Здравствуйте, SkyDance, Вы писали:

SD>Не совсем. Я бы даже сказал, совсем не. Разработка софта больше похожа на серию стометровок. Победа в каждом очередном забеге серии (суть релиз очередной версии) дает бонусы и шанс участвовать в следующем забеге. Проиграв очередной забег, из соревнования вы чаще всего выбываете. До поддержки и развития проекта дело может банально не дойти, если вы проиграете первую же стометровку.

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

SD>На каком-то этапе вы можете дать отдых натруженным мышцам (суть сделать рефаторинг "на будущее") — но если это приведет к поражению на этом этапе, вы можете вылететь из соревнования насовсем.

SD>Ого! Впервые встречаю такую юзабилити, которую просто придумали — и бац, она уже есть, и программистам не надо "кодировать формочки" На моей памяти, именно юзабилистские заморочки (особенно на вебе) выносили мозги программистам А вовсе не супер-пупер алгоритмы, для знания которых нужно аж целый день вчитываться в алголист.мануал.ру

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

Здравствуйте, Aviator, Вы писали:

A>Здравствуйте, Fasa, Вы писали:

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

Автор: alexsoff
Дата: 13.11.11

, есть подозрение, что это не так.
Ну если это не так, то у человека есть реальная возможность узнать кто он на самом деле.

Здравствуйте, alexsoff, Вы писали:

A>Здравствуйте, Kerk, Вы писали:

K>>У меня сложилось впечатление (возможно ошибочное), что бы создали эту тему, чтобы услышать: "Да, да, молодец, мы думаем точно так же". И очень удивлены существованием альтернативных точек зрения.
A>Я создал эту тему, чтобы услышать, что у кого-то был опыт (успешный или не успешный) в переписывании проектов с нуля, а не о том, что у меня низкая квалификация и я вообще должен провалить проект.

Ну так люди и делятся своим опытом. Который говорит, что желание все переписать очень часто говорит о низкой квалификации. Я бы не стал в этом видеть личные нападки.

Здравствуйте, Kerk, Вы писали:
K>Ну так люди и делятся своим опытом. Который говорит, что желание все переписать очень часто говорит о низкой квалификации. Я бы не стал в этом видеть личные нападки.
желание все переписать возникает из-за несоответствия своим правильным понятиям о том, как надо писать с тем, что есть. возникает оно обычно из-за того, что человеку только что обьяснили единственно верный способ разработки. или же он книжку прочитал о таком способе разработки. опытные же люди к заявлениям об единственной правильности относятся скептически, они видели в работе код разной степени гавенности, видели разные подходы в разработке и понимают, что возможно для данного проекта ничего страшного с кодом не происходит. было и похуже
с интересном для себя заметил, что люди с опытом начинают не только писать "более правильный код", но при этом часто могут написать очень что-то опасное и неправильное и у них все равно все прекрасно работает, так как писали подобное 100 раз и знают все его косяки. поэтому они часто даже не парятся с тем, чтобы писать все по ГОСТу.

Здравствуйте, Aviator, Вы писали:

A>Скорее всего значительно хуже. Автор топика напихает туда всяких "слоёв" и "паттернов", в результате код превратится в технологическую помойку. А на каждый фич реквест будет требоваться по месяцу кодирования, так как именно эта фича не вписывается в гениальную внедрённую архитектуру. Поэтому сначала требуется в очередной раз переделать фреймворк и внедрить ещё парочку "паттернов". Потом автору самому это надоест и он свалит проект на другого разработчика, который будет тщетно пытаться врубиться как оно работает и работает ли вообще.

Чего вы на ТС гоните? Он уже принял верное решение обойтись без революций. Это очень хороший признак, IMHO...

A>Это не цель, а стиль кодирования.
A>Есть какая-то изолированная функция, на неё куча тестов. То есть известно, что в целом она работает верно. Но приходится немного модифицировать её.

Так это как раз и есть "рефакторинг по месту". Когда _уже сейчас_ нужно что-то делать с данной функцией.
Я же возражал против "вялотекущего рефакторинга ради вероятной перспективы в отдаленном будущем". Если у рефакторинга нет конкретной цели и его проведение не обусловлено никакими причинами кроме "хочу сделать чтобы было хорошо" — вот против такого рефакторинга я возражаю.

A>Я создал эту тему, чтобы услышать, что у кого-то был опыт (успешный или не успешный) в переписывании проектов с нуля
..........
A>Я сторонник agile процесса и DDD, при которых не исключается,а наоборот приветствуется постоянный рефакторинг.

Одному мне видится противоречие в двух рядом стоящих фразах одного сообщения одного автора?

Pzz>Вы не представляете, сколько раз мне рассказывали эту сказку.

А вы не представляете, сколько раз я слышал сказку про "вот сейчас потренируемся, и потом за 5 минут добежим". Или, как вариант, "да осталось буквально еще пару зубьев у пилы наточить, а там — весь лес спилим за полчаса!"
Разумеется, ни сейчас, ни потом лес так и не спиливался.

Pzz>Ну правильно, вы же первую версию формочек написали, не задумываясь о том, как вы будете ее менять. Вторую-третью сделали на заплатках. Каждая следующая уже выносит мозги, потому что новый слой заплаток становится некуда пришивать.

Угу.
А ваш проект первой версии формочек на рынок так и не вышел, потому что проект закрыли. Каждый счастлив, каждый получил опыт.

Здравствуйте, SkyDance, Вы писали:

SD>А вы не представляете, сколько раз я слышал сказку про "вот сейчас потренируемся, и потом за 5 минут добежим". Или, как вариант, "да осталось буквально еще пару зубьев у пилы наточить, а там — весь лес спилим за полчаса!"
SD>Разумеется, ни сейчас, ни потом лес так и не спиливался.

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

Здравствуйте, Kerk, Вы писали:

K>Ну так люди и делятся своим опытом. Который говорит, что желание все переписать очень часто говорит о низкой квалификации. Я бы не стал в этом видеть личные нападки.

Поддерживаю.

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

K>>Ну так люди и делятся своим опытом. Который говорит, что желание все переписать очень часто говорит о низкой квалификации. Я бы не стал в этом видеть личные нападки.

S>Поддерживаю.

S>Да и вообще, ругать чужой код не прилично. Потому что вы не знаете, в каких условиях работал тот программист, когда писал говнокод. Может быть ему просто мало платили и трахали мозги каждый день, требуя немедленных результатов, вот он им и выдавал. А вы бы со своим грамотным подходом просто не справились бы в поставленные сроки. Кто знает кто знает.

Есть такое но также и есть то, что некоторые такое накодят, даже в идеальных условиях.

Здравствуйте, SkyDance, Вы писали:

SD>Не совсем. Я бы даже сказал, совсем не. Разработка софта больше похожа на серию стометровок.

да хоть и серию стометровок. иногда надо разгребать, что б не бежать по колено в этом самом. А то там глядишь, твоя серия стометровок превратится в серию заплывов на 100 метров.

Здравствуйте, SkyDance, Вы писали:

A>>Есть какая-то изолированная функция, на неё куча тестов. То есть известно, что в целом она работает верно. Но приходится немного модифицировать её.

SD>Так это как раз и есть "рефакторинг по месту". Когда _уже сейчас_ нужно что-то делать с данной функцией.
SD>Я же возражал против "вялотекущего рефакторинга ради вероятной перспективы в отдаленном будущем".

Видно наше понимание велотекущего рефакторинга несколько отличается. В моём представлении, если ты видишь что строка "НашаСамаяГлавнаяТаблицаВБазеДанных" повторяется во многих местах, то можно создать для неё константу или макрос, причём даже не обязательно устранять все использования этой строки, а только те, которые оказались под рукой.

Здравствуйте, alzt, Вы писали:

A>Видно наше понимание велотекущего рефакторинга несколько отличается. В моём представлении, если ты видишь что строка "НашаСамаяГлавнаяТаблицаВБазеДанных" повторяется во многих местах, то можно создать для неё константу или макрос, причём даже не обязательно устранять все использования этой строки, а только те, которые оказались под рукой.

Чтобы никому не было обидно — в одном месте константу, для тех, что под рукой, в другой — макрос.

Здравствуйте, alpha21264, Вы писали:

A>Программы можно писать в разных стилях.
A>Упорядочивать их вдоль или поперек. Экономить или на одном или на другом.
A>Если твой предшественник писал в другом стиле — это не значит что его стиль хуже.
A>Более того — у тебя есть шанс посмотреть в чем его стиль лучше.
A>А когда поймешь — использовать плюсы и его и своего стиля.

скажите, вот это — стиль?

#ifndef _waxie_binary_resource_h_
#define _waxie_binary_resource_h_

#include <string>

class BinRes
{
public:
    BinRes();
    virtual ~BinRes();

public:
    static bool ExtractBinResource( wchar_t *strCustomResName, int nResourceId, wchar_t *strOutputName );
};

#endif

тут есть какие-то плюсы стиля?

A>Видно наше понимание велотекущего рефакторинга несколько отличается. В моём представлении, если ты видишь что строка "НашаСамаяГлавнаяТаблицаВБазеДанных" повторяется во многих местах, то можно создать для неё константу или макрос, причём даже не обязательно устранять все использования этой строки, а только те, которые оказались под рукой.

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

A>скажите, вот это — стиль?

Да, стиль. Что именно вас возмущает в приведенном кусочке кода?

Здравствуйте, Abyx, Вы писали:
A>тут есть какие-то плюсы стиля?
это стиль. если у него убрать венгерскую нотацию, дефайны большими буквами обьявлять, чтобы не спутать с дефайнами ф-ий, не сокращать BinaryResource до BinRes, и убрать второй public, то получится примерно как я пишу.

Здравствуйте, __kot2, Вы писали:

__>Здравствуйте, Abyx, Вы писали:
A>>тут есть какие-то плюсы стиля?
__>это стиль. если у него убрать венгерскую нотацию, дефайны большими буквами обьявлять, чтобы не спутать с дефайнами ф-ий, не сокращать BinaryResource до BinRes, и убрать второй public, то получится примерно как я пишу.

Осталось определиться что же есть такое "стиль". Например, в моем понимании, стиль это вот например:

class BinaryResource {

vs

class BinaryResource
{

или

BinaryResource
GetResource(ResourceId id)

vs

BinaryResource GetResource(ResourceId id);

Или, например, стиль именования переменных (pascale, camel..)

То есть нечто, больше относящееся к форматированию. Имена классов типа "BinRes", "a", "b", "ptr" и тп. это в моем понимании просто кривой код, подлежащий рефакторингу.
Использование хедера #include <string> и при этом параметры типа wchar_t скорее всего тоже кривость. Но тут уже надо разбираться с конкретным случаем.

> То есть нечто, больше относящееся к форматированию. Имена классов типа "BinRes", "a", "b", "ptr" и тп. это в моем понимании просто кривой код, подлежащий рефакторингу.
> Использование хедера #include <string> и при этом параметры типа wchar_t скорее всего тоже кривость. Но тут уже надо разбираться с конкретным случаем.

Оппа. Рефакторинг это оказывается переименование идентификаторов. Чудненько, а то я думаю чего это народ все обсуждает, митингует. Теперь я в теме тоже могу обсуждать рефакторинг