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

I>>В большинстве проектов язык не является узким местом. 90% времени/бюджета не на код.

VD>Ага. 90% бюджета тратится на то, чтобы выразить на языке то, что на нем плохо выражается.

90% тратится на вещи вообще не связаные напрямую с кодом

>Ради этого придумываются архитектуры, модели и прочая дребедень о которой говорит автор. Достаточно взглянуть на его пример с парсером, чтобы понять что тот кто писал этот код бездарно убил 99% своего времени.

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

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

I>>>>Неужели абзац выше сложно прочесть ?
G>>>Кто сказал что они являются комментами? Почему далее все рассуждения опираются на то что статические типы являются кооментами\метаданными?
I>>Хорошо, давай начнём с меньшего : "Если статические типы являются коментами, тогда мне кажется,"
G>Давай, теперь надо доказать что статические типы являются комментариями, иначе все следующие рассуждения не имеют смысла.

Не надо. Сравни "Если статические типы являются коментами" и "Статические типы являются коментами"

I>>С чем ты не согласен ?
G>Я не согласен с некорректными, с точки зрения булевой логики, утверждениями.

"Если" != ""

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

I>90% тратится на вещи вообще не связаные напрямую с кодом

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

>>Ради этого придумываются архитектуры, модели и прочая дребедень о которой говорит автор. Достаточно взглянуть на его пример с парсером, чтобы понять что тот кто писал этот код бездарно убил 99% своего времени.

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

Ну, ты выше уже сказал, что 90% времени работы над своим проектом вы тратите в пустую.
Вот только вывод сделал не верный, что это не зависит от языка.

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

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

Вот вот. А еще есть требования, к примеру, набор кадров, переписка всякая, настройки всякой всячины, переговоры всякие и тд и тд и тд.

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

VD>Ну, ты выше уже сказал, что 90% времени работы над своим проектом вы тратите в пустую.

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

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

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

I>>90% тратится на вещи вообще не связаные напрямую с кодом

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

Если сюда добавить анализ требований, тестирование и внедрение, то от написания кода и останется 10-20 процентов времени. И в итоге надо получить не программный код, а работающее решение, которое устраивает заказчика/покупателя. А не красивый код. Красивый код — это средство, которое в общем случае помогает снизить издержки на только часть процесса производства программного продукта.

ЧТо бы написать код надо (грубо):

1. Сделать предпроектное исследование, в рамках которого код не пишут, продаться
2. Иметь заключенный контракт, в рамках которого будут куча документации, но ни строчки кода.
2. Формализованные и понятные требования. ТОже без единой строчки кода

После кодирования:

1. тестирование.
2. Потом это все что накодировали надо установить и заставить взлететь.
3. закодировал — задокументруй за собой (РП, РА )
4. Теперь все это надо СДАТЬ

Так что поддержу утверждение, что на код тратиться меньшая часть времени. Просто разработчикам в основном она и видна

И кстати , если кодирование начинает занимать в процессе слишком много времени, то одно из двух:
1. Слишком мало времени уделяется другим фазам (скорее всего страдает тестирование или сбор требований — соответственно или много багов доходит до заказчика или заказчик получает не то что хотел ).
2. Сликом много не поддерживаемого кода — большая стоимость внесения изменений.

VD>Ну, ты выше уже сказал, что 90% времени работы над своим проектом вы тратите в пустую.
VD>Вот только вывод сделал не верный, что это не зависит от языка.

Не правда, было сказано, что 90% занимает не код И это время не впустую проходит. Это кодить без это работы — впустую выкинутое время — все равно придется перекодировать.

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

VD>>Ну, ты выше уже сказал, что 90% времени работы над своим проектом вы тратите в пустую.
VD>>Вот только вывод сделал не верный, что это не зависит от языка.

В>Не правда, было сказано, что 90% занимает не код И это время не впустую проходит. Это кодить без это работы — впустую выкинутое время — все равно придется перекодировать.

Ну что ты, в самом деле, раз 90% занимает ни код, ни, тем более, код на ...(ой!), значит время тратится впустую.

Следующим шагом в развитии индустрии ПО вероятно будет обязательное требования уметь писать на ...(ой!) начиная от охраны, уборщиц и заканчивая CEO и советом директором, не говоря про дизайнеров в т.ч. интерьера, отделы маркетинга и продаж, но также и контрактёров — переводчиков документации.

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

I>Вот вот. А еще есть требования, к примеру, набор кадров, переписка всякая,

Это не работа для программиста.

I>настройки всякой всячины, переговоры всякие и тд и тд и тд.

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

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

VD>>Ну, ты выше уже сказал, что 90% времени работы над своим проектом вы тратите в пустую.

I>Ничего подобного я не говорил

Ага. Ты это сказал не так явно. Но суть от этого не меняется. Программист должен 90% времени посвящать своему коду. Это конечно, не значит, что он должен долбить код с утра до вечера, но все его действия должны быть связаны с написанием кода. Скажем, разработка алгоритма — это часть процесса разработки. В этот момент ты можешь не писать код, но это все равно часть общего процесса в результате которого получается код. И эффективность этого процесса несомненно зависит и от выбранного языка. Ведь если язык не позволяет описать задачу близко ее естественному описанию, то вы будете тратить море времени на "архитектуру" и прочую фигню, которая, как вам кажется, имеет отношение к делу, но на самом деле является накладными расходами используемого языка.

I>Обычно время записи решения в коде много меньше времени собственно времени решения.

И это говорит о неэффективности. Разве что мы по разному понимаем понятие "записи решения".

I> Или ты хочешь сказать, что решаешь только те задачи, которые не требуют размышлений ? В этом случае конечно скорость кодогенерации крайне важна

Я как раз люблю решать сложные задачи, которые требуют много размышлений. И иногда я даже специально отхожу от компьютера чтобы подумать о задаче по-серьезнее. Но 90% на размышления я точно не трачу. Задачи средней легкости я вообще проектирую в процессе решения, так как опыт подсказывает правильное решение.

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

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

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

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

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

I>>Вот вот. А еще есть требования, к примеру, набор кадров, переписка всякая,

VD>Это не работа для программиста.

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

Или вопросов у тебя никогда не возникает ?

I>>настройки всякой всячины, переговоры всякие и тд и тд и тд.

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

Для некоторых контор дешевле научить программиста настраивать окружение(сервер, продукт и тд), для некоторых — дать в помощь админа, для некоторых — и целый отдел будет ненакладно.
У тебя же как то категорично выходит

I>>Ничего подобного я не говорил

VD>Ага. Ты это сказал не так явно. Но суть от этого не меняется. Программист должен 90% времени посвящать своему коду.

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

Опять же, в зависимости от конторы спектр задач меняется. Здесь нет серебряной пули — в крупных контора разделение задач более сильное, в мелких чаще приходится совмещать обязанности. Везде свои плюсы и свои минусы.

I>>Обычно время записи решения в коде много меньше времени собственно времени решения.

VD>И это говорит о неэффективности. Разве что мы по разному понимаем понятие "записи решения".

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

I>> Или ты хочешь сказать, что решаешь только те задачи, которые не требуют размышлений ? В этом случае конечно скорость кодогенерации крайне важна

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

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

Что же касается языка, то нужно разделять понятия язык и речь

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

I>Опаньки, до тебя что, доводят абсолютно истинные требования, которые ты не имеешь права обсуждать если чего вылезет ?

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

I>Или вопросов у тебя никогда не возникает ?

Вопрос надо решать в рабочем порядке. Но не тратить же на это основное время?

I>>>настройки всякой всячины, переговоры всякие и тд и тд и тд.

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

I>Для некоторых контор дешевле научить программиста настраивать окружение(сервер, продукт и тд), для некоторых — дать в помощь админа, для некоторых — и целый отдел будет ненакладно.

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

I>У тебя же как то категорично выходит

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

И совершенно не удивительно, что в конторе где программист тратит на код 10% времени, низка и общая эффективность. Это следствие неверной организации работы.

I>Если точнее, то я говорил про разработку ПО, а не про конкретного человека.

А у вас разработку ПО делает один человек? Если, нет, то наши позиции, возможно, сходятся. Фирма не должна посвящать разработке ПО 90% своего времени. Но программист (разработчик) обязан. Все что не посвящено непосредственно разработке — это накладные расходы. Без них, конечно же, никуда. Но оптимальный процесс разработки ПО — это процесс в котором такие накладные расходы минимизированы.

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

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

Это попытка словоблудием прекрыть неверную организацию работы.

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

I>Опять же, в зависимости от конторы спектр задач меняется.

+1, уважаемый КО.

I>Здесь нет серебряной пули — в крупных контора разделение задач более сильное, в мелких чаще приходится совмещать обязанности. Везде свои плюсы и свои минусы.

Не спорю. Но совмещение задач — это от бедности. И если уж кто-то совмещает задачи, то надо это и рассматривать как выполнение разной работы, и не говорить, что "программист тратит 90% не на программирование". Просто он же на 90% не программист.

Но для нас важно не то, что он на Х% не программист, а то, что частенько, выполненяя обязанности программиста, такой совместитель выполняет работу которя вообще не несет никакой пользы. Например, тот же ручной деплоймент.

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

VD>>И это говорит о неэффективности. Разве что мы по разному понимаем понятие "записи решения".

I>Решение бизнес задачи разумеется, а не генерация парсера.

Это дагестанская точка зрения. Термин "бизнес-задача" не имеет отношения к решению "автоматизации бизнеса" в понимании которое принято у нас. "Бизнес" — это дело. Генерация парсеров такое же дело как и все остальные. Чтобы сгенерировать эффективный парсер, может понадобиться даже больше усилий, нежели для проектирования БД для сложной финансовой системы (как и наоборот).

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

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

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

I>Есть много вариантов — держать программистов которые понимают в бизнес-задачах или держать технарей которым можно дать эксперта по бизнесу. Везде свои плюсы и минусы. А у тебя почему с одного краю эффективно, а с другого — нет

А я не об этом говорю. Программист обязан понимать что он делает. Тут нечего обсуждать. Но как это связано с временем затрачиваемым на разработку? Или мы учитываем в этом времени время на обучение прикладной области? Тогда давай еще и время на изучение программирования сюда приплетем.

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

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

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

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

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

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

Да не главное, но без него эффектности не добиться.

I>Что же касается языка, то нужно разделять понятия язык и речь

Ага. И еще не разводить демагогию .

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

В>Если сюда добавить анализ требований, тестирование и внедрение, то от написания кода и останется 10-20 процентов времени.

О, как? А написание тестов — это не написание кода?

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

С тестами же все как с обычным кода. Чем гибче язык, тем лучше на нем можно автоматизировать тестирование.
Ну, и на тесты не должно уходить более 20% времени разработки.

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

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

В> Красивый код — это средство, которое в общем случае помогает снизить издержки на только часть процесса производства программного продукта.

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

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

В>ЧТо бы написать код надо (грубо):

В>1. Сделать предпроектное исследование, в рамках которого код не пишут, продаться

Если код не пишут, то это не работа программиста. Хотя как раз разумно было бы код все же писать (прототипировать).

В>2. Иметь заключенный контракт, в рамках которого будут куча документации, но ни строчки кода.

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

В>2. Формализованные и понятные требования. ТОже без единой строчки кода

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

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

В>После кодирования:

В>1. тестирование.

Без кодирования? Вы мышкой что ли свое ПО тестируете?

В>2. Потом это все что накодировали надо установить и заставить взлететь.

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

В>3. закодировал — задокументруй за собой (РП, РА )

А на этапе проектирования вы что делали? Или у вас получившееся решение отличается от исходного?
Ну, да опять же. По уму тут нужно привлекать техрайтеров. Или опять получается использование программиста не по назначению. Ну, да по бедности и такое бывает. Но раз так, то не надо считать, что это часть разработки. Это часть работы которую человек вынужден совмещать с трудом программиста.

В>4. Теперь все это надо СДАТЬ

О, как? А это тоже программист делает?

В>Так что поддержу утверждение, что на код тратиться меньшая часть времени. Просто разработчикам в основном она и видна

Ребята, да у вас какая-то каша получается. Вы смешиваете несколько видов деятельности и на этом основании говорите, что разработка не является основным видом деятельности. Но это всего лишь разные виды деятельности. В конторах где есть более 4 человек она должна выполнятся разными людьми. А программист должен:
1. Проектировать.
2. Кодировать.
3. Писать и прогонять тесты.
4. Отлаживать и исправлять ошибки.

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

В>И кстати , если кодирование начинает занимать в процессе слишком много времени, то одно из двух:
В>1. Слишком мало времени уделяется другим фазам

Ага. Заключению договров и внедрению .

В>(скорее всего страдает тестирование или сбор требований — соответственно или много багов доходит до заказчика или заказчик получает не то что хотел ).

И что, много багов не относится к коду? Халтурно писали код, получите море отладки. Уделяйте больше времени и внимания качеству написания кода, и получите меньше отладки. А лучше повышайте уровень кода, и уровень его контроля.

В>2. Сликом много не поддерживаемого кода — большая стоимость внесения изменений.

А это тоже от кода не зависит?

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

В>Не правда, было сказано, что 90% занимает не код И это время не впустую проходит. Это кодить без это работы — впустую выкинутое время — все равно придется перекодировать.

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

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

I>Не надо. Сравни "Если статические типы являются коментами" и "Статические типы являются коментами"

I>>>С чем ты не согласен ?
G>>Я не согласен с некорректными, с точки зрения булевой логики, утверждениями.

I>"Если" != ""

Главное, что верно то, что статические типы не являются коментариями. Остальное вытекает по индукции.

Так что рассматриваемое утверждение исходно не верно.

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

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

E>>Перевод статьи на хабре: http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html

A>Я весь опус не читал: много буков.

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

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

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

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

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

I>>В большинстве проектов язык не является узким местом. 90% времени/бюджета не на код.

VD>Ага. 90% бюджета тратится на то, чтобы выразить на языке то, что на нем плохо выражается. Ради этого придумываются архитектуры, модели и прочая дребедень о которой говорит автор.

Отчасти согласен. Но не 90% времени.
(вспоминается паттерн "виртуальный конструктор")

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

VD>Если вы не доверяете тем, кто собирает сведения, то лучше их заменить, а не заставлять проверять их работу.

У тебя баги бывают ? Бывают. Почему не вижу от тебя призывов заменить VladD2 ?

Не бывает идеальных исполнителей.

VD>Ну,и в любом случае, если кто-то начинает выполнять эту работу, то он уже не программист, а в лучшем случае совместитель.

Правильно, SSE как правило больше чем программист.

I>>Или вопросов у тебя никогда не возникает ?

VD>Вопрос надо решать в рабочем порядке. Но не тратить же на это основное время?

А что значит в рабочем порядке ? Основное время это 8 часов в день. Оставаться после работы что ли ?

I>>Для некоторых контор дешевле научить программиста настраивать окружение(сервер, продукт и тд), для некоторых — дать в помощь админа, для некоторых — и целый отдел будет ненакладно.

VD>Все эти конторы тратят время зря. Правильный выход — автоматизация процесса кофигурирвоания и развертывания. Вот на это должны идти админские часы. Но первый тип контор (по твоей классификации) просто уроды закапывающие деньги в песок.

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

VD>Ага. Потому что тут двух мнений быть не может. Или процесс эффективне, или нет.
VD>Программист эффективно выполняет только одну задачу — разрабатывает ПО. Если он вынужден тратить время на договары или внедрение, то эффективность его труда будет низкой.

А почему ты решил, что во всех фирмах программист это самый критический участок процесса ?

VD>И совершенно не удивительно, что в конторе где программист тратит на код 10% времени, низка и общая эффективность. Это следствие неверной организации работы.

Конечно. Это хорошо объясняет положение #1 на рынке Общая эффективность слабо зависит от программиста. А вот например от качества работы маркетинга зависит крайне сильно.

VD>А у вас разработку ПО делает один человек? Если, нет, то наши позиции, возможно, сходятся. Фирма не должна посвящать разработке ПО 90% своего времени. Но программист (разработчик) обязан. Все что не посвящено непосредственно разработке — это накладные расходы. Без них, конечно же, никуда. Но оптимальный процесс разработки ПО — это процесс в котором такие накладные расходы минимизированы.

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

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

VD>И язык — это одно из важнейших средств снижения накладных расходов. Не единственное, конечно. Но очень важное. Просто парадокс Блаба не дает людям это понять. Ведь если тебе предложить писать код на ассемблере, то скорее всего ты рассмеешся в глаза и скажешь, что это глупо. Но менее очевидных случаях ты этого просто не замечаешь.

Снижение накладных расходов это одна из самых неэффективных оптимизаций.

VD>Если программист вынужден тратить свое время на ручное тестирование, домысливание тех-задания, ручное развертывание, и тем более, на заключение контрактов, то — это просто не эффективное его использование.

Появление Канбана в ПО однозначно доказывает что твой взгляд мягко говоря устарел.

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

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

VD>Не спорю. Но совмещение задач — это от бедности. И если уж кто-то совмещает задачи, то надо это и рассматривать как выполнение разной работы, и не говорить, что "программист тратит 90% не на программирование". Просто он же на 90% не программист.

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

VD>Но для нас важно не то, что он на Х% не программист, а то, что частенько, выполненяя обязанности программиста, такой совместитель выполняет работу которя вообще не несет никакой пользы. Например, тот же ручной деплоймент.

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

VD>Совмещение же обязанностей тоже вредно. Это я знаю по своей шкуре, так как от той же бедности, так же вынужден совмещать несколько профессий в своем лице. Но я не рад этому. Я понимаю, что это плохо, и что это от бедности.

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

I>>Решение бизнес задачи разумеется, а не генерация парсера.

VD>Это дагестанская точка зрения. Термин "бизнес-задача" не имеет отношения к решению "автоматизации бизнеса" в понимании которое принято у нас. "Бизнес" — это дело. Генерация парсеров такое же дело как и все остальные. Чтобы сгенерировать эффективный парсер, может понадобиться даже больше усилий, нежели для проектирования БД для сложной финансовой системы (как и наоборот).

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

VD>А я не об этом говорю. Программист обязан понимать что он делает. Тут нечего обсуждать. Но как это связано с временем затрачиваемым на разработку? Или мы учитываем в этом времени время на обучение прикладной области? Тогда давай еще и время на изучение программирования сюда приплетем.

Да, и время на обучение, и время на освоение технологий, инструментов и в т.ч..

I>>Другими словами есть разработка есть сложный процесс, который нужно оптимизировать с учетом всех факторов. И как то выходит, что девелопер здесь далеко не самый важный фактор
VD>Это полнейшая чушь. Единственное что делает разработчик — пишет код. Все остальное, неизбежные накладные расходы. И их нужно сокращать. Без подходящего языка — это невозможно.

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

VD>Разработка ПО конечно не конвейер, но это тоже инженерная дисциплина.

В ПО уже появился такой процесс разработки как конвейер

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

VD>Здравствуйте, Ведмедь, Вы писали:

В>>Если сюда добавить анализ требований, тестирование и внедрение, то от написания кода и останется 10-20 процентов времени.

VD>О, как? А написание тестов — это не написание кода?

В общем случае нет, конечно. автоматическими тестами к сожеланию все не покрывается. Да и собственно написание тестов это далеко не 100% времени тестирования. Более того, по хорошему автоматические тесты к коду должен писать не тот же человек, который пишет сам код. Что бы была точко рабочего конфликта.

VD>Сбор же требований и внедренеие — это не задачи программиста. Если у вас эти задачи решает программист, то вы заведомо используете его время не эффективно.

А кто сказал, что работа над программным продуктом это только работа прграммиста? А остальные так, покурить вышли?

VD>С тестами же все как с обычным кода. Чем гибче язык, тем лучше на нем можно автоматизировать тестирование.
VD>Ну, и на тесты не должно уходить более 20% времени разработки.

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

VD>Несомненно! Но работает в этом решении как раз таки код. А раз так, то все что не связанно с написанием кода — это не производтиельные расходы. И их нужно сокращать. Так?

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

В>> Красивый код — это средство, которое в общем случае помогает снизить издержки на только часть процесса производства программного продукта.

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

Не, все правильно. Я к тому, что красивый и правильный код сокращает издержки только на часть производственного процесса.

VD>И еще я не согласен с термином "красивый". Код, есть продукт. Он должен быть в качественным. Понятие качества, конечно, многостороннее, но все же выразимо.

Во! И оказывается, что достижение идеального кода это зло — достаточно просто кода нужного качества. Иначе слишком большие издержи и time to market.

В>>ЧТо бы написать код надо (грубо):

В>>1. Сделать предпроектное исследование, в рамках которого код не пишут, продаться

VD>Если код не пишут, то это не работа программиста. Хотя как раз разумно было бы код все же писать (прототипировать).

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

В>>2. Иметь заключенный контракт, в рамках которого будут куча документации, но ни строчки кода.

VD>Это уже точно не дело программиста. Хороший программист вам таких контрактов на заключает, что вы потом их толпой юристов не разгребете. Чтобы заключить грамотный договор, нужно знать законодательную базу, судебную практику и т.п., а не языки программирования и методы проектирования.

В>>2. Формализованные и понятные требования. ТОже без единой строчки кода

VD>Вот это уже дело программистов. И то скорее, в некоторых случаях, ее выполняют выделенные еденицы вроде архиеткров и т.п.

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

В>>После кодирования:

В>>1. тестирование.

VD>Без кодирования? Вы мышкой что ли свое ПО тестируете?

А что вы вообще без людей тестируете? И пользовательский интерфейс? И бак трекинга нет? И никто не "дравит" баги?

В>>2. Потом это все что накодировали надо установить и заставить взлететь.

VD>Это у вас тоже программисты делаю? Не, я согласен, тут нужно создать инсталлятор (если пользователей много), проестироват его, написать инструкцию, если надо. Но это не задача программиста. Или задача специально выделенного программиста-прикладника.

Опять же надо определеиться мы говорим про программиста только ии вообще про весь процесс

В>>3. закодировал — задокументруй за собой (РП, РА )

VD>А на этапе проектирования вы что делали? Или у вас получившееся решение отличается от исходного?

Ну во первых конечное решение решение может отличаться. Во вторых на этапе проектирования все детали прописывать слишком дорого. Более того на этапе на этапе сбора требований, например получается ответ на вопрос "что надо", а после кодирования видно "как это работает". Детальная информация о настройке системы доступна только после кодирования. А РП вообще пишется в другом ключе — с точки зрения обучения операторов. Как бы не дело это делать на этапе проектирования

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

В>>4. Теперь все это надо СДАТЬ

VD>О, как? А это тоже программист делает?

В>>Так что поддержу утверждение, что на код тратиться меньшая часть времени. Просто разработчикам в основном она и видна

VD>Ребята, да у вас какая-то каша получается. Вы смешиваете несколько видов деятельности и на этом основании говорите, что разработка не является основным видом деятельности. Но это всего лишь разные виды деятельности. В конторах где есть более 4 человек она должна выполнятся разными людьми. А программист должен:
VD>1. Проектировать.
VD>2. Кодировать.
VD>3. Писать и прогонять тесты.
VD>4. Отлаживать и исправлять ошибки.

VD>Все это процессы непосредственно связанные с кодом. В любой из фаз, программист пишет, читает или думает о коде.

В>>И кстати , если кодирование начинает занимать в процессе слишком много времени, то одно из двух:
В>>1. Слишком мало времени уделяется другим фазам

VD>Ага. Заключению договров и внедрению .

В>>(скорее всего страдает тестирование или сбор требований — соответственно или много багов доходит до заказчика или заказчик получает не то что хотел ).

VD>И что, много багов не относится к коду? Халтурно писали код, получите море отладки. Уделяйте больше времени и внимания качеству написания кода, и получите меньше отладки. А лучше повышайте уровень кода, и уровень его контроля.

Достаточно много багов относится не к коду — например к требованиям.

В>>2. Сликом много не поддерживаемого кода — большая стоимость внесения изменений.

VD>А это тоже от кода не зависит?

VD>Ну, да если плевать на код и не считать его главным, а потом обосновывать баги тем, что код — это не главное, то конечно можно и до такого абсурда договориться.

При чем тут плевать на код? Просто считать код главным тоже заблуждение. Это все равно что считать, что самый главный на стройке тот кто кладет кирпичную стену.

В>>Не правда, было сказано, что 90% занимает не код И это время не впустую проходит. Это кодить без это работы — впустую выкинутое время — все равно придется перекодировать.

VD>Совершенно без различно как тратить время в пустую. Можно 90% "кодить" и получить никому не нужный бред или багодром, а можно 90% дизайнить и получить еще худший результат. Время все равно будет потеряно.

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

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

VD>Нормальным решением этой проблемы было бы введение типа Tuple,

...что мало отличается от массива из 2 элементов. Напомню, рассматриваемая альтернатива — MyFunctionCallResult class.

>или смена языка на язык поддерживающий кортежи.

На практике смена языка — нереальное решение для grunt'ов.

VD>Я бы выбрал четвертый вариант — оставил бы у функции один параметр и сделал бы его битовой маской описанной перечислением.

То есть, ввели бы новый тип. Это и есть злоупотребление типами. Я особо оговорил в комментарии, что это не API, а кишки объектной модели. То есть, отдельная частная имплементация одной функции. Стоит ли заводить enum? Более того, если уж все-таки создавать enum'ы, то по одному на каждый параметр, ибо смешивать несвязанные параметры в одном перечислении никак нельзя.

VD>ЗЫ
VD>Названия параметров порадовали.

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

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

VD>>Сбор же требований и внедренеие — это не задачи программиста. Если у вас эти задачи решает программист, то вы заведомо используете его время не эффективно.
В>А кто сказал, что работа над программным продуктом это только работа прграммиста? А остальные так, покурить вышли?

Да какая разница чем остальные занимаются?
Нет, я понимаю, что самая главная в мире профессия — маркетолога-продажника, но разговор вроде же немного не об этом.

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

Ф>Отчасти согласен. Но не 90% времени.
Ф>(вспоминается паттерн "виртуальный конструктор")

Ну, процент обсуждается . Потом он, конечно же, разный в разных случаях.

Я то отвечал на реплику "от языка ничего не зависит, так как 90% времени тратится не на программирование". На это я и ответил, что а) вы тратите силы программистов не эффективно; б) подходящий язык сокращает не только время на кодирование, но и на проектирование, и отладку.

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

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

VD>>Если вы не доверяете тем, кто собирает сведения, то лучше их заменить, а не заставлять проверять их работу.

I>У тебя баги бывают ?

Бывают.

I>Почему не вижу от тебя призывов заменить VladD2 ?

Потому что я себе доверяю. Если есть баг и я знаю о нем, то поправлю.

I>Не бывает идеальных исполнителей.

Не бывает. Но это не оправдание чтобы заниматься не своим делом.

VD>>Ну,и в любом случае, если кто-то начинает выполнять эту работу, то он уже не программист, а в лучшем случае совместитель.

I>Правильно, SSE как правило больше чем программист.

Это по фигу. Больше или меньше тут не применимы. Он не программист и потому говорить о том, сколько он тратит время на программирования не имеет смысла.

I>>>Для некоторых контор дешевле научить программиста настраивать окружение(сервер, продукт и тд), для некоторых — дать в помощь админа, для некоторых — и целый отдел будет ненакладно.

VD>>Все эти конторы тратят время зря. Правильный выход — автоматизация процесса кофигурирвоания и развертывания. Вот на это должны идти админские часы. Но первый тип контор (по твоей классификации) просто уроды закапывающие деньги в песок.

I>Ну ты в курсе, оптимизация должна быть mature

Какая на фиг оптимизация? Я сказал "автоматизация".

I>Конторы ничего не закапывают. Оптимизировать такие расходы нужно в том случае, если они становятся критическим местом.

А если они не критичны, то о них и говорить не стоит. Но раз у вас 90% времени программиста уходит на черт знает что (вроде развертывания софта), то они точно критичны и их нужно автоматизировать.

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

VD>>Ага. Потому что тут двух мнений быть не может. Или процесс эффективне, или нет.
VD>>Программист эффективно выполняет только одну задачу — разрабатывает ПО. Если он вынужден тратить время на договары или внедрение, то эффективность его труда будет низкой.

I>А почему ты решил, что во всех фирмах программист это самый критический участок процесса ?

Я так не решал. Но мы говорим о программисте. Так что не надо сюда приплетать черт знает что.
Если в вашей фирме основные трудозатраты — это навешивание лапши на уши клиентов, то это всего лишь значит, что основной деятельностью вашей фирмы не является разработка ПО. Но если у вас есть программист, то его основной задачей, все равно, остается написание кода. А если он делает что-то еще, то он а) не программист; б) априори неэффективен (так как совмещение всегда снижает эффективность).

VD>>И совершенно не удивительно, что в конторе где программист тратит на код 10% времени, низка и общая эффективность. Это следствие неверной организации работы.

I>Конечно. Это хорошо объясняет положение #1 на рынке Общая эффективность слабо зависит от программиста. А вот например от качества работы маркетинга зависит крайне сильно.

VD>>А у вас разработку ПО делает один человек? Если, нет, то наши позиции, возможно, сходятся. Фирма не должна посвящать разработке ПО 90% своего времени. Но программист (разработчик) обязан. Все что не посвящено непосредственно разработке — это накладные расходы. Без них, конечно же, никуда. Но оптимальный процесс разработки ПО — это процесс в котором такие накладные расходы минимизированы.

I>Оптимальный это процесс это такой, который позволяет максимально эффективно достигать цели. Минимизация издержек о которой ты говоришь это каменный век, путь в никуда.

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

VD>>И язык — это одно из важнейших средств снижения накладных расходов. Не единственное, конечно. Но очень важное. Просто парадокс Блаба не дает людям это понять. Ведь если тебе предложить писать код на ассемблере, то скорее всего ты рассмеешся в глаза и скажешь, что это глупо. Но менее очевидных случаях ты этого просто не замечаешь.

I>Снижение накладных расходов это одна из самых неэффективных оптимизаций.

VD>>Если программист вынужден тратить свое время на ручное тестирование, домысливание тех-задания, ручное развертывание, и тем более, на заключение контрактов, то — это просто не эффективное его использование.

I>Появление Канбана в ПО однозначно доказывает что твой взгляд мягко говоря устарел.

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

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

VD>>Не спорю. Но совмещение задач — это от бедности. И если уж кто-то совмещает задачи, то надо это и рассматривать как выполнение разной работы, и не говорить, что "программист тратит 90% не на программирование". Просто он же на 90% не программист.

I>Термин программист на нынешний день устарел.

VD>>Но для нас важно не то, что он на Х% не программист, а то, что частенько, выполненяя обязанности программиста, такой совместитель выполняет работу которя вообще не несет никакой пользы. Например, тот же ручной деплоймент.

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

VD>>Совмещение же обязанностей тоже вредно. Это я знаю по своей шкуре, так как от той же бедности, так же вынужден совмещать несколько профессий в своем лице. Но я не рад этому. Я понимаю, что это плохо, и что это от бедности.

I>Самый ценный опыт я получал в то время, когда совмещал обязанности. То есть, дело сводится к тому, как извлечь из этого пользу. Если мне нужно кликать в UI неделю-другую, я четко понимаю, что это за польза лично для меня и для конторы. Контора прибегает к такому способу когда тестирование становится критическим участком — больше кликов, больше фиксов. Для меня такой этап заканчивается четким представлением что не так с программой с т.з. пользователя.

I>>>Решение бизнес задачи разумеется, а не генерация парсера.

VD>>Это дагестанская точка зрения. Термин "бизнес-задача" не имеет отношения к решению "автоматизации бизнеса" в понимании которое принято у нас. "Бизнес" — это дело. Генерация парсеров такое же дело как и все остальные. Чтобы сгенерировать эффективный парсер, может понадобиться даже больше усилий, нежели для проектирования БД для сложной финансовой системы (как и наоборот).

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

VD>>А я не об этом говорю. Программист обязан понимать что он делает. Тут нечего обсуждать. Но как это связано с временем затрачиваемым на разработку? Или мы учитываем в этом времени время на обучение прикладной области? Тогда давай еще и время на изучение программирования сюда приплетем.

I>Да, и время на обучение, и время на освоение технологий, инструментов и в т.ч..

I>>>Другими словами есть разработка есть сложный процесс, который нужно оптимизировать с учетом всех факторов. И как то выходит, что девелопер здесь далеко не самый важный фактор
VD>>Это полнейшая чушь. Единственное что делает разработчик — пишет код. Все остальное, неизбежные накладные расходы. И их нужно сокращать. Без подходящего языка — это невозможно.

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

VD>>Разработка ПО конечно не конвейер, но это тоже инженерная дисциплина.

I>В ПО уже появился такой процесс разработки как конвейер

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

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

VD>>Здравствуйте, Ведмедь, Вы писали:

В>>>Если сюда добавить анализ требований, тестирование и внедрение, то от написания кода и останется 10-20 процентов времени.

VD>>О, как? А написание тестов — это не написание кода?

В>В общем случае нет, конечно.

Ну, тогда вам придется признать, что ваш процесс разработки далек от эффективности.

В>автоматическими тестами к сожеланию все не покрывается.

Это почему это? Разве что ГУИ трудно автоматизировать. Но те у кого его много и это делают.

В>Да и собственно написание тестов это далеко не 100% времени тестирования.

О, как? А что же еще такое трудозатратное вы делаете? Разрабатываете архитектуру тестирования? Проводите консилиумы?

Я знаю два вида тесто. Один закрепляет реализованный функционал. Другой закрепляет исправленный баг, что по сути вариация первого случая. Что же еще с ними можно делать?

В>Более того, по хорошему автоматические тесты к коду должен писать не тот же человек, который пишет сам код.

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

В>Что бы была точко рабочего конфликта.

Вот это что-то очень сложное. Им бы не конфликтовать, а работать в паре.

VD>>Сбор же требований и внедренеие — это не задачи программиста. Если у вас эти задачи решает программист, то вы заведомо используете его время не эффективно.

В>А кто сказал, что работа над программным продуктом это только работа прграммиста? А остальные так, покурить вышли?

Остальные нас не колышат. Мы обсуждали вопрос эффективности программистов. ПО — это код и документация. Остальное — это уже не разработка ПО.

VD>>Несомненно! Но работает в этом решении как раз таки код. А раз так, то все что не связанно с написанием кода — это не производтиельные расходы. И их нужно сокращать. Так?

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

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

В>Не, все правильно. Я к тому, что красивый и правильный код сокращает издержки только на часть производственного процесса.

Это заблуждение. Когда-нибудь, возможно, ты поймешь это.

В>Во! И оказывается, что достижение идеального кода это зло

Чушь какая-те. Причем тут идеал?

В>- достаточно просто кода нужного качества. Иначе слишком большие издержи и time to market.

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

В>Эм... чую все таки надо определиться, мы говорим о проценте кодирования вообще в производстве продукта или процент времени(трудоемкости, стоимости) кодирования только прграммиста?

Конечно программиста. Процент труда бухгалтера нас вообще не трогает. Язык то бухгалтер не использует.

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