Как избежать прыжка к решению, когда под давлением? [закрыто]

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

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

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

ОТВЕТЫ: Я думаю, что это правильный ответ: как это решить . Я нашел эту ссылку как ответ на шаги для решения или подход к решению . Были также несколько действительно хороших советов: « Размышлять вслух во время интервью - действительно лучшая стратегия? , Отличным и лаконичным аргументом для TDD является первый ответ на TDD. Написание кода против выяснения ответа на проблему? ,

Я вспоминаю, как читал исследование о том, как пожарные маршалы формируют план действий по прибытии на место пожара; исследование наблюдало (и осуждало) их за то, что они выдвинули идею, а затем сразу же воплотили эту первую идею. Из-за нехватки времени это было в значительной степени «это может сработать», а затем «хорошо, давайте сделаем это». В исследовании отмечалось, что лучшие, более быстрые и безопасные варианты были доступны, но за ними не следовали просто потому, что маршалы не думали о них первыми.

Если вам нужен структурированный подход к борьбе с «пожарами», возможно, возьмите лист из их (новой) книги, в котором прописано несколько этапов:

RRAPID

1. Реакция - мобилизация ресурсов на инцидент
2. Разведка - Соберите данные о ситуации
3. Оценка - Выберите курс действий на основе лучших и худших сценариев
4. План - разработать план, основанный на курсе действий
5. Выдача заказов - используйте стандартный формат брифинга
6. Развертывание - выполнение и мониторинг

или в более общих чертах:

1. Разбудить всех и заставить их двигаться
2. Выясни, что происходит
3. Решения для мозгового штурма
4. Выберите один и спланируйте
5. Расскажи всем, что у них за работа
6. Выполнить и контролировать

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

Затем я набросал (очень грубо и на бумаге или на доске) два или три возможных решения. Затем я спрашиваю себя: «Есть ли что-то еще, что мне нужно знать, чтобы реализовать что-либо из этого?»

Как только у меня появятся мои первоначальные вопросы (в 100% случаев есть вопросы, если у вас их нет, вы не очень подробно изучили требование). Я возвращаюсь к заинтересованным сторонам, чтобы получить мои ответы.

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

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

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

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

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

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

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

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

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

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