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

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

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

В статически-типизированном то языке?

Просто это грамотное обобщение. Но в каком-нибудь Обероне это просто невозможно сделать, например.

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

Словарь мне сказал, что grunt — это "хрюканье", "ворчанье", "мычание", т.е. какие-то животные.

SV.>То есть, ввели бы новый тип.

Ну, да. У меня по этому поводу пунктиков нет. Если так для дела лучше, то почему бы не ввести?

SV.>Это и есть злоупотребление типами.

Злоупотребление — это значения свойств в классы запихивать. А ввести тип для описания состояния — это совершенно нормально.

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

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

SV.>Более того, если уж все-таки создавать enum'ы, то по одному на каждый параметр, ибо смешивать несвязанные параметры в одном перечислении никак нельзя.

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

Орел привел конкретный метод где значения были НеРаком, Боком, Наскоком. Все часть одного состояния. Ну, так на фиг мне его по параметрам разбивать?

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

Может быть. Что говорит об авторе примера, но не как не об обсуждаемой проблеме.

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

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

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

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

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

Нет в мире совершенства. Но свести тестирование только к написанию кода тестов это еще дальше от эффективности. Поговорите с любым грамотным QA инженером на эту тему.

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

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

Именно что UI. И оно автоматизируется. НО не все и трудоемко. А заказчику плевать, что у вас прекрасно работает внутренние функции, если в интерфейсе он видит какую то гадость.

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А тестер? А аналитик? А архитектор? А ПМ? А технический писатель? А тех. саппорт? Они не участвуют в производстве программного продукта?

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

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

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


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

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

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

VD>Словарь мне сказал, что grunt — это "хрюканье", "ворчанье", "мычание", т.е. какие-то животные.

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

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

В>Нет в мире совершенства. Но свести тестирование только к написанию кода тестов это еще дальше от эффективности. Поговорите с любым грамотным QA инженером на эту тему.

Да говорил. Они так и делают.

В>Именно что UI. И оно автоматизируется. НО не все и трудоемко. А заказчику плевать, что у вас прекрасно работает внутренние функции, если в интерфейсе он видит какую то гадость.

Конечно! Если это так, то у вас тесты плохие. Ну, или это единичный случай которым можно пренебречь.

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

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

ОТ, ОНО! Эта статья как раз об этом. Читайте ее внимательнее .

В>2. Локализация бага (источник бага живет чаще всего не там где его обнаружили)

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

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

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

В>А баги настройки? Ведь бывает такое, что код верный, но криво настроен.

Отличная тема! Это к вопросу о автоматическом деплойменте и качестве используемого языка.
Если деплоймент автоматический, а язык не требует подпорок вроде разных Струтсов и прочих IoC-ов, то и проблемы этой не возникнет никогда.

В>Или все, раз код написан и выполняется в тестовой среде, то дальше жизнь заканчивается?

Мы снова вернулись к багам? Или речь снова о ручном развертывании с ошибками?

В>Это очень простое — что бы не было стимула сговариваться

Сговариваться о чем? Им же обоим нужно рабочее ПО сдать.

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

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

В> Нужен высокий уровень самодисциплины и квалификации что бы честно прописать тесты самому себе.

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

В>Так мы говорим про эффективность программиста или про эффективность разработки ПО?

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

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

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

В>Вы знаете, что разработчики больших систем практически не боятся кражи исходников?

Нет. Не знаю. И вижу обратные факты. Как и вижу примеры когда кражи исходников не боятся разработчики мелких программ. Это зависит от множеств факторов. В том числе от психологии.

Вы хотите поговорить о психологии?

В> ДАже с документацией? Потому что эти исходники и документация без людей и процесса ни шиша не стоят.

Это зависит. Дай мне исходники системы защиты и ты очень облегчишь мне ее вскрытие.

В>Вы под разработку ПО с кодированием не путаете?

Нет.

В>Написать 1000 строк кода, пусть даже и работающего это не разработка ПО. Нужен код, который делает то что от него требуется.

Ага. Но написание 10 строк в месяц нельзя оправдать ничем. Особенно тем, что в разработке ПО код не главное. В прочем, это по любому чушь.

В>Я не говорил про неважность кода.

Тогда о чем мы спорим? Ты влез в спор между тем, кто утверждал, что язык не важен, так как не важен. Мол они чем-то другим занимается вместо разработки.

В> Я говорил что остальные аспекты не менее важны. Нельзя утверждать, что код это самая важная часть разработки ПО.

Много важного есть в жизни. Я не ставлю это под сомнение. Но в разработке ПО код — это главное. И он не может быть не важен.

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

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

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

В>А тестер?

А тестер, если он дело делает, а не мышью в монитор тычет, тоже программист.

В> А аналитик?

А он что делает то?

В>А архитектор?

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

В>А ПМ?

ПМ? Он бухгалтер. Его задача проверять кто что сделал и задания раздавать. Но он хотя бы делом занят.

Потом ПМ он один на проект. И он точно не может оцениваться в 90% времени.

В> А технический писатель?

А бухгалтер?

А уборщица?

А вахтер?

В>А тех. саппорт?

А секретарша?

В>Они не участвуют в производстве программного продукта?

Нет. Они выполняют свою работу. Связанную с разработкой, но не разработку.

У нас вопрос был один. Важен выбор языка в разработке ПО или нет. Мне сказали не важен. Я не поверил. Вахтеры и техрайтеры тут ничего не доказывают.

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

В>Все наоборот. Если фирма тратит много на кодирование, то что то там не ладно

Почему не ладно?

В> — за последение 10-15 лет эффективность кодирования за счет новых технологий, языков, библиотек и т.д. выросла на порядок, если не больше.

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

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

Это каких, позвольте узнать?

В>Так что доля кодирования в производстве программного продукта упала.

Гы-гы. Это эффективность создания ПО упала. Когда ПО делали отдельные индивидуумы, то их КПД было Х, а когда этим занялись большие конторы, то оно стало падать.

В>Вы наверное просто не участвовали в серьезных внедрениях.

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

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

Хреново работаете. Что еще можно сказать.

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

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

I>>У тебя баги бывают ?
VD>Бывают.
I>>Почему не вижу от тебя призывов заменить VladD2 ?
VD>Потому что я себе доверяю. Если есть баг и я знаю о нем, то поправлю.

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

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

Перечень обязанностей у разработчика уже совсем не тот что 10-15 лет назад.

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

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

I>>Ну ты в курсе, оптимизация должна быть mature
VD>Какая на фиг оптимизация? Я сказал "автоматизация".

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

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

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

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

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

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

Программист это слишком общий термин. Безопасника, админа тоже можно считать программистами. А вот software enginer уже совсем другие обязанности и одним только программированием не ограничиваются.

SSE, т.е. senior softare enginer или senior softare developer обязательно должны уметь работать с требованиями, уметь формулировать, проверять, руководить девелоперами попроще и много чего другого.

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

Давай проверим. Я работаю в фирме которая нумер 1 в своём бизнесе и конкуренты это гиганты вроде AT&T и наш продукт это наш софт. Твой ход Готов выслушать твой рассказ почему грамотная организация разработки не вывела твою фирму в лидеры хотя бы в России.

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

В>>Нет в мире совершенства. Но свести тестирование только к написанию кода тестов это еще дальше от эффективности. Поговорите с любым грамотным QA инженером на эту тему.

VD>Да говорил. Они так и делают.

Значит ты не тех набрал Всегда есть тонны нюансов.С одной тсороны есть большие плюсы, когда тестеры чуть-чуть девелоперы, они могут лазить по коду и выискивать скользкие места. С другой стороны, есть плюсы когда обязанности сильно разделены. Тем не менее свести всё к написанию тестов не получится по той причине что цели пользователя нельзя на 100% покрыть тестами.

В>>Именно что UI. И оно автоматизируется. НО не все и трудоемко. А заказчику плевать, что у вас прекрасно работает внутренние функции, если в интерфейсе он видит какую то гадость.

VD>Конечно! Если это так, то у вас тесты плохие. Ну, или это единичный случай которым можно пренебречь.

Свести особенности человеческой психологии к набору тестов это сильно. Почему ты до сих пор нобелевку не получил ? Ай да ПерельманVladD2.

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

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

VD>Если деплоймент автоматический, а язык не требует подпорок вроде разных Струтсов и прочих IoC-ов, то и проблемы этой не возникнет никогда.

Струтсы и ИоКи растут не из языка а из обязанностей-зависимостей. Как только проект разрастается до определенного уровня он гарантировано превращается в монолит и сопротивляется рефакторингу и язык здесь при при чем. Причины находятся в человеческой психике

Пример, который ты сам и привеёл, — компилятор Немерле. Было бы всё так просто, как ты рассказал, не было бы твоих постов про монолит и сложности рефакторинга.

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

Хочешь сказать, что app.config и web.config ты редактируешь раз в год ? Я в это не поверю Работая с asp.net или wcf туда надо лазить дённо и нощно.

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

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

VD>Много важного есть в жизни. Я не ставлю это под сомнение. Но в разработке ПО код — это главное. И он не может быть не важен.

Если код важен, то это не значит, что код важно писать 90% времени см пример выше.

VD>Очень часто люди тратят много времени на модели и прочий высокопарный бред (о котором и говорится в статье) только потому, что используемый язык так далек от предметной обрасли, что высказывание одного слова из предметной области на выбранном языке выливается в создание целых иерархий классов.

Допустим. Вот нужен мне мега-ДСЛ вроде linq но с моей спецификой. Смотрю я твои мессаги и вижу, что даже linq задээсэлить у тебя не выходит, потому что запятые не так используются. Как быть ?
В такой ситуации embedded lang + resharper далеко не факт что уступят ...(ой!) да с отказом от совместимости уже во второй версии

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

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

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

Ты попутал язык и речь Задача сложная == речь не прокачана. Мощный язык это нисколько не компенсирует. Речь осваивают десятками лет а не переходом на новый компилятор.

В>> А аналитик?
VD>А он что делает то?

Собирает требования в кучку и контролирует их качество. Примерно так.

В>>А архитектор?

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

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

В>>А ПМ?

VD>ПМ? Он бухгалтер. Его задача проверять кто что сделал и задания раздавать. Но он хотя бы делом занят.

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

В>>Все наоборот. Если фирма тратит много на кодирование, то что то там не ладно

VD>Почему не ладно?

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

Т.е. если фирма в основном кодит, то скорее всего движется непойми куда, а выхлопа от топ-менеджмента и маркетинга нет вовсе. Ты в курсе, что маркетинг это множитель ? 90% времени на маркетинг, это значит, грубо говоря, что эффект 1 программиста увеличивается в 9 раз.

VD>Это заблуждение. Эффективность мэйнстрим-программиста поднялась совсем незначительно.

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

VD>Реально прорывом был переход к языка высокого уровня от ассемблеров.

Менеджед и сопутствующие инструменты это

VD>Кое-что конечно сдвинулось и после, но трудоемкость разработки ПО до сих пор запредельная. Техрайтер может наклепать 10 страниц текстов за день. А программист 10 строк работающего кода.

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

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

VD>Хреново работаете. Что еще можно сказать.

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

VD>Потом на заказных системах клин светом сошелся что ли? В коробке фаза выявления требований вообще отсутствует в чистом виде.

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

>Пользователи просят фич и их включают в следующие релизы. А вот на проектирование, написание кода и тестирование уходит основное время.

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

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

H>Сразу видно, что ты не играл в Z (там так базовый юнит назывался)
H>Вот тебе ссылка на правильный словарь. Grunt — это пехотинец.

А зачем мне играть в малоизвестную игрушку?

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

Сори времени на обсуждение полезности траты рабочего времени нет. Работать надо.
Отвечу только вот на это:

I>Хочешь сказать, что app.config и web.config ты редактируешь раз в год ? Я в это не поверю Работая с asp.net или wcf туда надо лазить дённо и нощно.

Так не используйте эти asp.net или wcf, если они вам работать мешают. "wcf" — это банальный овердизайн. Для организации RPC в Интернете достаточно REST-а. Наклепать для него фрэймворк или макру труда не составляет (или даже готовый взять). Так зачем грызть этот кактус?

Зачем править app.config и web.config я тоже не представляю. Нужная конфигурация должна лежать в репозитории. Если что-то нужно настраивать под конкретную машину, то нужно писать скрипты автоматизирующие эти настройки.

Но ручного труда быть не должно. Руками мы должны писать код.

Неужели такая простая мысль может вызвать непонимание?

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


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

VD>б) априори неэффективен (так как совмещение всегда снижает эффективность).
вот скажи, текст ты сам набираешь или машинистку заставляешь?
это я к тому что утверждение "совмещение всегда снижает эффективность" н верно так как разделение труда тянет за собой взаимодействие, которое может стать узким местом.

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

I>>Хочешь сказать, что app.config и web.config ты редактируешь раз в год ? Я в это не поверю Работая с asp.net или wcf туда надо лазить дённо и нощно.

VD>Так не используйте эти asp.net или wcf, если они вам работать мешают. "wcf" — это банальный овердизайн. Для организации RPC в Интернете достаточно REST-а.

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

>Наклепать для него фрэймворк или макру труда не составляет (или даже готовый взять). Так зачем грызть этот кактус?

Придется выписывать весь стек технологий. Может еще и поисковик вроде гугла написать самому ?

VD>Зачем править app.config и web.config я тоже не представляю. Нужная конфигурация должна лежать в репозитории. Если что-то нужно настраивать под конкретную машину, то нужно писать скрипты автоматизирующие эти настройки.

.net так устроен. прикручиваешь логгер, надо править конфиг, прикручиваешь бд — надо править конфиг. Лезешь в инет — все в конфиге. К тебе лезут из инета — опять конфиг. Куда ни ткни вылазит этот конфиг.

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

Ты ни много ни мало предложил выписывать велосипеды для всего на свете.

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

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

Сделай переходник. Но не трахаться с WCF сделав его основной интерфейсной библиотекой.

Да и что это за чудные сервисы? Где вы их берете? Весь цивилизованный мир в последнее время клепает сервисы в REST-стиле. Публичные сервисы в формате Soap делают только люди с полным майрософтом головного мозга.

>>Наклепать для него фрэймворк или макру труда не составляет (или даже готовый взять). Так зачем грызть этот кактус?

I>Придется выписывать весь стек технологий. Может еще и поисковик вроде гугла написать самому ?

У гугла используется Soap? О, как! А мужики из гугля и не знали!
Вот, все что я смог найти по запросу "Soap google".

Так что google — это отличный аргумент! Ты еще Яндекс в пример приведи .

WCF и Soap — overdesign. Они не для жизни сделаны, а для галочки. А разные дуболомы используют их, чем портят жизнь себе и окружающим.

VD>>Зачем править app.config и web.config я тоже не представляю. Нужная конфигурация должна лежать в репозитории. Если что-то нужно настраивать под конкретную машину, то нужно писать скрипты автоматизирующие эти настройки.

I>.net так устроен.

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

I>прикручиваешь логгер,

А у меня вот, с логером проблем нет.

I>надо править конфиг,

Не забывай добавлять — "тебе надо".

I>прикручиваешь бд — надо править конфиг.

Что за прикручиваешь? В прочем, кури вот это.

I>Лезешь в инет — все в конфиге.

Ну, дык. Можно проще сказать. Используешь каменный молоток — программируешь в ХМЛ-е.

I>К тебе лезут из инета — опять конфиг. Куда ни ткни вылазит этот конфиг.

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

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

I>Ты ни много ни мало предложил выписывать велосипеды для всего на свете.

Лучше уж велосипеды, чем используемые тобой самокаты.

К тому же, эти велосипеды пишутся, в основном, поверх ваших же самокатов.

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

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

VD>Сделай переходник. Но не трахаться с WCF сделав его основной интерфейсной библиотекой.

Никто и не трахается. ВЦФ это уже практически стандарт.

VD>Да и что это за чудные сервисы? Где вы их берете? Весь цивилизованный мир в последнее время клепает сервисы в REST-стиле. Публичные сервисы в формате Soap делают только люди с полным майрософтом головного мозга.

Ну иди да авторитетно объясни, а то до сих пор люди до хрипа спорят что лучше, соап и рест

I>>Придется выписывать весь стек технологий. Может еще и поисковик вроде гугла написать самому ?

VD>У гугла используется Soap? О, как! А мужики из гугля и не знали!

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

VD>WCF и Soap — overdesign. Они не для жизни сделаны, а для галочки. А разные дуболомы используют их, чем портят жизнь себе и окружающим.

Это уже практически стандарт.

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

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

I>>надо править конфиг,
VD>Не забывай добавлять — "тебе надо".

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

I>>прикручиваешь бд — надо править конфиг.

VD>Что за прикручиваешь? В прочем, кури вот это.

Это просто поделка. До ЕФ ей как до небес.

VD>Ну, дык. Можно проще сказать. Используешь каменный молоток — программируешь в ХМЛ-е.

Как без конфига сменить прокси после запуска приложения в котором нет УИ ?

I>>К тебе лезут из инета — опять конфиг. Куда ни ткни вылазит этот конфиг.

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

Твои велосипеды требуют на порядок больше времени.

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

Я люблю использовать готовое, которое работает, протестировано и развивается, а не ломает совместимость уже ко второй версии.

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

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

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

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


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

VD>>б) априори неэффективен (так как совмещение всегда снижает эффективность).
C>вот скажи, текст ты сам набираешь или машинистку заставляешь?
Я когда был лид программистом, писал только интерфейсы и узкие места, другую часть (95% кода) писали "машинистки"

C>это я к тому что утверждение "совмещение всегда снижает эффективность" н верно так как разделение труда тянет за собой взаимодействие, которое может стать узким местом.
+100500, это кстати во многих бюрократических компаний убивает весь творческий процесс.
Но мне кажется по совмещению тут имеется немного другое, помнится мне выражение — что программист подобен жонглеру. Переключение на другой род занятий ведет к "пересетапу переменных окружений" а это накладные расходы.
Но заметь это только временый период — разделить. То что некоторые люди будут делать 2-3 смежных действия это одно, главное тут в том что ты будешь видеть кубики для оптимизации всего процесса.

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

З.Ы. Эта технология сейчас была проверена на западной компании — стока радости я не слышал от их дизайнеров и художников, одним словом — "Awesome!!!"
Поэтому теперь как только я вижу — комуникацию людей, работа не по должности, и тд, у меня начинается алергия

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

E>нуб — всего-навсего "новичек", негативного окраса вроде бы нет. Или я не прав?

"newbie" еще можно охарактеризовать как указание на новичка без негативного окраса, но "n00b" — это уже негативная окраска. Не то, что бы какое-то оскорбление, но тем не менее.

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

C>>вот скажи, текст ты сам набираешь или машинистку заставляешь?
IRO>Я когда был лид программистом, писал только интерфейсы и узкие места, другую часть (95% кода) писали "машинистки"
понятно. не хочеш разговора по существу так и скажи

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

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

C>>>вот скажи, текст ты сам набираешь или машинистку заставляешь?
IRO>>Я когда был лид программистом, писал только интерфейсы и узкие места, другую часть (95% кода) писали "машинистки"
C>понятно. не хочеш разговора по существу так и скажи
Вроде бы я ответил — заставляю машинистку, или мы так, по троллить?

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

C>>>>вот скажи, текст ты сам набираешь или машинистку заставляешь?
IRO>>>Я когда был лид программистом, писал только интерфейсы и узкие места, другую часть (95% кода) писали "машинистки"
C>>понятно. не хочеш разговора по существу так и скажи
IRO>Вроде бы я ответил — заставляю машинистку, или мы так, по троллить?
ну и кто тут после этого ответа тролит?

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

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

C>>>>>вот скажи, текст ты сам набираешь или машинистку заставляешь?
IRO>>>>Я когда был лид программистом, писал только интерфейсы и узкие места, другую часть (95% кода) писали "машинистки"
C>>>понятно. не хочеш разговора по существу так и скажи
IRO>>Вроде бы я ответил — заставляю машинистку, или мы так, по троллить?
C>ну и кто тут после этого ответа тролит?
как же задолбали эти тролли, все лучшего! пока!

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

VD>Сделай переходник. Но не трахаться с WCF сделав его основной интерфейсной библиотекой.

WCF прекрасно подходит и для RESTful сервисов.

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

VD>>Сделай переходник. Но не трахаться с WCF сделав его основной интерфейсной библиотекой.

AVK>WCF прекрасно подходит и для RESTful сервисов.

Ну, тебе виднее. Только не очень ясно на фиг он REST-а нужен? Плюс почему сразу full? Жить надо по обстоятельствам .