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

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

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

E>, и есть ли он вообще . Я ж того — в архитекторы мечу

В которые не кодят?

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

AK>Кто как считает, какие в области разработки ПО самые большие проблемы?

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

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

AVK>В которые не кодят?
Которые кодят, причем как ключевае части системы, так и первыми показывают, как в рамках того, что они наархитектурили, жить. Которые делают Code Review, определяют стандарты кодирования (личным примером, а не бумажкой, которую никто не читает и никто не следует). Которые определяют, какие скилы нужны для сотрудников, и которые учавствуют в наборе персонала (а то наберут индусов, за которыми только и будешь что код чистить). На которых держится проект, и когда команда знает, чем же занимается архитектор в данный момент. И которые гораздо более оплачиваемые, чем менеджеры и аналитики.

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

L_L>где-то кто-то сказал — "пиши так, чтобы ..."

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

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

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

Геннадий Васильев пишет:

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


Да, это верно. Причём понаписано куча книг по планированию разработки ПО,
но все читают, видимо, только до предложения типа "Очень важно планировать
разработку", а про то, что "ничего страшного, если при планировании вы
ошиблисть в 10 раз в меньшую или большую сторону, главное -- перепланировать
с учётом новых оценок" почему-то никто не дочитывает.

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

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

E>Которые кодят, причем как ключевае части системы, так и первыми показывают, как в рамках того, что они наархитектурили, жить. Которые делают Code Review, определяют стандарты кодирования (личным примером, а не бумажкой, которую никто не читает и никто не следует). Которые определяют, какие скилы нужны для сотрудников, и которые учавствуют в наборе персонала (а то наберут индусов, за которыми только и будешь что код чистить). На которых держится проект, и когда команда знает, чем же занимается архитектор в данный момент.

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

E> И которые гораздо более оплачиваемые, чем менеджеры и аналитики.

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

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

EC>А что бы ты спросил для проверки скиллов в дизайне?
Простенькое задание вида набросать дизайн классов на бумажке. По тем задачам, которые приходилось решать мне. То есть формулировал бы проблему, с которой встречался сам, текущие ограничения, и спросил как бы кандидат эту проблему решил, про то, что предполагается какой-то дизайн сделать тоже бы не говорил (так как на практике есть проблема — про то, что ее с целью экономии времени надо решать обобщенно, никто не говорит на практике). После написания решения поспрашивал бы почему сделали именно так, а не иначе, возможно бы предложил свое решение, предложив найти в нем проблемные места, и спросив, как можно сделать лучше. Ну и после решения изменил бы исходные допущения в том же стиле, как любит делать заказчик, посмотрел, возможно ли будет относительно безопасно изменить дизайн на уже работающем проекте, или придется изменения отклонить, сказав, что это будет стоить вам миллион долларов . Цель преследовал бы двойную — кроме проверки кандидата есть надежда услышать то, чего не знаю сам, надеялся бы, что и кандидату тоже что-то извлечет из интервью даже при неблагоприятном для него исходе . Но уж знания определения конкретных паттернов бы точно не спрашивал. В других областях, специальностях, насколько я знаю — все вопросы задают максимально приближенными к реальности, ИМХО имеет смысл перенимать опыт.

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

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

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

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

AVK>>Ну, надо иметь очень хорошее резюме, чтобы попасть на такую должность со старта.
E>Угу. Вот только хотелось бы, чтобы такая должность была

Они есть

E>В теории — уход ключевого архитектора может оказаться пагубным для проекта

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

E>, как результат, есть 2 варианта — либо платить ему нормальную для его уровня зарплату

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

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

E>уход ключевого архитектора может оказаться пагубным для проекта

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

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

AK>Так все же — наличие или отсутствие? Их не хватает, или наоборот, они есть и все портят?

Видимо и то и другое. Когда программистов нет — ничего не делается потому, что некому. А когда программисты есть — они все портят.

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

E>В теории — уход ключевого архитектора может оказаться пагубным для проекта

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

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

E>В теории — уход ключевого архитектора может оказаться пагубным для проекта, [...]

Это ты где такую теорию нашёл, мистер мечтатель?

Взаимопонивание:
— заказчик не может объяснить программистам, чего он хочет (иногда по причине собственного непонимания, чего он хочет)
— программисты не способны (или нет возможности) объяснить/убедить заказчика(или вышестоящего менеджера), что то что от них хотят — не реально/не практично/не будет работать/можно сделать проще/ и т. д.

Сорри, ошибся — "взаимопонимание"

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

PO>Сорри, ошибся — "взаимопонимание"

+1 Reciprocality

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

AK>Кто как считает, какие в области разработки ПО самые большие проблемы?

По моему мнению, одна из самых больших — масштабирование приложения на большое кол-во ядер.
Простейший пример, Вы пишете десктопное приложение для работы с изображениями, типичный размер изображения — 2-10 мегапиксела. После выбора пункта меню "Открыть"(из jpg, из png, из tiff) Ваше приложение замерзает на 2-4 секунды. При этом из 8 ядер "вскипает" только одно.
Что делать, если на вашей платформе нет стабильных многопоточных кодеков?

Для множества программных проектов(игры, обработка мультимедиа) огромное преимущество на рынке получают разработки эксплуатирующие ВСЕ ядра как
1) более быстрые
2) увеличивающие свою производительность при установке на машину с большим кол-вом ядер (4->8->16->32->...)

На сегодня "хорошая" эксплуатация множества ядер есть только у декларативных языков вроде SQL. Затребовал "SELECT ..." и пусть уже там оптимизатор Oracle парится. Все остальное — сказки для университетов: Transactional Memory, Functional Programming, Actor-based languages. Ядра RDBMS на них не пишут. 3D-шутеры тоже.

В реальности в следующем поколении процессоров AMD/Intel будут инструкции для Hardware Transactional Memory (AMD спеку уже написала, Azul systems свои Vega уже делает, Intel тоже вот-вот выпустит спеку). И вот при попытке срастить Transactional Memory programming style(atomic, commit, rollback) и Explicid Synchronization programming style(lock, semaphore, CountDownLatch, Barrier, ThreadPool, Future, etc.) не одну сотню программистов увезут или в дурдом или в менеджеры по продажам.

Так вот, все еще сложнее. До сих пор программные модели были под cache coherent SMP машины. Уже для 100 ядер (а Intel готовит 80 ядер — http://kharkovconcurrencygroup.blogspot.com/2009/09/intel-teraflops-research-chip.html, Tilera 100 ядер — http://kharkovconcurrencygroup.blogspot.com/2009/10/tilera-talks-100-core-processor.html) машины будут NON cache coherent NUMA (Non Uniform Memory Access). И модели с потоками, которые как хотят обмениваются данными — БУДУТ ОЧЕНЬ ПЛОХО РАБОТАТЬ. Будут какие-то очень асимметричные программные модели. В CUDA на сотнях ядер это уже так.

Полагаю, произойдет разделение. Однопоточники, с уровнем сложности VB или SQL(зарплата 1.000$-3.000$) и многопоточники с уровнем к.т.н/к.ф-м.н (2.000$-8.000$).

P.S. Говорят, разработчик Paint.NET сказал, что самое сложное было — сделать приложение многопоточным и при этом корректным.

P.P.S. Все тут написанное чистое ИМХО. Как специалист по concurrent Java автор материально заинтересован именно в таком ходе событий . Кому интересно, автор сеет паранойю также в блоге — http://kharkovconcurrencygroup.blogspot.com

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

AK>>Кто как считает, какие в области разработки ПО самые большие проблемы?
VD>Проблемы три:
VD>1. Много сложных задач.
VD>2. Мало тех кто умеет решать сложные задачи.

т.е. получается, что большинство кодеров делают то, что им в общем то не под силу?.

VD>3. Слишком много хиливаров.

нет ты!.

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

GI>Полагаю, произойдет разделение. Однопоточники, с уровнем сложности VB или SQL(зарплата 1.000$-3.000$) и многопоточники с уровнем к.т.н/к.ф-м.н (2.000$-8.000$).

ага, мечты-мечты.. илитарность.. вера в кандидатскую..
а потом Капитан Америка узнает, что Капитан Индия делает его работу лучше и быстрее.. [здесь должна быть картинка/]