Смотрю на разработки лидеров рынка (MS, Oracle, Google) -- почти всегда с первого релиза прямо как игрушки: все ровненько, продумано нигде ничего не торчит, красивая документация и пр.

Когда смотришь код продуктов MS -- почти везде XML-комментарии, навороченная архитектура, придерживаются корпоративного стиля кодирования. Писать такой код намного сложнее, чем просто рабочий.

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

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

28.02.2012 1:22, Здравствуйте, IObserver :
> И действительно, кому это все *практически* нужно?

Дьявол он всегда в мелочах. Я от аськи отказался не потому, что там нет
видеозвонков, а потому, что мелочи (реклама родного клиента, падучесть
миранды, сохранение паролей квипом) просто достали. Я пользуюсь NNTP на
кывт не потому, что родной веб-клиент криво написан, а потому что в вебе
нет таких мелочей, как переход между сообщениями по пробелу и отправки
по ctrl+enter.

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

IO>Когда смотришь код продуктов MS -- почти везде XML-комментарии, навороченная архитектура, придерживаются корпоративного стиля кодирования. Писать такой код намного сложнее, чем просто рабочий.

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

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

IO>Когда смотришь код продуктов MS -- почти везде XML-комментарии, навороченная архитектура, придерживаются корпоративного стиля кодирования. Писать такой код намного сложнее, чем просто рабочий.



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

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

L>А можно спросить, что есть "просто рабочий" код? А то есть подозрение, что автор имеет в виду т.н. "говнокод" в том или ином его проявлении.

Бывает и красиво оформленный говнокод.

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

L>А можно спросить, что есть "просто рабочий" код? А то есть подозрение, что автор имеет в виду т.н. "говнокод" в том или ином его проявлении.

Не обязательно говнокод, хотя и это тоже (кстати, на это сайте был опрос -- очень много людей сознались, что умышленно пишут говнокод). Для C# мог легко объяснить: включите все правила проверки в VS или используйте FXCop. Если все эти рекомендации выполнять -- времени уходит в 2 раза больше. Хотя на практике пользователь этой работы не увидит и очень вряд ли, что вы столкнетесь с этим. А если еще и качественную документацию писать, то будет еще медленнее.

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

IO>включите все правила проверки в VS или используйте FXCop. Если все эти рекомендации выполнять -- времени уходит в 2 раза больше.

Сейчас спроси людей -- выполняете ли вы правила FxCop и пишите ли документацию. Большинство ответят что нет. А если будут выполнять -- то будут писать код в 2 раза медленнее.

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

Не пишут потому, что требуется рабочий функционал. Мало кто задумывается о будущем проекта, о том, что незнающий кода будет долго разбираться, и на это уйдет ощутимо больше времени чем написание документации писавшим этот код.
Но люди думают о своем будущем — они всегда будут востребованы на этом проекте, как единственно знающие что там внутри.
Зачем писать тесты, когда можно обернуть все в try-catch?, зато потом кому-то будет работа по тестированию и отлову багов.
Обычно все упирается во время и деньги, т.е. задают вопрос заказчику согласен ли он платить за это , а он, естественно, не понимая смысла в в этом, отказывается.

IMHO внимание к мелочам есть естественное следствие учета того как продается продукт, да и выводов современного маркетинга вообще. Недостаточно иметь хорошие "технические" характеристики, так как без возможности заинтересовать и впечатлить на первоначальной демонстрации до проверки характеристик продукта может и не дойти. К тому же в последнее время потребителей приучают к качеству исполнения (например Apple) и продукты, недостаточно вылизанные в мелочах априори внушают ощущение более низкого качества, пусть даже это и неоправданно.

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

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

K>На самом деле не факт что вылизывание так уж дорого, если отношение к мелочам и создание неотвратного продукта заложено в культуру разработки. Переделывать то что наделали тяп-ляп программисты — да, дорого, но делать хорошо сразу намного дешевле.

Нифига не дешевле. Дороже, причем раз в 10. Еще попробуйте найти человека, который будет внимателен к мелочам.

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

В итоге первый без особого напряга сделал в принципе работающее и выполняющее свои фунцкции за 2 мес (но там криво, там на скорую руку...). Второй, работая очень тяжело даже на новогодние праздники -- только через 4 мес. довел свое произведение до Beta-версии (хотя под конец пришлось отказаться от принципов и делать просто быстро, т.к. сроки). Притом второй хотел еще и тесты писать, даже часть функционала покрыл тестами, но потом забил, т.к. элементарно нет на это времени (даже старые тесты не поддерживаются и исключены из проекта).

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

IO>Проверили -- делали одновременно 2 разработчика один и тот же продукт. Первый делал как можно быстрее без внимания к мелочам. Второй тщательно вылизывал, начиная от архитектуры, заканчивая расположением элементов на форме (внешний вид, юзабилити, элементарный дизайн).

IO>В итоге первый без особого напряга сделал в принципе работающее и выполняющее свои фунцкции за 2 мес (но там криво, там на скорую руку...). Второй, работая очень тяжело даже на новогодние праздники -- только через 4 мес. довел свое произведение до Beta-версии (хотя под конец пришлось отказаться от принципов и делать просто быстро, т.к. сроки). Притом второй хотел еще и тесты писать, даже часть функционала покрыл тестами, но потом забил, т.к. элементарно нет на это времени (даже старые тесты не поддерживаются и исключены из проекта).

Судя по... тексту, ты ведь молодой программист?
Второй программист "тщательно вылизывал" теми же методами, что и первый?
Или использовал ДРУГУЮ методу? А квалификация одинаковая?
Тут тебе старшие товарищи говорят именно про методу.
У нас (у программистов) от перестановки слагаемых много что меняется.
Сначала сделать, а потом подумать или сначала подумать а потом сделать.

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

A>Судя по... тексту, ты ведь молодой программист?

Я говорю не от первого лица и обосновываю не свое мнение

A>Второй программист "тщательно вылизывал" теми же методами, что и первый?

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

IO>Смотрю на разработки лидеров рынка (MS, Oracle, Google) -- почти всегда с первого релиза прямо как игрушки: все ровненько, продумано нигде ничего не торчит, красивая документация и пр.

Это ты невнимательно смотрел Я вот и на гугловском, и на оракловком сайтах натыкался на явные косяки. Правда, они были запрятаны в глубинных редко посещаемых уголках сайта и, по-видимому, не сильно мешали основной массе пользователей. Да и в вижуалстудии баги иногда вылазят (но, опять же, не на поверхности).

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

Выходят боком в том случае, если были ошибки при постановке задачи — неправильно расставили приоритеты. Если же приоритеты расставлены правильно — тогда, наоборот, эти усилия приносят пользу.
Вообще "мелочь" — понятие относительное. Часто бывает так: какая-то фигня, на первый взгляд незначительная, на самом деле именно для этой задачи оказывается критично важной. Так что с мелочами надо аккуратно. Забить на мелочь можно, но только тогда, когда есть уверенность, что это действительно мелочь.

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

IO>Нифига не дешевле. Дороже, причем раз в 10.

Зависит от. Для одноразового продукта действительно политика вида "быстренько склепали за 2 месяца, продали один раз и забыли навсегда" вполне себе оправдана.
А ты не пробовал провести подобный анализ для продуктов с жизненным циклом в 8-10 (а то и 15!) лет? Сколько составила прибыль от продаж продукта1 и продукта2, какую долю рынка заняли эти продукты, каковы были итоговые затраты не только на разработку, но и на последующее сопровождение и модификацию? Ведь ситуация, когда требования ни в чем не изменились за эти самые 8-10-15 лет, и багов не было найдено ни одного, и все эти годы все так же успешно продается первая (и она же единственная!) версия продукта.... хм, мне представляется довольно маловероятной. Нет?

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

IO>Не обязательно говнокод, хотя и это тоже (кстати, на это сайте был опрос -- очень много людей сознались, что умышленно пишут говнокод). Для C# мог легко объяснить: включите все правила проверки в VS или используйте FXCop. Если все эти рекомендации выполнять -- времени уходит в 2 раза больше. Хотя на практике пользователь этой работы не увидит и очень вряд ли, что вы столкнетесь с этим. А если еще и качественную документацию писать, то будет еще медленнее.

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

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

одно дело писать библиотеку, которой будут (или не будут если не понравится) пользоваться сотни тысяч/миллионы программистов или конечных пользователей,
и другой — писать в команде из трех программистов для четырех юзеров, которые никуда не денутся если что-то с приложением не так

над мелочами работают, если считают что это приносит деньги, и не работают, когда считают что не приносит (или приносит меньше чем что-то другое)

28.02.2012 13:04, Здравствуйте, Vlad_SP :
> Зависит от. Для одноразового продукта действительно политика вида
> "быстренько склепали за 2 месяца, продали один раз и забыли навсегда"
> вполне себе оправдана.

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

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

B>Ну у нас включен FxCop.
B>Комментарии пишем. Времени больше практически не требуется.

Что за бред? Даже напечать комментарий -- уже требуется время (100-200 симв. в мин.). А если еще и подумать как написать более понятно -- еще больше времени.

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

То же самое по отношению к правилам кодирования, наименования и тестам.

B>Слесаря тоже бывают разными. У одного бардак и грязь и после него еще полы мыть надо.
B>Другой придет, почти ничего не заляпает, а если где капнуло, то сам вытерет.
B>Второй, что характерно, еще и работает быстрее

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

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

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

B>>Ну у нас включен FxCop.
B>>Комментарии пишем. Времени больше практически не требуется.

IO>Что за бред? Даже напечать комментарий -- уже требуется время (100-200 симв. в мин.). А если еще и подумать как написать более понятно -- еще больше времени.

Верить или не верить — это твое дело.
Говорю как есть.
Накладные расходы не больше пяти процентов от времени кодирования.
А если учесть, что кодирование — это далеко не самая большая часть на проекте,
то вообще не о чем говорить.

IO>Даже методики оценки времени на разработку обязательно учитывают пишутся комментарии или нет.

IO>То же самое по отношению к правилам кодирования, наименования и тестам.

B>>Слесаря тоже бывают разными. У одного бардак и грязь и после него еще полы мыть надо.
B>>Другой придет, почти ничего не заляпает, а если где капнуло, то сам вытерет.
B>>Второй, что характерно, еще и работает быстрее

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

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

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

Здравствуйте, Ромашка, Вы писали:



Р>Не только для одноразового. Если нужно быстро выйти на рынок, то так и
Р>пишут. Главное место застолбить.

Именно так и есть.

И я считаю, что для нового коробочного продукта с неизвестным заранее спросом так и надо делать.
Застолбить, а там уже думать и разгребать завалы.

А то пока семь раз будешь отмерять, кто нибудь другой отрежет



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

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

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

Речь не о грязи, а о качестве работы. Грязь на стройке потом убрать можно, а качество не изменишь.

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

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

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

Поясню на примере. Допустим, вы заказали чтобы вам покрасили дверь и очень заинтересованны не переплатить. Один маляр берет самую дешевую краску, которой вообще нельзя в помещении пользоваться. Второй фирменную, которая 15 лет не будет "шелушиться".

Кроме того, второй тщательно подготовит поверхность перед покраской: удалит мусор, обезжирит, покроет абразивом и пр.

Внешне двери будут выглядеть почти одинаково. Но в первом случае через 2 года вам придется опять вызывать маляра, во втором можете не заглядывать еще 15 лет.

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