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

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

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

"Тысячи их" (С).
Финансовая успешность проекта далеко не всегда определяется качеством его архитектуры. В конце концов, расширение и доводка продукта до юзабельного состояния — целая отрасль (см. "системные интеграторы", одной из их задач и является скрестить архитектуру ужа с иголками ежа).
А некоторые продукты и вовсенельзя "просто купить". Они продаются только с инженегром в комплекте, который будет все устанавливать, настраивать и следить за работоспособностью.

On 06.03.2013 23:02, Ikemefula wrote:

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

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

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

SD>"Тысячи их" (С).
SD>Финансовая успешность проекта далеко не всегда определяется качеством его архитектуры.

Как ты определяешь понятие качественной архитектуры ? Красивые квадратики, стрелочки ?

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

Давай ты выдашь таки понятие качества а потом попробуем применить его к нескольким программным продуктам.

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

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

__>>А что должен знать "архитектор"? Просветите пожалуйста дикаря и неуча.

_>Архитектор — это человек, не который много знает, а который может решить сложную задачу, которую ты, кодерок, не потянешь. У тебя просто мозга не хватит её охватить, предвидеть проблемы и ограничения. Твои задачи — чекать палиндромы и обходить BST.
Есть проблема, что для того, чтобы решать сложные задачи, необходимо еще уметь решать и простые. Поэтому такой тест очень неплох для того, чтобы отличить опытного разраба от подмножества неудачников описанных в стартовом посте -- если человек начинает какать кирпичиками в ответ на эти вопросы, то можно сразу дать ему под зад, чтобы шел побираться в другое место. Если не начинает, а честно отвечает в пределах своей компетенции, то надо смотреть на другие признаки -- опыт (не менее 10-12 лет), места работы и.т.д.

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

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

A>Я видел. Ситуация следующая, область не автоматизирована, есть какие-то макросы в Екселе и на этом все. Приходит мега-архитект, делает говно-платформу, которая неэффективно, но кое-как работает. В итоге конторе профит.

А что для тебя "качество" ?

> Амогла бы работать раз 5 быстрее и требовать раза в три меньше сил на поддержку, т.е. конторе доп. профит, но не срослось.

То есть, говноплатформа помешала конторе получить доп-профит ? С чем ты был не согласен тогда?

On 07.03.2013 11:25, denisko wrote:

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

Скорее так — для того чтобы решать сложные архитектурные задачи —
необходимо уметь решать и простые архитектурные задачи. Которые
необязательно имеют отношение к другим ИТ задачам (например,
алгоритмическим).

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

Если вам надо опытного разработчика — то да. Про архитектора туманно. В
связи с тем что реально архитекторов более одного на контору не надо,
термин очень расплывчат и используется чаще всего в значении "ну это
такой, который круче чем просто senior".

--
WBR,
Serge.

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

H>Скорее так — для того чтобы решать сложные архитектурные задачи —
H>необходимо уметь решать и простые архитектурные задачи. Которые
H>необязательно имеют отношение к другим ИТ задачам (например,
H>алгоритмическим).
Чтобы уметь решать архитектурные задачи (сборка приложений из стройматериалов -- блоков и паттернов) и ничего больше надо либо иметь идеальные стройматериалы (блоки и паттерны), либо большой опыт хождения по разным граблям, связанными с этими стройматериалами. Первого пока(?) не существует, так что второе становится необходимым. Большой опыт отличают обычно большие горести и большие знания. Так что если приходит на собеседования жизнерадостный юнец с нулевыми знаниями, то вероятность что он станет хорошим архитектором достаточно мала.


H>Если вам надо опытного разработчика — то да. Про архитектора туманно. В
H>связи с тем что реально архитекторов более одного на контору не надо,
H>термин очень расплывчат и используется чаще всего в значении "ну это
H>такой, который круче чем просто senior".

Все это становится еще более туманным, если принять во внимание количество архитекторов, наличие большого числа бизнес-аналитиков и ПМ, наличие большого числа разрабов, которые будут делать что угодно, но только не то, что им скажут и.т.д. В результате самое правильное определение архитектора в РФ -- "человек, который хочет заниматься тем и единственно тем, что говорить мышам, чтобы они становились ежиками".

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

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

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

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

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

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

Но на практике не всегда правильное решение приводит к успеху.
Иногда перезапуск по крону процесса с ликом памяти(или других ресурсов) — это самое выгодное решение с точти зрения бизнеса.
Потому как:
1. Проблема точно решается(для остальных решений это еще надо подтвердить)
2. Затраты по ресурсам миинимальные
3. Затраты по времени минимальные
Хотя с технической точки зрения — это совсем неправильное решение.

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

On 07.03.2013 16:28, robin_of_the_wood wrote:

> — это самое выгодное решение с точти зрения бизнеса.

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

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

>> И такие ошибки надо предотвращать любыми средствами.
V>Противоречия не видишь? Слово "любыми" здесь неприменимо. Средствами, на
V>которые бизнес может пойти.

Ну под "любыми" я подразумевал "любыми доступными".
А уже область доступности конечно всегда бизнесом определяется. Спору нет.

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

KP>.NET — это еще тот рассадник УГ. Но, выход есть, все же некоторые компании на .NET могут писать не только очередную опердень, но и что-то действительно интересное. Например, такой компанией является Microsoft, Bing если говорить точнее.

А где не опердени?

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

D>Есть проблема, что для того, чтобы решать сложные задачи, необходимо еще уметь решать и простые.

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

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

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

A>>Я видел. Ситуация следующая, область не автоматизирована, есть какие-то макросы в Екселе и на этом все. Приходит мега-архитект, делает говно-платформу, которая неэффективно, но кое-как работает. В итоге конторе профит.

I>А что для тебя "качество" ?

Что ты имеешь ввиду?

>> Амогла бы работать раз 5 быстрее и требовать раза в три меньше сил на поддержку, т.е. конторе доп. профит, но не срослось.

I>То есть, говноплатформа помешала конторе получить доп-профит ? С чем ты был не согласен тогда?

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

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

On 07.03.2013 19:14, Abalak wrote:

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

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

>> кое-какая упущенная выгода
V>Оооо, этот термин вообще потрясает — раньше это называли дележкой шкуры
V>неубитого медведя.

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

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

On 07.03.2013 22:05, Abalak wrote:

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

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

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

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

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

Т.е. это ты так ненавязчиво сейчас нарушил правила и решил усомниться в моей квалификации? Вкратце там схема такая — приходит текстовый файлик, в нем от несколькох сотен до нескольких миллионов строк (1-2). Он балком кладется в базу, далее другой процесс берет эти данные, проводит некий препроцессинг (изменение названий, добавление служебной информации и т.п.) и делает из этих данных XML. XML этот кладется на диске, с которого его забирает третий процесс, проводит необходимые вычисления с этими данными и раскладывает по табличкам. Готов после этого утверждать, что нормально написанное будет медленнее.
Заказчика (точнее это внутренняя разработка) скорость пока (это было 2 года назад) вполне устраивает, т.к. файлов не очень много. Я догадыаюсь, но не уверен, что могла не устраивать скорость добавления новых фич, т.к. в этих фичах зачастую были замешаны маркетологи, продвигавшие услуги и им нужно было иметь новый функционал максимально быстро.

V>Опять куча качественных терминов без малейшей возможности оценить их
V>количественно.

Выше.

V>Ну и. Сам говоришь, что "нормальная" с твоей точки зрения система могла
V>оказаться и дороже и, неизветсно еще, лучше ли.

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

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

V>Противоречия не видишь? Слово "любыми" здесь неприменимо. Средствами, на
V>которые бизнес может пойти.
V>А Икемуфула просто очень далек от финансовой части програмерской работы.

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

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

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

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

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

I>>А что для тебя "качество" ?

A>Что ты имеешь ввиду?

"Качество программного обеспечения, архитектуры, кода" что это значит, по твоему ?

A>Именно, и не факт, что мега-профит, т.к. свои функции она выполняла, времени достаточно, могли бы только съэкономить на поддержке и разработке. Ну и скорость введения новых фич была не максимальной, что тоже снижало профит. Хотя отрасль забюрократизированна по самое не балуй, так что объем упущенной выгоды не очевиден.

А как ты выяснил, что у платформы гранаты не той системы низкое качество архитектуры или кода ?