Як уникнути стрибків до розчину, коли тиснеш? [зачинено]

Якщо під особливо строгий термін програмування (наприклад, годину), якщо я взагалі панікую, моя тенденція полягає в тому, щоб стрибати в кодування без реального плану і сподіваюся, що я з’ясую це, коли йду далі. Зважаючи на достатньо часу, це може спрацювати, але в інтерв'ю це було досить невдало, якщо не прямо контрпродуктивно. Мені не завжди зручно сидіти там, думаючи, поки годинник відлітає.

Чи є контрольний список чи є методи розпізнавання, коли ви досить добре розумієте проблему, щоб почати кодування? Коли найпродуктивніше думати і розробляти більше, аніж кодувати деякі експерименти, а потім розробити всебічний дизайн?

Ось перелік методик складання тесту з математики та ще один для складання усного іспиту . Чи існує подібний перелік методик для вирішення проблеми програмування під тиском?

ВІДПОВІДИ: Я думаю, що це правильна відповідь: як її вирішити . Я знайшов це посилання як відповідь на кроки щодо вирішення чи підходу до рішення . Було також кілька дійсно хороших порад на те, чи справді думка вголос під час інтерв'ю справді найкраща стратегія? . Чудовий і стислий аргумент для TDD - це перша відповідь на код написання TDD проти з'ясування відповіді на проблему? .

Я пригадую, як читав дослідження про те, як пожежні десанти формують план дій по прибуттю на місце пожежі; У дослідженні спостерігали (і засуджували) їх за те, що вони вийшли з ідеєю, а потім переслідували цю першу ідею негайно. Через тиск часу, це було майже "це може працювати", а потім "добре, давайте це зробимо". У дослідженні зазначалося, що є кращі, швидші, безпечніші варіанти, але їх не дотримувались просто тому, що маршали не думали про них спочатку.

Якщо ви хочете структурований підхід до подолання «пожеж», можливо, вийдіть із їхньої (нової) книги, яка передбачає кілька етапів:

РЕЧЕНИЙ

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

або в більш загальних рисах:

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

Я завжди починаю з розуміння вимог та пошуку прогалин у них, на які потрібні відповіді.

Тоді я ескізую (дуже грубо і на папері чи дошці) два-три можливі рішення. Тоді я запитую себе: "Чи є ще щось, що я повинен знати, щоб здійснити будь-яке з них?"

Після того, як у мене з’являються мої початкові запитання (є питання в 100% часу, якщо у вас немає жодного, ви насправді не розглядали вимоги глибоко.), Я повертаюся до зацікавлених сторін, щоб отримати мої відповіді.

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

Як тільки я отримаю відповіді, я вибираю грубу конструкцію, а потім складаю список усіх речей, які мені доведеться зробити для її втілення. Тоді я починаю кодувати.

... моя схильність полягає в тому, щоб стрибати в кодування без реального плану і сподіваюся, що я з’ясую це, продовжуючи.

Я робив це ще в університеті. Це стало справжньою проблемою і, як правило, призведе до переписування коду. Я почав це вирішувати, не написавши код. Я робив акцент на думці про проблему. Маючи достатньо практики, я інстинктивно дотягуюся до своїх думок, а не до клавіатури.

... в інтерв'ю це було досить невдало, якщо не відверто контрпродуктивно. Мені не завжди зручно сидіти там, думаючи, поки годинник відлітає.

В ході інтерв'ю повинна бути аргументована, продумана реалізація рішення, і це не завжди легко. Те, що ви не хочете робити, - це розмивати відповіді, не замислюючись. Якщо ви знаєте відповідь, швидко дайте її. Якщо ви цього не зробите, покладайтеся на свої думки, щоб обґрунтувати рішення. Завжди вказуйте, коли ви не знаєте, і демонструйте, як би ви йшли до пошуку рішення.

Чи є контрольний список чи є методи розпізнавання, коли ви досить добре розумієте проблему, щоб почати кодування?

Я б заважав такому, тому що ви можете жорстко покластися на це. Швидше запитайте себе, чи ви досить добре розумієте проблему, щоб почати кодування. Як би ти знав? Тому що, коли ви обґрунтуєте свій підхід, а потім вивчите його, враховуючи теперішнє знання мови, це матиме сенс. Завжди майте план і підхід. Також пам’ятайте, що код ніколи не закінчується, а код, який не розвивався, загине, тому очікуйте, що часто повертаєтесь до коду.

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

Вам захочеться дізнатися дизайн над усіма і подумати над ним. Потім ви починаєте виготовляти структуру класу та заглушки. Потім перегляньте його ще раз. Чи має сенс? Експерименти з кодування - це чудовий спосіб продемонструвати, що щось працює добре, і його слід використовувати, але не покладатися на нього, чи формувати написаний вами код.