Подходит к концу первая неделя Capstone. Поразительный контраст между тем, как я подходил к проблемам всего 6 дней назад и сейчас ... и это только начало. Благодаря огромному количеству знаний, полученных на этой неделе, полезно повторить его в письменной форме ради удержания. Итак, вот краткое изложение некоторых из наиболее важных концепций.
1. Преобразование ментальной модели в код - самая простая часть ...
… И построение модели, которая точно представляет проблему, - самая сложная часть. Фактически, если я читаю чей-то код, я обычно могу реконструировать ментальную модель, которую они использовали для решения проблемы. Однако, если бы я столкнулся с той же проблемой, было бы гораздо труднее перейти от описания проблемы к ментальной модели, которую представляет их код.
В пятницу мы провели имитационные интервью с другими членами нашей когорты (всего нас шестеро). Один из студентов потратил 33 минуты на разработку ментальной модели и всего 7 минут на кодирование оптимизированного решения. Зачем он это сделал? Потому что гораздо важнее и сложнее построить правильную ментальную модель, чем преобразовать эту модель в код. Построение ментальной модели - это акт решения проблем, творчества и синтеза. Чтобы перевести это в код, нужно просто свободно владеть определенным языком сценариев.
2. Не каждое решение - хорошее решение.
Некоторые решения совершенно плохие. Заставить код работать и заставить код работать хорошо - два совершенно разных подвига, и последнее намного сложнее. При решении любой проблемы необходимо учитывать множество компромиссов. Существует классический компромисс между эффективностью использования пространства и эффективностью времени. Например, я столкнулся с проблемой, которую я мог решить за время O (n log n), используя пространство O (1), но ее также можно было решить за время O (N) с пространством O (N). Первый немного медленнее, но занимает больше места, в то время как второй немного быстрее, но занимает меньше места… Итак, что мне выбрать?
Это подводит меня к следующему пункту о создании хороших решений: ваше решение не обязательно должно быть хорошим в начале решения проблемы, оно просто должно быть хороший к тому времени, когда вы закончите. Мы склонны начинать с неэффективных решений - «наивных» или «грубых» решений - а затем «продвигаем наше решение вниз по кривой большого О».
Начинать с наивного метода грубой силы не только хорошо, но и полезно. Наивный подход обычно интуитивно понятен, но чтобы его придумать, все же требуется достаточное понимание проблемы. То есть, это позволяет вам сосредоточиться на понимании проблемы, а не на построении умного решения. Он также раскрывает узкие места в производительности, которые нужно отточить во время оптимизации. Итак, наивный подход дает ощутимые дальнейшие шаги. Это разница между попыткой прыгнуть на 10 футов вперед за один раз и прыжком на 5 футов один раз, а затем снова на 5 футов. Последнее намного проще.
3. Чтение чего-то очень отличается от понимания.
Еще одна вещь, которая мне очень понравилась на этой неделе, - это присутствие эксперта, внимательного на каждом этапе пути. Перед поступлением в Capstone студенты должны были прочитать книгу о структурах данных и алгоритмах. Я читал книгу несколько раз и чувствовал, что у меня есть сильное интуитивное понимание многих концепций ...
А потом пришло время применить эти концепции.
Конечно, я понял теорию, лежащую в основе Big-O и различных элементарных и составных структур данных. Я даже погрузился в математические доказательства, связанные с Big-O, просто из любопытства. Но способность замечать или предвидеть узкие места в производительности - это совсем другое дело. Мой взгляд на решение проблем резко изменился. Перед тем, как приступить к Capstone, я был удовлетворен, когда мои программы производили правильный вывод и были хорошо написаны (то есть без дублирования кода, правильного именования, модульности и т. Д.). Теперь я вижу, что этого недостаточно: производительность - это вопрос на каждом этапе кстати… Но не за счет других важных факторов дизайна. Другими словами, производительность является важным дополнительным фактором, но хороший инженер-программист сосредотачивается на всех аспектах построения решения. Хорошее решение не только хорошо написано, легко читается, соответствует уровню абстракции, имеет модульность, когда это необходимо, но и является эффективным. Все эти соображения важны.
4. Несколько ментальных моделей соответствуют множеству различных проблем.
Чтобы научиться умело и быстро разрабатывать ментальную модель проблемы, нужно усвоить сложную кривую обучения, и я все еще нахожусь у ее основания, поднимаясь вверх. Однако кое-что я уже заметил. Существует множество проблем с алгоритмами и структурой данных, но ментальных моделей, которые могут решить эти проблемы, меньше.
Наш инструктор постоянно напоминает нам о необходимости сосредоточиться на ментальной модели. Когда мы рассматриваем проблемы, мы даже не смотрим на код, пока мы не достаточно и четко не обсудим соответствующую ментальную модель, а также линию рассуждений, которой мы следовали, чтобы прийти к этой ментальной модели в первую очередь.
По мере того, как я решаю больше проблем, я начинаю замечать сходство между многими проблемами, которые якобы очень разные, но в основном очень похожи. Даже сегодня я потратил пару часов на решение нескольких проблем, пытаясь конкретизировать свои ментальные модели для них, только чтобы прийти к одной и той же ментальной модели для всех них. Следовательно, код, который я написал для решения каждой из этих проблем, выглядел почти идентичным. И это несмотря на то, что описания каждой проблемы звучали совершенно по-разному. Эта ментальная модель запечатлелась в моей памяти, как и ее копия проблемного образца.
Настоящая прелесть этого подхода в том, насколько легче подойти к проблеме, если вы распознаете общую схему, в которую попадает проблема. Если у вас есть ментальная модель, которая соответствует образцу проблемы, то на самом деле требуется очень мало интенсивного мышления или решения проблемы: вы уже знаете решение, это просто вопрос перевода этого решения на ваш язык по выбору ... , как я уже сказал, это самая легкая часть.
Заключение
Capstone - это все, что я мог бы пожелать от программы профессионального обучения ... Беседы разнообразны, потому что каждый человек:
А) умный
Б) очень трудолюбивый
C) уже опытные разработчики
Г) уважительный и вдохновленный учиться
Из-за этих факторов разговоры между членами когорты также являются отличным учебным опытом. У всех нас достаточно высокий базовый уровень знаний, потому что мы завершили основательную учебную программу по разработке программного обеспечения. Таким образом, мы можем сосредоточиться на темах более высокого уровня, не сбиваясь с пути из-за путаницы в фундаментальных принципах. Это позволяет нам сосредоточиться на более инженерных темах.
Наконец, инструктор чрезвычайно искусен в изложении сложных идей. Некоторые из самых ярких образовательных опытов, которые у меня были, были во время «пошаговых инструкций» нашего инструктора по процессу решения конкретной задачи по программированию. Он ведет нас от описания проблемы к полностью оптимизированному решению. Он объясняет свой мыслительный процесс, чтобы мы понимали, как перейти от описания проблемы к ментальной модели. Если бы он начал с самой ментальной модели, мы бы никогда не столкнулись с этим предварительным модельным процессом построения модели. Тем не менее, это самый ответственный шаг в решении проблемы. Ментальные модели легко понять, если их поставить перед вами. Их нелегко придумать. Он отлично учит нас, как их придумывать. Я по-прежнему считаю это очень сложным, но мне гораздо удобнее с этим процессом, чем неделю назад, и я бы сказал, что это довольно резкий сдвиг за довольно короткий промежуток времени ... осталось еще 2,75 месяца ... назад к учебе (да, студенты Capstone работают по субботам).
Ознакомьтесь с остальной частью серии Capstone:
Заключительная неделя 2: Рекурсия и динамическое программирование
Заключительная неделя 3: мастерство против комфорта
Заключительная неделя 4: Решение проблем на плечах гигантов
Итоговая неделя 5: Ноу-хау бесполезно без знаний и навыков, как изучать фреймворки, как инженер
