На этой неделе я провел некоторое время, проводя «практический» хакатон и ломая голову над алгоритмами. Теперь оба этих модных слова были очень сокровенными для меня и, следовательно, представляли собой вызов, с которым, как я знал, мне придется столкнуться, но я боялся этого.
Как всегда в жизни, в некотором смысле это оказалось немного антиклиматическим. Я построил идею хакатона и алгоритмов как невероятно сложных задач, которые только элитные программисты или те, кто каким-то образом родился с мозгом, способным выдавать блестящие математические утверждения, могли бы выполнить на раннем этапе своего пути программирования. Нет, это просто неправда, ну, эти люди, вероятно, могут и делают, но мы, простые смертные и студенты, изучающие программирование, тоже можем!
Для моей практики хакатона я объединился с некоторыми другими новичками в программировании, чтобы вместе решить некоторые сложные проблемы в установленные сроки. Теперь, в отличие от настоящего хакатона, наши проблемы будут быстро решаться старшим разработчиком, и они, вероятно, смогут решить их в одиночку и примерно за 15 минут, а не за 1 час. Но для нас они были более сложными, требовали от нас общения, и я чувствовал себя наиболее уверенно во время этого опыта. Что было очень и очень неожиданным результатом.
Это укрепило некоторые из моих «мягких навыков», которые абсолютно необходимы для успешной карьеры в сфере технологий, независимо от должности. Это важно для настройки и убеждения товарищей по команде в планировании кода во время хакатона или настройки совместного программирования для решения сложной проблемы.
Это был не единственный раз, и я не буду полагаться на свой опыт управления проектами и академического преподавания. Я был тем, кто держал в фокусе общую картину, заставлял свою команду говорить и озвучивать проблему, чтобы разбить ее на части ДО того, как мы начали кодировать. Это было нелегко, потому что мы все были рады начать решающую часть, но невозможно по-настоящему решить проблему в команде, если мы все не понимаем, что означает проблема, какие шаги мы хотим предпринять для ее решения. . Произнеся это вслух под диктовку, мы смогли убедиться, что у всех нас есть взаимное понимание того, о чем все думают. Менеджер проекта во мне также чувствовал потребность в том, чтобы все чувствовали себя услышанными. Это позволило сделать фактическое кодирование более эффективным, и наши алгоритмы «разделяй и властвуй» не были сложными, поскольку у нас был план, как их разделять и властвовать. А когда появлялись ошибки, мы как команда могли лучше их обсуждать, так как знали, для чего был написан код.
Итак, мои выводы для моих будущих хакатонов и мой анализ структуры, которую мы взяли (с некоторыми напоминаниями о том, что было добавлено в общую картину для верности).
1) Все должны быть на одной волне с целью — всегда удивительно, как одна и та же подсказка или проблема могут быть интерпретированы по-разному, или даже записанные шаги могут быть интерпретированы по-разному. Но в ситуации, рассчитанной по времени и в условиях совместной работы, очень важно, чтобы все были на одной волне с самого начала.
2) Планирование кода или даже первоначальная формулировка логики, стоящей за целью, очень важны — это возможность убедиться, что все, кто использует разные фразы, действительно имеют в виду одно и то же, и все понимают друг друга.
3) Затем запишите все шаги, таким образом, они разбиты на этапы — это похоже на настройку серии подсказок / списков дел, чтобы сделать серию простых задач, которые работают вместе для решения сложной проблемы.
4) Затем выполните шаги один за другим в порядке бизнес-логики или согласованном порядке.
5) Тестируйте инкременты по мере продвижения (модульное тестирование или console.log).
6) В целом, убедитесь, что вы постоянно общаетесь. Исследованием может заниматься один человек или даже команда, а затем обсуждать, какое решение попробовать первым.
7) Делает процесс более эффективным, гарантирует, что каждый будет услышан и внес свой вклад, а также гарантирует, что мы придем к решению таким образом, чтобы это было выгодно всем (превращает его в обучающий опыт)
Теперь перейдем к некоторым алгоритмам и концепциям объектно-ориентированного программирования, над которыми я работал!
Неизменяемость: что это такое, плюсы и минусы?
Неизменяемость является основным принципом функционального программирования и может многое предложить объектно-ориентированным программам. Изменяемый объект — это объект, состояние которого можно изменить после его создания. Неизменяемый объект — это объект, состояние которого нельзя изменить после его создания.
Плюсы
- Программы с неизменяемыми объектами менее сложны для понимания, поскольку вам не нужно беспокоиться о том, как объект может меняться с течением времени. Следовательно, в некотором смысле его легче поддерживать и легче кодировать и читать между разными разработчиками в одной или разных командах.
- Одна копия объекта ничем не хуже другой, поэтому вы можете кэшировать объекты или повторно использовать один и тот же объект несколько раз.
Минусы
- Распространение множества мелких объектов вместо изменения существующих может привести к снижению производительности.
- Циклические структуры данных, такие как графики, сложно построить. Если у вас есть два объекта, которые нельзя изменить после инициализации, как заставить их указывать друг на друга?
Это здорово, но как добиться неизменности в собственном коде?
Существуют библиотеки неизменяемости, такие как immutable.js, mori или immer.
В противном случае используйте объявления const в сочетании с упомянутыми выше методами создания.
Затем, чтобы «мутировать» объекты, используйте оператор распространения, Object.assign, Array.concat() и т. д., чтобы создавать новые объекты вместо изменения исходного объекта.
https://wecodetheweb.com/2016/02/12/immutable-javascript-using-es6-and-beyond/
Что такое алгоритмы "разделяй и властвуй"? Как они работают?
Что ж, мы решили некоторые проблемы «разделяй и властвуй» на нашем хакатоне, и они кажутся относительно распространенными как на собеседованиях по программированию, так и в реальных ситуациях программирования. Его можно разделить на следующие три части:
Разделить: разделить проблему на несколько подзадач.
Conquer: работайте над подзадачами, вызывая рекурсивно, пока подзадача не будет решена.
Объедините: как только второстепенные проблемы будут решены, вы получите решение проблемы.
Некоторые из быстрых примеров задач алгоритма «разделяй и властвуй» включают:
- Бинарный поиск.
- Быстрая сортировка.
- Сортировка слиянием.
- Целочисленное умножение.
- Умножение матриц (алгоритм Штрассена)
- Максимальная подпоследовательность.
https://www.radford.edu/~nokie/classes/360/divcon.html
https://www.geeksforgeeks.org/divide-and-conquer-algorithm-introduction/
Некоторые алгоритмические проблемы: как работают сортировка вставками, сортировка кучи, быстрая сортировка и сортировка слиянием?
Во-первых, обратите внимание, что алгоритмы — это математический термин, но гораздо проще думать о них как о рецептах. Это блоки кода, которые работают вместе, чтобы что-то создать. Когда вы действительно думаете об этом, вы, вероятно, писали, читали и работали с алгоритмами задолго до того, как наткнулись на настоящее слово «алгоритм» в своем путешествии по программированию. Отсюда мое прежнее заявление о том, что мы, простые кодирующие смертные, можем победить их обоих. Но их может быть трудно вспомнить в ситуации стресса, а также они могут быть невероятно сложными. Вот несколько простых, чтобы мы начали!
Сортировка вставками:
Сортировка вставками — это алгоритм сравнения, который строит окончательный отсортированный массив по одному элементу за раз.
Он перебирает входной массив и удаляет один элемент за итерацию. Затем он находит место, которому принадлежит элемент в массиве, и помещает его туда.
Быстрая сортировка:
Быстрая сортировка — это алгоритм сравнения, использующий принцип «разделяй и властвуй» для сортировки массива.
Алгоритм выбирает опорный элемент A[x], а затем перестраивает массив на два подмассива.
Подмассив 1) A[p . . . . x-1] , так что все элементы меньше A[x]
Подмассив 2) A[x+1 . . . r] , так что все элементы больше или равны A[x].
Кучная сортировка:
Сортировка кучей — это еще один алгоритм сравнения, который использует двоичную структуру данных кучи для сортировки элементов.
Он делит свой ввод на отсортированную и несортированную области. Затем он итеративно сжимает несортированную область, удаляя самый большой элемент и перемещая его в отсортированную область.
Сортировка слиянием:
Сортировка слиянием — это алгоритм сравнения, который сосредоточен на том, как объединить два предварительно отсортированных массива, чтобы получить массив, который также отсортирован.
https://www.cpp.edu/~ftang/courses/CS241/notes/sorting.htm
http://www.cs.cornell.edu/courses/cs211/2000fa/materials/Nov16%20Sorting.pdf
Каковы три закона рекурсии алгоритма?
Закон 1) Рекурсивный алгоритм должен иметь базовый случай.
Закон 2) Рекурсивный алгоритм должен изменить свое состояние и двигаться к базовому случаю.
Закон 3) Рекурсивный алгоритм должен вызывать себя рекурсивно.
В базовом случае это означает, что проблема достаточно мала, чтобы ее можно было решить напрямую.
Изменение его состояния и переход к базовому варианту означает, что некоторые данные изменены, и каким-то образом это приближает нас к решению.
Алгоритм должен вызывать сам себя, что по сути представляет собой просто рекурсию.
Я надеюсь, что это поможет любому, кто слышал слова «хакатон» и «алгоритмы», немного меньше испугаться и понять, что да, они могут быть страшными и сложными, но как только мы их разберем, эти два понятия такие же, как и все остальные. часть нашего путешествия по кодированию. Страшная концепция, которую мы затем узнаем и переживаем (иногда проталкиваем), а затем в конечном итоге становимся менее пугающей и, возможно, веселой?! Ну, по крайней мере, весело вне собеседований по программированию.
Ваш друг в коде,
Рэйчел
