В отличном выступлении на GDC 2019 года под названием Все, кто смотрит это, уволены: советы для программистов игровой индустрии Майк Актон дал невероятно полезную информацию о том, что он, очевидно, считает лучшим подходом к решению технических проблем.
Даже если его презентация была ориентирована на разработчиков игр, я обнаружил, что его советы также очень хорошо работают в других областях, связанных с программированием, таких как веб-разработка, или даже, в какой-то степени, с обычными жизненными проблемами. Я не мог устоять перед желанием применить его 50 советов к проекту, который я недавно начал для одного из моих клиентов.
По стандартам Майка Эктона меня бы действительно уволили. Хорошо, что мои клиенты более снисходительны, чем он 😉. Меня поразила часть о допустимых диапазонах значений, которые я преобразую. Несмотря на использование строго типизированных языков и фреймворков, я недостаточно глубоко задумывался о проверке ввода и понял, что, возможно, позволил пользователям вводить отрицательные суммы в этой системе выставления счетов, что, как вы понимаете, могло бы все испортить. Фу, это было близко.
Меня очень вдохновило это видео, и я решил начать шаблонизировать (да, шаблонизировать — это слово, так говорит Городской словарь 😛) советы Майка Актона для моих собственных проектов, начиная с сегодняшнего дня.
Как следствие, я создал таблицу из 31 вопроса (см. ниже), на которые необходимо ответить, прежде чем приступить к написанию хотя бы одной строчки кода в проекте на Parallel45. Очень полезный инструмент, который уже улучшает качество нашей работы и делает наших клиентов еще счастливее!
Спасибо, Майк!
- Какую проблему я пытаюсь решить?
- Почему важно решить эту проблему?
- Где тот предел, когда решать эту проблему не стоит?
- Что такое план Б?
- Какие шаги необходимы для решения этой проблемы?
- Каковы неизвестные и риски, связанные с решением?
- Какую структуру я создал, я могу использовать и изменить для решения этой проблемы
- Как я узнаю, что решил проблему?
- Что я пытаюсь доказать? Какова моя гипотеза?
- Как я могу доказать, что моя гипотеза неверна?
- Каковы требования к задержке для решения моей проблемы?
- Какая пропускная способность необходима для решения моей проблемы?
- Каков наиболее распространенный вариант использования решения, которое я разрабатываю?
- Каковы наиболее распространенные реальные ценности в реальной жизни, которыми я манипулирую?
- Каковы допустимые диапазоны значений, которыми я манипулирую?
- Что происходит, когда данные за пределами этого диапазона попадают в систему?
- Как выглядят входные данные?
- Какова частота изменения реальных ценностей, которыми я манипулирую?
- Где документация по инструментам, которые я чаще всего использую для решения этой проблемы?
- Что является самой медленной частью рабочего процесса системы для моих пользователей?
- Какая информация о моей системе нужна пользователям для эффективного использования решения?
- Для какого оборудования предназначено это решение?
- Как это оборудование влияет на дизайн моей системы?
- Как работает мое решение? Сколько времени это занимает?
- Как я могу оптимизировать свое решение?
- Как я могу отлаживать живые сборки моего решения?
- Какие данные считывает решение и откуда они берутся?
- Как часто я читаю данные, которые мне не нужны, как часть моего решения?
- Какие данные я записываю и где они используются?
- Как часто я записываю данные, которые мне не нужны, как часть моего решения?
- Как данные артикулируются в памяти?
И помните, ваш проект не рассчитан на будущее и не зависит от платформы! Не забывайте сидеть и наблюдать за реальными пользователями вашей системы, чтобы понять болевые точки и то, как они взаимодействуют с ней.
