Malinnikov
+10
Сферические гранаты в вакууме.
Malinnikov
+21
Для разгребания результатов их работы потребуется еще больше вакансий.
Malinnikov
0
Спасибо за это приложение. Перешел на него со скитча и пользуюсь постоянно.
Malinnikov
0
Это тоже мое утверждение, но вы возражали на комментарий, который содержит другое.

Что касается именно этого, то я по-прежнему считаю, что плохой код — это плохая работа, но выяснится это после того, как плохой код проявит себя дополнительными затратами ресурсов, связанными с ним.
Malinnikov
0
Нет, не "все дополнительные затраты — это признак плохого кода".

Возможно, существуют допзатраты, которые порождены другими причинами, я не знаю всех причин.

Я утверждаю, что плохая работа — это причина дополнительных затрат, но я нигде не говорил, что всех.
Malinnikov
0
Вы сейчас возражаете против утверждения «все дополнительные затраты служат признаком плохой работы».

Напомню, что мое утверждение «плохая работа приводит к дополнительным затратам».

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

Но дополнительные затраты по прежнему фигурируют и плохую работу определить помогают.
Malinnikov
0
Я рад, что не зря потратил время и вы приняли мое определение плохой работы — она вызывает дополнительные затраты.

Именно это и есть объективный критерий ее определения.
Malinnikov
0
Смотрите: затраты труда на превращение плоской книги в древовидную — q. Если вы тратите не q, а q+d, то вы что-то сделали не так.

d — допзатраты, В этот момент вы понимаете, что надо было делать по-другому. Оказалось, что эта работа была сделана плохо.
Malinnikov
0
Зачем вы предлагаете обсуждать связь между плохой работой и удовлетворенностью заказчика?

Вы ведь возражаете против показателя дополнительных затрат, как признака плохой работы.

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

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

Ни один из этих вариантов моему определению не противоречит.
Malinnikov
0
Чей это риск, это другой вопрос. Если вы пытаетесь опровергнуть мое определение плохой работы, приводите, пожалуйста аргументы на эту тему. Если аргументов больше нет, то я благодарю вас за дискуссию.
Malinnikov
0
Итак, проверяем мой тезис: допзатраты есть (повышенный счет на новую фичу), понимание, что работа плохо сделана, есть.
Malinnikov
0
Вариант «соответствует, но внезапно захотелось больше чем в ТЗ записано» — это не мой тезис, пожалуйста, не приписывайте это мне.

Мой критерий определения плохой работы — это дополнительные затраты любых ресурсов, связанных с этой работой, которые пришлось понести впоследствии.

Это совсем не то, что «соответствует, но внезапно захотелось больше чем в ТЗ записано».
Malinnikov
0
Кто говорит о «непредвиденных затрат от заказчика»?

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

В этот момент кто-то поймет, что ту, первую работу сделали плохо.

При этом неважно, какие выгоды удалось или не удалось получить при использовании плохой работы. Речь идет о самом факте того, что кем-то была сделана тогда плохая работа.
Malinnikov
–1
Это утверждение легко опровергнуть. Работа может быть плохой вне зависимости от того, проверял ее заказчик или принял и оплатил, не проверяя.

Так не распознать плохую работу. Я предлагаю другой признак разпознавания.
Malinnikov
0
Речь не идет о новых требованиях, где вы это взяли? На новые фишки затраты планируются. Речь идет о дополнительных затратах, которых быть де должно.
Malinnikov
0
написал, что должен держать 10к, а потом внезапно захотел 100к

Затраты на достижение 100к не связаны с работой старого кода, это новая цель, новый проект.

А если это не работа старого кода привела к допзатратам, то это не тот случай.
Malinnikov
0
А никто и не говорит. А вот когда придется к ней возвращаться для переделок, терять время/деньги/репутацию, тогда все и прояснится. Согласны?
Malinnikov
0
Само определение затрат, как дополнительных, говорит о том, что изначально их быть не должно.
Malinnikov
0
Я смотрю, вы уже перешли к другому вопросу, как искать виноватого в случае обнаружения плохой работы.

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

Если после выполнения не пришлось тратить время и деньги на его код, проект не стрельнул по другим причинам, к исполнителю претензий нет.
Malinnikov
0
Пожалуйста, не опровергайте утверждений, которых я не делал.

Я говорю о том, что дополнительные затраты говорят о плохой работе, а не о том, что «простыня спагетти» это плохая работа.
Malinnikov
0
Нет- нет, не путайте. Если новую версию изначально планировалось писать, то это не дополнительные затраты, а запланированные изначально затраты.

Нет дополнительных затрат на поддержку первой версии — значит, работа по ней сделана хорошо. Что-то не работает, незапланированные доработки, переделки — значит, плохо.
Malinnikov
0
Итого: раз пришлось тратить доп. ресурсы (переписывание профессионалом), кто-то сделал работу плохо (в вашем примере это быдлокодер). Это как раз то, что я утверждаю.
Malinnikov
0
Отвечая на вопрос, адресованный UZER2006, вы уверены, что он утверждает именно это?
Malinnikov
0
Так что, плохую работу никак нельзя определить? Все можно объяснить/оправдать стилем, постановкой задачи, субъективностью оценок? Я правильно понимаю ваш тезис? (надеюсь, нет)
Malinnikov
0
Что «это»? С чем именно в моем утверждении вы не согласны? И что вы утверждаете? Каков ваш тезис?
Malinnikov
+2
Можно сколько угодно далеко углубляться в философские вопросы вроде «что понимать под...», «что такое работа» и т.д. Но плохой код (объективно плохой) существует. Как распознать эту объективность? Его существование отнимает дополнительные ресурсы. А это значит, что кем-то была сделана плохая работа.
Malinnikov
0
Понятие «код, который я считаю плохим» вы пытаетесь ввести только сейчас. В заметке идет речь об объективно плохом коде, а это плохая работа, да.
Malinnikov
+4
Что делать с плохо сделанной работой? Понять и простить? Отвечать ли за плохую работу других людей своим именем, репутацией? Переделывать все самому?
Malinnikov
+16
Они ведь могли узнать рецепты моей жены.
Malinnikov
0
При использовании id разработчик лишается compile time проверок, при использовании конкретных типов — не лишается. Так что же рациональнее использовать разработчику?
Malinnikov
0
Наличие id не означает, что Objective-C поощряет его использовать вместо конкретных типов.
Malinnikov
+1
Этот язык не приучает класть на типизацию и опасен не более, чем C или C++ при работе с указателями.
Malinnikov
+1
В новом xcode это не поправили, потому что этого никогда там не было.

Может, он и выдавал вам ошибку, но, боюсь, вы неправильно определили ее причину.

Тогда использовался gcc. Этот компилятор мог справиться с лишним пробелом и раньше 2010 года.
Malinnikov
+1
NSObject *object = [NSObject alloc];
NSObject * object = [NSObject alloc];

Две строки выше абсолютно одинаковы для компилятора, если вы это имеете в виду. Хотя, если вы пишете на C++, вам это должно быть известно.

Поясните, что вы имели в виду?
Malinnikov
+1
Пусть не пишут, нам больше достанется. :-)
Malinnikov
–1
Ох. Меня тоже все это смущает. Очень неточные формулировки и странные (иногда) выводы.
Malinnikov
0
Вы правы, init может вернуть совсем другой объект, но я говорю о том же.

Смотрите:

NSObject *object = [NSObject alloc];
[object init];

[object doSomeAction]; // использование неинициализированного объекта