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

I>Это вжик жаловался на сдвиги,
Как обычно ты в своих фантазиях весь. Я (вжик) привел пример разбора RIFF шапки сдвигами. И таки да, разбор RIFF сдвигами — это и есть пример говнокода.

Здравствуйте, Аноним, Вы писали:

I>>Это вжик жаловался на сдвиги,
А>Как обычно ты в своих фантазиях весь. Я (вжик) привел пример разбора RIFF шапки сдвигами. И таки да, разбор RIFF сдвигами — это и есть пример говнокода.

"А может ты просто читать код не умеешь ?" @ AS тут утверждает, что говно не в коде, а в девелоперах. Кому из вас верить ?

Я, кстати, сильно сомневаюсь, что только "разбор RIFF шапки" может быть примером говнокода.

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

А>>Как обычно ты в своих фантазиях весь. Я (вжик) привел пример разбора RIFF шапки сдвигами. И таки да, разбор RIFF сдвигами — это и есть пример говнокода.
I>Я, кстати, сильно сомневаюсь, что только "разбор RIFF шапки" может быть примером говнокода.

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

Здравствуйте, Аноним, Вы писали:

А>>>Как обычно ты в своих фантазиях весь. Я (вжик) привел пример разбора RIFF шапки сдвигами. И таки да, разбор RIFF сдвигами — это и есть пример говнокода.
I>>Я, кстати, сильно сомневаюсь, что только "разбор RIFF шапки" может быть примером говнокода.

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

Я не понимаю, "разбора RIFF шапки сдвигами" это единсвенно легальный вариант говнокода или есть другие ? Ты не ходи кругами, внятно ответь.

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

I>Я не понимаю, "разбора RIFF шапки сдвигами" это единсвенно легальный вариант говнокода или есть другие ? Ты не ходи кругами, внятно ответь.
Какой смысл тебе отвечать, если ты все одно не читаешь? Только форум загаживать? Для этого есть Политика, О жизни и т.п. Священные войны.

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

D>Тоже самое будут говорить про 2010 -- стиль сменился. Зато в 2030 все будут говорить какие были классные программеры в 2000ных -- на таком говне мамонта писали, такие сложные вещи, а у нас на 100500 ядерных машинах перерисовка окошек тормозит.

Нечто подобное сейчас говорят про программы для ZX Spectrum.

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

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

I>Говнокод означает, что внесение изменений требует неадекватного количества затрат относительно задачи. Скажем, если задача добавления кнопки занимает одну неделю, то это однозначно плохой код, независимо от того, какие девелоперы на проекте. Просто потому, что существуют решения, позволяющие эту задачу решать за время сравнимое со временем клика мышом.

Рискну утверждать, что это заблуждение.
"Задача добавления кнопки" может формулироваться так — "по нажатию на эту кнопку я хочу, чтобы мне выводилась оценка (valuation) моего инвестиционного портфолио". Казалось бы, что может быть проще — портфолию в базе уже есть, все бумаги известны, количества есть, и даже есть поле, куда эта оценка должна выводиться.
Однако математический аппарат под этой "кнопкой" — даже если взять классику Блэка-Шоулза — мало кто за неделю осилит.

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

I>>Говнокод означает, что внесение изменений требует неадекватного количества затрат относительно задачи. Скажем, если задача добавления кнопки занимает одну неделю, то это однозначно плохой код, независимо от того, какие девелоперы на проекте. Просто потому, что существуют решения, позволяющие эту задачу решать за время сравнимое со временем клика мышом.

SD>Рискну утверждать, что это заблуждение.
SD>"Задача добавления кнопки" может формулироваться так — "по нажатию на эту кнопку я хочу, чтобы мне выводилась оценка (valuation) моего инвестиционного портфолио".
Казалось бы, что может быть проще — портфолию в базе уже есть, все бумаги известны, количества есть, и даже есть поле, куда эта оценка должна выводиться.
SD>Однако математический аппарат под этой "кнопкой" — даже если взять классику Блэка-Шоулза — мало кто за неделю осилит.

Задача была простая "добавить кнопку на тулбар". То есть, пример вполне конкретный — добавить кнопку и связать с имеющимся готовым функционалом. Это и есть именно тот пример, про который я говорил.

I>Задача была простая "добавить кнопку на тулбар". То есть, пример вполне конкретный — добавить кнопку и связать с имеющимся готовым функционалом. Это и есть именно тот пример, про который я говорил.

Откуда нам знать вашу ситуацию? Может статься, что тулбары разрабатывали очень давно, и требования к ним были жесткие и точно сформулированные: вот такой набор кнопок, вот так себя ведёт. Программисты сделали ровно то, что от них требуется. В тот момент тулбар развивать не планировалось. И каждое последующее добавление кнопки шло со словами "вы добавьте прямо сейчас, нам не до рефакторинга, надо пилить — завтра релиз". Вы же не думаете всерьез, что важный релиз будут переносить лишь потому, что через 3-5 лет понадобится добавить еще кнопок на тулбар?

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

I>>Задача была простая "добавить кнопку на тулбар". То есть, пример вполне конкретный — добавить кнопку и связать с имеющимся готовым функционалом. Это и есть именно тот пример, про который я говорил.

SD>Откуда нам знать вашу ситуацию? Может статься, что тулбары разрабатывали очень давно, и требования к ним были жесткие и точно сформулированные: вот такой набор кнопок, вот так себя ведёт. Программисты сделали ровно то, что от них требуется. В тот момент тулбар развивать не планировалось. И каждое последующее добавление кнопки шло со словами "вы добавьте прямо сейчас, нам не до рефакторинга, надо пилить — завтра релиз". Вы же не думаете всерьез, что важный релиз будут переносить лишь потому, что через 3-5 лет понадобится добавить еще кнопок на тулбар?

Объяснение есть у каждого. Я в курсе, очень удобно пилить деньги кастомера. Ну добавляется кнопка месяц, ну и что в этом плохого ? Раз кастомер платит, так хоть полгода.

Это подход распильных проектов: "полгода до релиза, месяц пишем фичи, четыре месяца фиксим кнопки, месяц общий багфикс"

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

Мне такой подход категорически не нравится.

I>Объяснение есть у каждого. Я в курсе, очень удобно пилить деньги кастомера. Ну добавляется кнопка месяц, ну и что в этом плохого ? Раз кастомер платит, так хоть полгода.

Не пойму, вы сейчас радеете за деньги кастомера? Или считаете, что заказчик идиот? А не этот ли заказчик 5 лет назад сэкономил, и вместо рефакторинга кривой подсистемы сказал "нет, мне надо сейчас и быстро"? Если этот же, то какие могут быть претензии.

I>Это подход распильных проектов: "полгода до релиза, месяц пишем фичи, четыре месяца фиксим кнопки, месяц общий багфикс"

У меня сложилось обратное ощущение. Ибо распил — это как раз "мы делаем правильную архитектуру, которая через 5 лет позволит нам легко менять кнопки на тулбаре". Не знаю, как у вас, но в большинстве связанных с бизнесом мест такие начинания быстро бы пресекались, ибо что через 5 лет будет, даже Доу Джонс не знает.

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

SD>Не пойму, вы сейчас радеете за деньги кастомера? Или считаете, что заказчик идиот? А не этот ли заказчик 5 лет назад сэкономил, и вместо рефакторинга кривой подсистемы сказал "нет, мне надо сейчас и быстро"? Если этот же, то какие могут быть претензии.

Привык людей не обсчитывать.

Кастомер ничего не понимает в софтостроении, вообще ничего, более того, у него целая куча ложных моделей, аналогий.

Если кастомер экономит, ему нужно четко объяснять, какие последствия этой экономии. Я собтсвенно всегда так и делаю, если кастомер не хочет слышать такие эстимейты, я не хочу с ним работать, пусть его деньги пилят все кому не лень.

Если кнопка добавляется месяц, то как минимум нужно донести до кастомера о наличии этой особенности, потому что это само по себе уже большой риск. Опаньки ! А твоя обязанность сообщать кастомеру о таких вот рисках. Если ты этого не делаешь, ты просто обсчитываешь кастомера.

Ты предлагаешь распильный вариант — если кастомер не в курсе, давай возьмем денег по максимуму.

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

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

I>>Это подход распильных проектов: "полгода до релиза, месяц пишем фичи, четыре месяца фиксим кнопки, месяц общий багфикс"

SD>У меня сложилось обратное ощущение. Ибо распил — это как раз "мы делаем правильную архитектуру, которая через 5 лет позволит нам легко менять кнопки на тулбаре". Не знаю, как у вас, но в большинстве связанных с бизнесом мест такие начинания быстро бы пресекались, ибо что через 5 лет будет, даже Доу Джонс не знает.

Во первых, Это ведь ты утверждаешь, что добавление кнопки может занимать сколь угодно много времени, хоть минуту, хоть день, хоть месяц и считаешь что это нормально.

Во вторых, покажи, где я говорил про 5 лет ?

I>Кастомер ничего не понимает в софтостроении, вообще ничего, более того, у него целая куча ложных моделей, аналогий.

Хотите сказать, ваш заказчик — глуп и ничего не понимает в том, как надо вести бизнес? Тогда он разорится независимо от того, сэкономите вы ему деньги, или нет. Поэтому будем исходить из предположения, что заказчик таки может привлечь сторонних экспертов и при существенном расхождении в оценках спросить "как же так".

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

I>У меня как раз такой проект сейчас, разрабатывался непойми кем с 2001го года.
<...>
I>Во вторых, покажи, где я говорил про 5 лет ?

Шизофренией какой-то попахивает... окей, не 5, пусть будет 12 лет.

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

I>>Кастомер ничего не понимает в софтостроении, вообще ничего, более того, у него целая куча ложных моделей, аналогий.

SD>Хотите сказать, ваш заказчик — глуп и ничего не понимает в том, как надо вести бизнес? Тогда он разорится независимо от того, сэкономите вы ему деньги, или нет. Поэтому будем исходить из предположения, что заказчик таки может привлечь сторонних экспертов и при существенном расхождении в оценках спросить "как же так".

Заказчик ничего не понимает в софтостроении. Вообще ничего. Он как ребенок, ему надо объяснять по многу раз. А ведение бизнеса здесь абсолютно ни при чем.

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

I>>Во вторых, покажи, где я говорил про 5 лет ?
SD>Шизофренией какой-то попахивает... окей, не 5, пусть будет 12 лет.

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

I>Его решения основаны только желанием получить результат, а не реальным опытом и уж точно не знаниями о ситуации в проекте. Потому если заказчик настаивает на быстром введении фичи, ему нужно пояснить внятно какие риски такое решение создаёт и как это скажется в будущем.

Да 5 лет назад "заказчик" представлял из себя вообще других людей. И интересы могли быть другими, и требования, и продукт, и вообще это могла быть другая компания.

I>Ты покажи где я про такое говорил

Прямо здесь и пишешь:
I>У меня как раз такой проект сейчас, разрабатывался непойми кем с 2001го года.

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

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

I>>Его решения основаны только желанием получить результат, а не реальным опытом и уж точно не знаниями о ситуации в проекте. Потому если заказчик настаивает на быстром введении фичи, ему нужно пояснить внятно какие риски такое решение создаёт и как это скажется в будущем.

SD>Да 5 лет назад "заказчик" представлял из себя вообще других людей. И интересы могли быть другими, и требования, и продукт, и вообще это могла быть другая компания.

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

I>>Ты покажи где я про такое говорил

Сейчас у меня веб проект, там нет никаких кнопок на тулбаре

SD>В каком году было принято решение про злосчастные кнопки на тулбаре? Вряд ли год назад.
SD>Соответственно, на тот момент риск "добавление очередной кнопки может обойтись на 2 рабочих дня дороже" проблемой не являлся.

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

I>Правильно. Так вот обычно софт пишется с учетом того, что требования будут меняться. То есть, нужна гибкость. А вот добавление кнопки за месяц это на гибкость мягко говоря не похоже.

По пунктам. Во-первых, софт обычно пишется по утвержденным требованиям, а также в утвержденные сроки и бюджеты. В процессе разработки всегда ищется компромисс между гибкостью, надёжностью, тестируемостью и еще кучей "-стью". И, само собой, бюджетом и сроками. Ситуация, когда выбор делается не в пользу гибкости — более чем стандартна.
Во-вторых, я не верю в месяц на добавление кнопки. Имею на то право. Можем проверить: я возьму код, месячную зарплату команды и сделаю пресловутую кнопку. Это при том, что я не в теме совершенно, и, скорее всего, даже не знаю язык, на котором там всё написано.

I>Риск появился сразу же.

И его митигировали путём откладывания.
Это тоже обычный способ решения проблем. Путём откладывания. А там ишак уже того...

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


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

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

SD>Во-вторых, я не верю в месяц на добавление кнопки. Имею на то право.

Я тоже не верил, пока не протащил свою первую кнопку. Реально конечно не месяц месяц на кнопку, а месяц на кнопки для готовой фичи. Это время с добавлением, отладкой, багфиксом кода связывания кнопок. Добавил кнопку — а в N+1 сценарии кнопка теряет свое состояние, из нажатого становится отжатой. В N+2 кнопка создает проблемы для других кнопок. В N+3 кнопка создает побочный эффект — креш если открыта вьюха A.
Такая вот орхетектура, что бы только отыскать код который влияет на кнопки или наоборот, надо убить вагон времени.

>Можем проверить: я возьму код, месячную зарплату команды и сделаю пресловутую кнопку. Это при том, что я не в теме совершенно, и, скорее всего, даже не знаю язык, на котором там всё написано.

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

SD>И его митигировали путём откладывания.

Правильно. Оттягивали решение до тех пор, пока девелоперы не стали 100% времени писать водопроводный код. И проект ожидаемо умер и попал на воскрешение, где им и занялся me

SD>Это тоже обычный способ решения проблем. Путём откладывания. А там ишак уже того...

Новый слово в инженерии — решать проблему путём её откладывания. Попробуй на практике применить, найди работу с почасовой оплатой, когда кастомер будет время от времени или постоянно пересматривать ваши репорты, чего сделано и сколько затрачено. Только естесвенно все репортай честно — добавлял кнопку месяц, значит пишешь: "таск нумер ААА12345 'байндинг кнопки XXX' 160 часов."

P.S. У меня вопрос напоследок, не собирался ли ты ЗП команды за месяц получить путем откладывания проблемы на потом ?

I>Правильно. Оттягивали решение до тех пор, пока девелоперы не стали 100% времени писать водопроводный код. И проект ожидаемо умер и попал на воскрешение, где им и занялся me

Видишь как здорово. Все довольны. Тебе есть работа, заказчикам — проект, инвесторам — деньги много лет капали. Причем, сдается мне, неплохие, раз осталось на реанимацию полумёртвого проекта. Жизнь как она есть.

I>Новый слово в инженерии — решать проблему путём её откладывания.

Прямо мои слова, из 2007 (?) года. Я тоже негодовал и демонстрировал бурю протеста. Видишь, всего-то понадобилось 6 лет и работа на разных должностях, чтобы понять — и такое решение тоже решение. Обидно, но факт: это зачастую работает много лучше, чем созывать митинги, генерировать тонну виртуальной бумаги и заниматься умным рефакторингом.
Цинично? Разумеется. А как иначе. Такова жизнь.