Одно недавнее лабораторное задание в школе Flatiron заключалось в следующем: чтобы узнать о взаимодействии с веб-API, мы создавали программу на Ruby, которая

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

Однако с этого момента инструкции были в основном: с ума сходить. Сделайте что-нибудь весело отсюда. Имея в своем распоряжении весь API, создайте что-то, что, по вашему мнению, будет забавным, интересным или крутым. Постарайтесь ничего не взорвать.

(Здесь я должен упомянуть о сочувствии, которое я испытывал к сетевым администраторам сайта SWAPI, и о замешательстве, которое они, должно быть, испытали, когда их сайт внезапно подвергся DDOS-атаке из-за сотен или тысяч веб-запросов в минуту от нетерпеливых студентов Flatiron. , Запоздалые извинения.)

Народное творчество шло разными путями. Одна особенно блестящая (по моему мнению) группа превратила извлеченную информацию в викторину, предоставив вам несколько фрагментов информации из определенного фильма и попросив пользователя угадать, из какого фильма она была. Другие сделали более интересные варианты первоначального задания. Мой партнер и я решили, что нет причин ограничивать пользователей извлечением информации конкретно о персонажах, и что с небольшой доработкой и общим назначением код можно (довольно легко) сделать для опроса информации о чем-либо, содержащемся в базе данных, от персонажей до фильмов, планет, транспортных средств и видов; все, что имело собственный разбитый на страницы список, могло быть настроено таким образом. И оттуда отображать всю содержащуюся информацию: каждый раз, когда он сталкивался с URL-адресом, вместо отображения этого URL-адреса он извлекал объект JSON из этого и отображал список этих названий (фильмы, люди, планеты, транспортные средства и так далее). Это было немного похоже на это в действии.

Создавать это было и сложно, и весело. Но в этом и заключается одна из проблем, с которыми творческие программисты часто сталкиваются в реальном мире: что делать, когда в процессе разработки вам приходят в голову захватывающие идеи для наворотов. Что вы считаете приоритетным? Как вы организуете свой код? Есть ли смысл полностью переделывать кодовую базу, чтобы упростить и логично упростить этот новый элемент дизайна, который пришел вам в голову? Должны ли вы просто создать список пожеланий для идей, которые нужно реализовать после того, как весь жизненно важный производственный код будет опробован и протестирован?

Это проблема, с которой я иногда сталкивался в прошлом во время учебы. На самом деле, мой первый опыт формирующего программирования заключался в следующем: лабораторная работа была «Создать графический интерфейс, любой графический интерфейс», и до тех пор, пока он не сломался, чем круче он был, тем лучше. И, черт возьми, это было весело:у вас появлялись идеи для причудливых, забавных, чисто визуальных вещей, а затем вы их воплощали! И они будут работать! Именно это и подтолкнуло меня к программированию. Однако в реальном мире проекты редко разворачиваются подобным образом. Важно сначала сосредоточиться на основных функциях, а затем вы можете создавать интересные функции, которые, как вы знаете, впоследствии понравятся пользователям. Но если вы начнете убегать, гоняясь за каждой отличной идеей, которая приходит вам в голову, вы не только никогда не закончите проект, но и забудете о тех частях, которые имеют приоритет. И его отладка будет кошмаром, так как вы никогда не заставите основные компоненты работать.

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

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