Войти
ПрограммированиеФорумОбщее

Оценить потенциал к работе над программной архитектурой

Страницы: 1 2 3 Следующая »
#0
13:49, 19 сен. 2018

Предположим, нужно выбрать программиста для задачи по рефакторингу и редизайну большой подсистемы. Никто из программистов раньше такого не делал и с данной системой дела не имел. Задался вопросом: какие вопросы можно задать программисту, чтобы выяснить - есть ли у него склонности к проектированию архитектуры? Вопросы должны подразумевать возможность ответить сразу или в течение часа.
Как вы считаете, какие вопросы были бы наиболее показательны для выделения программистов склонных к порядку, систематизации, выделению абстракций и тому подобное, что повысило бы шансы на успешный редизайн программной архитектуры?


#1
13:59, 19 сен. 2018

Показать/рассказать про прошлые проекты и какие архитектурные решения применялись, какова была роль в этих проектах.
А просто вопросы мало что покажут.

#2
14:03, 19 сен. 2018

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

#3
14:06, 19 сен. 2018

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

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

Если получится что-то впечатляющее, способное наращивать мощность со временем - то тест пройден.
Если получится лапша из микросервисов и немасштабируемая архитектура, тогда вернуть неудачника обратно в каменоломни.
Этого должно уже быть достаточно.
Успешность зависит от того насколько ваш проект заражен верой в микросервисы и другим булщитом, который не работает :)

#4
14:14, 19 сен. 2018

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

#5
14:31, 19 сен. 2018

1. Обязательно портфолио и рассказ о проектах в нём.
2. Вопросы по системной инженерии и смежным дисциплинам. Например, описать жизненный цикл проекта, какие проблемы есть на каждом этапе, etc. Без этого я бы архитектуру никакую разрабатывать не доверил :-D
3. Предложить порассуждать на холиварные темы, вроде "когда разумно использовать ООП, а когда ФП". Если человек скатывается в одну сторону, значит есть пробелы в кометенции.
4. Архитектурные вопросы по предметной области задачи. В вебе, например, это разница между параллельностью и конкуррентностью, очереди (что, как, зачем). В игровой логике: графы, эвристики, конечные автоматы.
5. Предложить описать последовательность решения некоторой общей проблемы. Я, например, прошу описать действия в случае "К вам ночью прибежл гонец с работы, сказал что сервер недоступен и умер. Что будете делать?"

#6
16:17, 19 сен. 2018

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

#7
16:44, 19 сен. 2018

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

#8
17:35, 19 сен. 2018

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

мне помнится в некоторых проектах приходилось разбирать по коду самостоятельно, фиксировать в диаграммах, по сути составлять документацию

сейчас я конечно понимаю насколько был наивен

#9
17:52, 19 сен. 2018

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

#10
18:41, 19 сен. 2018

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

#11
20:03, 19 сен. 2018

makeacase
> задачи по рефакторингу и редизайну большой подсистемы
а кста вопрос, с чего ты взял что подсистему надо рефакторить?

потому что никто из текущих программистов не разбирается? : )

#12
0:55, 20 сен. 2018

makeacase
> Как вы считаете, какие вопросы были бы наиболее показательны для выделения
> программистов склонных к порядку, систематизации

Типа такого:
- Вы идете по коридору, на полу валяется скомканная бумажка. Ваши действия - поднять и выкинуть в урну / пройти мимо.

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

#13
9:20, 20 сен. 2018

>Никто из программистов раньше такого не делал и с данной системой дела не имел.
Тогда никакие ухищрения не помогут, особенно если работа требует специальных знаний (физика, рендер, сеть, звук). Только опыт работы с подобными системами.

#14
12:15, 20 сен. 2018

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

Страницы: 1 2 3 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.