Крис Ли, инструктор Launch School, во время обучения несколько раз говорил: «Не волнуйтесь, вы научитесь, как только обожжетесь». Это утверждение занимало мой разум последние 36 часов.
Я перешел на следующий курс учебной программы Launch School после прохождения первой оценки, и это было все, на что я надеюсь, и даже больше; вызов! В настоящее время я работаю над игрой OO Rock, Paper, Scissors, в которой есть несколько дополнительных функций. Одна функция, в частности, проверяла мои способности в течение последних 36 часов: включение ИИ для компьютерного игрока. Я определил свои собственные правила для этой функции, которые заключаются в следующем: если компьютер проигрывает при определенном ходе, уменьшите вероятность того, что компьютер снова выберет этот ход, если он проигрывает 50% или более времени, играя этот ход. На самом деле это элементарно: если компьютер играет в рок и проигрывает в первом раунде, во втором они не выберут рок. Я намерен более подробно остановиться на уменьшении вероятности в будущем, но сейчас мы просто обсудим этот первый набор правил для функции ИИ.
Теперь, когда у меня были правила, которым я следовал, я написал логику этой функции. 1.) Создайте новый массив для размещения проигрышных ходов компьютера. 2.) Перебрать массив и подсчитать, сколько раз каждый ход проигрывает. 3.) Разделите количество проигрышей каждого хода на общее количество проигрышных ходов. 4.) Если результат = 50% времени, поместите этот ход в массив dont_pick. 5.) Если компьютер выбирает ход из массива dont_pick, выберите другой ход. 6.) Повторяйте этот процесс каждый раунд.
Так что моя логика довольно проста. Я написал свой первый метод для создания массива проигрышных ходов. Вот где я застрял последние 36 часов, и заявление Криса начало воспроизводиться в моей голове. Я собираюсь выйти с другой стороны этой проблемы и получить более четкое представление о программировании в целом. Моя программа добавляла ход, независимо от того, был ли он проигрышным или выигрышным. Почему?
Я попробовал несколько операций и методов отладки, чтобы выяснить, где была ошибка. Я сузил его до следующей строки кода: `comp_losses ‹‹ move[1] if move[0] › move[1]`. Я намеревался сравнить объекты класса Move, чтобы определить, превосходит ли одно движение другое; это, однако, было не то, что я делал. Имейте в виду, здесь много кода, на который не ссылаются. `move[0]` и `move[1]` являются частью хэша, в котором хранится история ходов, сделанных каждым игроком, человеком и компьютером.
Тем не менее, углубившись в код, я узнал, что есть проблема со строкой кода, упомянутой выше. `move[0]` и `move[1]` не являются объектами моего класса Move, это строки; поэтому сравнение сравнивает строки, а не объекты Move. Эта ошибка сломила меня на большее время, чем я хотел.
Итак, теперь мы знаем нашу проблему, как мне ее исправить? Ну, я мог бы просто создать новый объект Move, вызвав `comp_losses ‹‹ move[1] if Move.new(move[0]) › Move.new(move[1])`. Это, безусловно, выполнит операцию, которую я пытаюсь выполнить. Но вместо того, чтобы предложить временное решение, я хотел обратиться к источнику проблемы. Я понял, что при хранении истории ходов в своем логе я их цеплял как струны. Я сделал небольшое исправление, чтобы хранить их как объекты класса Move. Проблема решена.
Мораль моего кошмара отладки одна, не все кошмары плохи. Из-за этой проблемы я понял, что мне нужно больше знать о своем коде и о том, что хранится в переменных, которые я вызываю. Простой процесс сохранения строки в моем хэше, а затем попытка сравнить эту строку как объект укусили меня за задницу. Потратьте время, чтобы понять, почему вы сохраняете переменную в ее текущем формате. Вы также должны спросить себя, как вы собираетесь использовать эту переменную в будущем.
В целом, мне нравятся эти задачи и общая сложность обучения разработке программного обеспечения по учебной программе Launch School. Их персонал и поддержка были на высшем уровне и были чрезвычайно ценным активом для моего образования.
Оставайся глупым, Будь скромным, ЖИВИ НЕУДАЧНЫМ!!
