программирование теория или практика
👨🎓️ Нужны ли программисту математика, английский язык, теория алгоритмов и паттерны проектирования?
Иногда возникают нюансы. Вам приходится не только писать код, но и формализовать задачу, поставленную заказчиком на манер знаменитого «копать от забора и до обеда». Или ваш код, написанный «на коленке» за пару минут, работает слишком медленно. Или ваша программа выдает исключение, давно описанное на stackoverflow.com, но вы не умеете читать по-английски. Или возникает необходимость сделать рефакторинг кода, а для вас это звучит как «харакири». Как правило, начальству наплевать на то, как вы справитесь с этими проблемами, но справиться вы обязаны – «вы же программист»! За что же вам платят эдакие деньжищи?
Математика
Давным-давно, когда компьютеры были большими, а зарплаты программистов – маленькими, каждый программист был математиком. Помните главного героя «Понедельника начинается в субботу» братьев Стругацких, программиста Сашу Привалова?
— Кристобаль Хозевич, – сказал я. – Я ее все-таки решил. Вы были совершенно правы. Пространство заклинаний действительно можно свернуть по любым четырем переменным…
…Я отдал ему листки, он сел рядом со мною, и мы вместе разобрали задачу с начала и до конца и с наслаждением просмаковали два изящнейших преобразования, одно из которых подсказал мне он, а другое нашел я сам…
– Это мы опубликуем. Это никому не стыдно опубликовать.
Аркадий и Борис Стругацкие, «Понедельник начинается в субботу»
На минуточку: обычный программист (пусть даже заведующий вычислительным центром) знал математику настолько хорошо, чтобы придумать в ней что-то новое, достойное публикации! То есть, фактически был профессиональным математиком. А как же еще? В те времена считалось, что программист должен уметь самостоятельно формализовать задачу, и только потом написать программу для ее решения.
В моем дипломе, полученном на факультете прикладной математики, гордо значится специальность – математик. Хотя все понимали, что нас учат на программистов. Нас научили использовать численные методы для решения сложных задач, которые нельзя решить аналитически – например, уравнения теплопроводности. Пригодилось ли это на практике? Пока нет, но еще может пригодиться. Если говорить о нужности для программиста, всю высшую математику можно разделить на три части:
Дискретная математика
Этот раздел математики изучает конечные структуры и содержит множество различных подразделов. Самый важный подраздел для программистов – это математическая логика, в которую входит обработка привычных каждому программисту логических операций вроде and, or, и not. Например, следующий оператор срабатывает, если верно a, но не b, или, наоборот, верно b, но не a:
Если вы изучали дискретную математику, то сразу поймете, что то же самое можно написать гораздо проще, используя операцию «исключающее ИЛИ», причем код будет не только намного короче, но и станет работать быстрее:
Математическая логика также помогает «инвертировать» логические выражения или упрощать их, что может потребоваться программисту буквально каждый день:
Еще один важнейший раздел дискретной математики для программистов – это теория графов. Если слово «граф» для вас ассоциируется с графом Монте-Кристо, а не со структурой данных, состоящей из вершин и соединяющих их ребер, вы рискуете не только провалиться на любом собеседовании, но еще и опозориться:
С чем должно ассоциироваться слово «граф» для программиста
Теория графов имеет огромное значение для программистов, поскольку большинство реально встречающихся на практике сложных задач описываются в терминах графов, и именно в этих терминах описываются алгоритмы решения таких задач. Очень популярным подвидом графа является дерево – это связный граф без циклов. Полное незнание теории графов не позволит вам найти нужные алгоритмы и тем более понять их.
Алгоритмы на графах очень часто применяются в реальной жизни. Моей первой реальной задачей была визуализация проектных связей изделия, и схема этих проектных связей, разумеется, была графом. Эта задача до сих пор актуальна и популярна.
Английский язык
Если вы не умеете быстро и без напряжения читать книги по программированию на английском языке – это значит, что вы просто не сможете постоянно следить за передним краем даже в своей области, не говоря уже о смежных. Конечно, российские издательства выпускают переводы книг по программированию, но к моменту их выхода на Западе уже успевает выйти новое издание. К тому же качество этих переводов настолько плохое, что я предпочитаю читать книги в оригинале, то есть на английском. Зачастую электронные версии самых свежих книг на английском языке появляются задолго до их печати, то есть я могу осваивать новые технологии одновременно со всем миром. К тому же, книг по программированию выходит так много, что далеко не каждая из них вообще будет переведена на русский!
Иногда вам придется и написать абзац-другой – например, задать вопрос на форуме или в отдел технической поддержки. Поскольку писать сочинения вроде «London is the capital of Great Britain» вам едва ли понадобится, это не должно вызвать особых трудностей, если вы уже хорошо умеете читать. Даже если вы сделаете пару ошибок, не страшно – лишь бы вас правильно поняли.
Многие фирмы работают на Запад, и там регулярно проводятся совещания на английском языке. Вот там вам уже понадобятся и разговорные навыки, и аудирование, и даже хорошее произношение. Такие фирмы прямо пишут в своих вакансиях что-то вроде «English – Upper-Intermediate». Высококлассному специалисту с большим опытом должно быть очень обидно упускать такие вакансии только из-за незнания языка.
С другой стороны, многие фирмы устраивают своим сотрудникам бесплатные курсы английского языка. Не упускайте эту возможность! Знание языка – это не излишество, а необходимость. Несмотря на то, что сам код можно писать, не зная даже английского алфавита.
Теория алгоритмов
Теория алгоритмов оценивает не точное количество ресурсов (которое на практике редко можно рассчитать), а характер его зависимости от размеров исходных данных, называемой сложностью. Например, цикл по всем элементам массива имеет вычислительную сложность O(N), где N – количество элементов массива. Это значит, что количество вычислительных операций пропорционально N. Общеизвестно, что сложность быстрой сортировки (в среднем) равна O(N * logN), а сложность бинарного поиска – O(log N). Поиск в хеш-таблице происходит еще быстрее: при правильно подобранных ключах и достаточном размере таблицы его сложность O(1), то есть вообще не зависит от размера входных данных! Этим и обусловлена широкая популярность хеш-таблиц, а также базирующихся на них словарей (dictionary) и множеств (set).
Использование неоптимального алгоритма – это мина замедленного действия, заложенная под ваш продукт. Предположим, что вы взяли на работу новичка, не знающего, что такое бинарный поиск. Как, по-вашему, он будет искать нужный элемент в массиве? Правильно, перебором всего массива – то есть операция, которая даже для миллионов элементов должна занимать несколько секунд, у него займет несколько дней, недель или даже месяцев. Именно поэтому тимлид должен отлично разбираться в теории алгоритмов, чтобы не брать на работу тех, кто не знает даже ее основ, а также помогать своей команде искать и придумывать лучшие алгоритмы.
Теоретически, вы можете писать код, и не зная об алгоритмах, но это будет код школьника-троечника. Причем страшнее всего то, что вы этого даже не почувствуете! Если вам не хватает английского языка – это всегда очевидно: вы не можете понять текст, постоянно лезете в словарь, или, что еще хуже, пользуетесь автоматическим переводчиком. Если вам не хватает математической подготовки – вы, конечно, не сможете обнаружить нехватку самостоятельно, но хотя бы почувствуете, что чего-то не понимаете. А вот люди, ничего не знающие об алгоритмах, не получают никаких «звоночков». Они успешно пишут код, который прекрасно проходит все тесты (поскольку размер данных в тестах обычно невелик), но у пользователя работать не будет.
Поэтому теория алгоритмов программисту действительно необходима, она применяется практически каждый день. При этом не обязательно уметь придумывать новые алгоритмы самостоятельно, но оценивать сложность своих алгоритмов и искать более эффективные алгоритмы для ваших задач точно нужно уметь.
Паттерны проектирования
Пожалуй, впервые важность проектирования была продемонстрирована в книге Ф.Брукса «Мифический человеко-месяц», вышедшей в далеком 1975-м, но она была ориентирована на менеджеров, а не на программистов. В 1994-м Э. Гамма, Р. Хелм, Р. Джонсон и Д. Влиссидес (называемые «бандой четырех», «Gang of Four») опубликовали книгу «Паттерны объектно-ориентированного проектирования», заложившую основы современного подхода к проектированию ПО. В книге описано множество типовых приемов (которые авторы назвали «паттернами»), помогающих улучшить проекты проекты программ, и это стало основным фактором ее популярности. Стало модно задавать вопросы по паттернам проектирования на собеседованиях, и юные соискатели начали заучивать их наизусть. (Я не рассматриваю SOLID, появившийся позднее, поскольку он слабо помогает проектировать – но заучить его для собеседований вам тоже придется).
К сожалению, навыки кодирования и проектирования очень сильно отличаются друг от друга, так что гениальный проектировщик вряд ли окажется еще и супер-кодировщиком (а когда такое все же случается, в мире появляется очередной Линус Торвальдс). Типичный кодировщик – это юноша, очень быстро набирающий код, то есть обдумывающий его еще быстрее. Типичный проектировщик – это человек с большим опытом, который может не набрать ни одной строки кода на протяжении нескольких дней или даже недель. Его задача – придумать наилучшую архитектуру продукта, вот он и думает. Разумеется, кодировщики, ничего не знающие о проектировании, считают проектировщика просто бездельником! Именно поэтому крупные компании не ставят проектировщика в подчинение руководителю команды кодировщиков, а придумывают для него особую должность «архитектора» (software architect).
Отличный пример широко распространенного, но неправильного понимания паттерна проектирования дает паттерн Bridge (Мост). Начнем с правильного примера использования этого паттерна на C# (код взят из документации Microsoft):
Интерфейс IDBConnection реализует Мост между клиентским приложением и базой данных (БД). Цель паттерна – полная изоляция клиента от деталей реализации каждой конкретной БД. Конкретным объектом, реализующим этот интерфейс, может быть любой экземпляр класса, унаследованного от DBConnection (код создает экземпляры SqlConnection, OdbcConnection и OleDbConnection), но клиент никогда не должен узнать, какого именно. Это позволяет разработчикам клиентского приложения сделать его по-настоящему мультиплатформным, а разработчикам Моста – постепенно добавлять поддержку новых БД, которая не заставит разработчиков клиента ничего менять. Важная парадигма: для клиентского приложения оба «берега», соединяемых Мостом, всегда представляют одно и то же (в нашем примере – БД), только на «его» берегу находится абстрактное представление о БД, а на «чужом» – ее конкретная реализация.
Теперь взгляните, какой «пример Моста» приведен на сайте Метанит. Там объект программиста обращается к объекту языка программирования через «мост». Непонятно, зачем изолировать объекты языков программирования от объектов программистов, но проблема даже не в этом. Во-первых, вы не можете заранее предсказать все, что вам потребуется от языков программирования – а это значит, что ваш «мост», скорее всего, через некоторое время придется изменять, тогда как одна из целей настоящего Моста заключается именно в защите клиента от изменений (как вы думаете, будет ли когда-нибудь изменен IDBConnection?). Во-вторых, вы не можете раз и навсегда определить даже вид соотношения между языками и программистами! Кто сказал, что каждый программист знает только один язык? Такие «мосты» только напрасно усложняют проект и не приносят никакой реальной пользы.
А вот пример того же паттерна с сайта Refactoring Guru. Здесь строится «мост» между пультами и управляемыми с их помощью устройствами. Этот пример уже имеет смысл, поскольку управлять с пульта проще, чем кнопками на устройстве (клиенту всегда проще работать с абстрактным интерфейсом Моста, избавляющим его от ненужных деталей реализации), но все-таки он неудачен. Не все команды управления телевизором и радио будут совпадать. Но самое главное – пульт не скрывает от клиента конкретную реализацию: клиент по-прежнему смотрит телевизор, а не пульт, и слушает радио, а не пульт. А мы уже знаем, что основная цель Моста – именно изоляция клиента от конкретной реализации.
Удачи вам в определении того, чего вам не хватает, и успешного устранения этих пробелов!
Можно ли научиться хорошо программировать если сначала теория потом практика?
Простой 3 комментария
сначала теория потом практика
Практика первична все же
можно ли научиться программировать на высоком уровне(сеньйор), если сначала теорию часа 3 изучать, потом практика часа 2 в день.
ходить в вуз, а там полная фигня
Если вам так сложно учиться в вузе, а потом учиться самостоятельно, то может быть вообще не стоит идти в ИТ?
Там в области манкикодинг очень высокая конкуренция, по сравнению с тем, что было 20 лет назад.
Таким образом через полгода я знал базовый стек по типу HTML, CSS, JS на более-менее хорошем уровне. С того момента уже около трех лет прошло, все также в свободное время смотрю курсы (уже вошло в привычку в свободное время открыть его на телефоне и залипнуть), делаю сайдпроекты, работаю.
Программирование для начинающих: как стартовать и куда двигаться?
Бывает, что человек, совсем не связанный с IT, проникается интригующей красотой этой сферы и ставит себе задачу постепенно освоить программирование с нуля. И тут он зачастую просто теряется, не понимая, с чего начать, и нуждаясь в хорошем фундаменте и системном подходе.
Я, будучи недавно в такой же ситуации, гуглила, искала мануалов на Хабре (кое-что нашла: Десять советов начинающим программистам, Начинающему программисту про стартапы и не только…), но в итоге всё же была вынуждена обратиться за советом к одному хорошему человеку, который составил для меня вот такой план. С разрешения этого человека размещаю данный план на Хабре – вдруг он пригодится и кому-то ещё. (Тем более, что перечисленные книги относятся к «золотому фонду» литературы в данной сфере и проверены временем.)
UPD: Новичкам советую обратить внимание на комментарии — там активно и аргументированно корректируется этот план.
Нортон «Программно-аппаратная организация IBM PC»
Эта книга, несмотря на свою давность, относятся к тем, что пока отнюдь не устарели. Как новичок подтверждаю – повествование вполне понятно и для почти полного чайника в IT.
Гук «Аппаратные средства IBM PC»
А эту книгу стоит прочитать «поверх» – она расскажет о том, как дела в данной сфере обстоят сейчас.
Морс, Алберт «Архитектура микропроцессора 80286»
Почему тут берётся за основу именно микропроцессор 80286 – станет понятно по изучении трудов первого этапа.
Гук «Аппаратные интерфейсы ПК»
Гук «Интерфейсы устройств хранения»
Этап III. Операционные системы
Таненбаум «Архитектура компьютера»
Колисниченко, Аллен «Linux: полное руководство»
От общей теории переходим к изучению конкретной операционной системы – на примере Linux.
Немет, Снайдер, Хейн «Руководство администратора Linux»
Этап IV. Собственно программирование
Керниган, Ричи «Язык программирования С»
Почему первым для освоения выбран именно язык Си? Как мне рассказали знающие товарищи, он поможет достичь правильного «программистского мышления», чего было бы сложно достичь, начиная изучение, скажем, с Паскаля. Кроме того, язык Си по-прежнему используется в наши дни и подходит как для прикладного, так и для системного программирования.
Кнут «Искусство программирования»:
Том 1. Основные алгоритмы
Том 2. Получисленные алгоритмы
Том 3. Сортировка и поиск
Бентли «Жемчужины программирования»
Зачем осваивать эти труды? Как уже отмечали на Хабре – «наверное, нигде больше, чем в айти, не изобретается такое огромное количество велосипедов». Данные книги помогут этого избежать – и попутно будут прививать умение писать не просто код, а хороший код.
Ну а для затравки можно прочесть небольшой цикл лекций «Культура программирования» (автор – А. Бабий). Он помогает начинающим программистам понять, что их деятельность не будет проходить в вакууме, а неизбежно включит взаимодействие с другими программистами, с заказчиками и пользователями (а также включит необходимость копаться потом в своих собственных или в чужих программах).
Закономерный вопрос новичка: сколько времени займёт изучение всего этого? По прогнозам моего советчика, у человека, который может тратить на изучение программирования только вечера и выходные, на прочтение и осмысление литературы первых трёх этапов уйдёт полгода-год. На четвёртый этап тоже даётся год – чтение должно сопровождаться практикой по самостоятельному составлению программ. Как получится на самом деле – время покажет.
Буду крайне благодарна за ваши советы и уточнения.
Практика vs Теория или зачем нужно высшее образование?
Дмитрий Симонов, CTO, создатель канала «Техдирские заметки» задал интересную дискуссию. Практика vs Теория или зачем нужно высшее образование?
Битвы вокруг практики vs теории хватает. Не менее, чем на «ганзах», что лучше AК или AR-15, или Кольт 1911 или Глок 17. Чем мы, айтишники хуже?
У меня на одном проекте был менеджер, который свои теории пытался внедрять в работу, чем ужасно её удорожал. Получал он от этого извращённое удовольствие или нет — истории не известно. Про него крутили пальцем у виска, так и называя: «теоретик». Получалось, прямо как в D&G — нет, не Дольче и Габбана, а дорого и глупо. Хоть и работало в итоге, если не мешать его шаловливым рукам. Что только что через его руки не прошло в первые недели появления — и Kubernetes, и Prometheus, и Ceph.
На другом проекте есть мужик, который вместо того, чтобы правильно настроить всё, чтобы работало, так вот кидается во все процессы — и сам всё делает. Так как он практик и знает, как правильно. Но работа в целом стоИт, потому что чувака на всё не хватает. Две руки, две ноги, посередине гвоздик. Но голова светлая, что лампочка Ильича. Ж### полная (это не про размер, а про наполненность!)
Практики — это те, кто прошёл поля граблей и накопил в голове набор кейсов, которые знает как решать.
Теоретики, — это те, кто знают, как вообще всё устроено, но практики нет.
Практики — это те, кто умеют ловить известные проблемы.
А теоретики — это те, кто могут подсказать практикам, как решать неизвестные проблемы.
Что важнее? Решать известные проблемы и неизвестные?
«Пирамида Дейла»: правда ли, что обучение на практике лучше любой теории?
Эта теория предлагает простое решение сложных задач, но не имеет доказательств. Похоже, это просто миф.
Из этой статьи вы узнаете:
Если вы часто читаете литературу об обучении, то наверняка слышали о «пирамиде Дейла» — теории, гласящей, что человек запоминает в среднем 10% прочитанного, 20% услышанного, 30% увиденного и 90% того, что сделал сам. Проценты в разных трактовках могут меняться, но суть остаётся той же: якобы активное обучение на реальном опыте всегда лучше, чем любой другой подход. Идея звучит заманчиво, но есть одна большая проблема — с самого её зарождения не было ни одного достоверного исследования, которое бы её подтверждало.
Журналистка. Пишет про исследования в сфере образования и пытается разрушить все вредные нейромифы. Любит онлайн-курсы и философию стоиков. Разбирается в поп-культуре и ратует за её использование в процессе обучения.
С чего всё началось
Кен Мастерс из Университета имени султана Кабуса в 2019 году провёл подробный анализ использования концепции «пирамиды Дейла» в медицинском образовании и выяснил, что впервые похожая идея была представлена в статье Чарльза Роудса 1906 года. Там указывается, что «мы запоминаем одну десятую того, что мы слышим, пять десятых того, что видим, семь десятых того, что говорим, и девять десятых того, что делаем». Роудс помещает цитату в кавычки, но источник не указывает — так что, вероятно, и до него это убеждение было распространено.
В 1950-х американская Национальная учебная лаборатория (National Training Laboratories, NTL) опубликовала свою версию пирамиды.
По заявлению организации, эти процентные значения были установлены в процессе исследования NTL, однако найти подробную информацию о нём оказалось невозможно.
Неясно и то, как Эдгар Дейл стал ассоциироваться с пирамидой. В его книге «Аудиовизуальные методы обучения» (Audiovisual Methods in Teaching), впервые опубликованной в 1954 году, нет ничего определённо похожего. Однако в этой работе можно встретить «конус опыта» — схему, распределяющую образовательные форматы от самых абстрактных к самым конкретным: вербальные символы → визуальные символы → изображения, аудиозаписи, радио → фильмы → образовательные телепрограммы → выставки → образовательные экскурсии → демонстрации → театрализованная деятельность → симуляционная деятельность → практическая деятельность.
По запросу «Dale’s cone of experience» можно найти различные вариации конуса, в которых каждый тип учебного материала (текст, презентация, фильм и так далее) уже привязан к определённому проценту усвоения информации. Однако в оригинальной идее Дейла этого не было, схема вообще никак не касалась запоминания. Единственная её цель состояла в том, чтобы наглядно представить классификацию.
Третье переиздание «Аудиовизуальных методов обучения» Дейл специально дополнил разделом «Некоторые вероятные заблуждения» (Some Possible Misconceptions), в котором подчеркнул, что его классификация учебных материалов не означает, что конкретные формы обучения эффективнее, чем абстрактные. Как можно понять, его предупреждение не сработало.
Возникает очевидный вопрос: откуда в истории этого мифа вообще возникли проценты? И почему они такие ровные? Даже если бы кто-то действительно провёл исследование, неужели его результаты могли бы быть такими идеальными? Это всё ещё остаётся загадкой.
Почему теория «пирамиды обучения» несостоятельна
Как минимум она не универсальна и не применима к абсолютно любому материалу, и тому есть реальные доказательства.
В статье «Что делать с ухудшающимися оценками по математике в Канаде» (What to Do about Canada’s Declining Math Scores) доцент Университета Виннипега Анна Стокк вывела важную закономерность. Она отметила, что в период с 2003 по 2012 год практически во всех провинциях Канады отмечено резкое снижение баллов учащихся в тестах по математике, которые школьники сдают после восьмого класса. Этот общенациональный спад совпал по времени с переходом школ на учебные программы, основанные на идее «опытного пути».
Согласно этой концепции, ученики должны сами находить ответы, а не получать алгоритмы решений и формулы от преподавателя. Для подобного подхода характерны:
Стокк пришла к выводу, что в случае с математикой дети намного лучше усваивают материал, если сначала им расскажут правила, дадут формулы и объяснят важные принципы, и уже потом начнётся закрепление на практике.
Вопрос об эффективности «пирамиды» также рассматривали учёные Джеймс Лэлли и Роберт Миллер в статье «Пирамида обучения: показывает ли она учителям правильное направление». Они изучили работы, исследующие эффективность разных методов обучения, и пришли к выводу, что каждый из них действенен в определённых условиях и ни один метод не обладает однозначными преимуществами перед другими.
Насколько широко распространился этот миф
Попробуйте ввести в поисковую строку «диаграмма Дейла» или «пирамида Дейла». Вы увидите, как много существует разных вариантов этого мифа. Как мы уже знаем, с момента его зарождения не проводилось эксперимента, который бы подтвердил этот подход. При этом используется идея довольно активно. Если вернуться к анализу уже упомянутого ранее Кена Мастерса, то лишь среди статей по медицинскому образованию, опубликованных в период с сентября 2012 года по апрель 2018-го, была найдена 41 работа с отсылкой к «пирамиде Дейла».
Мастерс также обнаружил, что количество ссылок на пирамиды обучения в медицинской образовательной литературе резко увеличилось по сравнению с периодом до 2012 года. Даже опровержения этой теории порой используются для её поддержки, а исследователи, которые признают недостоверность идеи, всё ещё включают её в свои работы.
Встречается пирамида обучения и в популярной литературе по саморазвитию. Например, в книге про финансовый успех «Почему мы хотим, чтобы вы были богаты» Роберта Кийосаки и Дональда Трампа есть следующий отрывок:
«В 1969 году в рамках системы просвещения было проведено исследование, которое продемонстрировало эффективность различных типов обучения. На базе материалов исследования был создан „конус обучения“. Из него видно, что наименее продуктивным средством обучения являются чтение и лекции, а наиболее эффективным — практическая работа. Между ними занимают положение методы, имитирующие реальный опыт. Не кажется ли вам парадоксальным, что наша система образования всё ещё использует в процессе обучения главным образом чтение и лекции? И это при том, что „конус обучения“ известен уже с 1969 года!»
Почему людям так нравится «пирамида Дейла»
Компания Metiri Group, занимающаяся аналитикой данных, в 2008 году провела исследование «Мультимодальное обучение с помощью медиа» (Multimodal Learning Through Media), в котором подробно разобрала миф о «пирамиде Дейла».
Исследователи предполагают, что люди, добавляющие к схеме американского педагога проценты усвоения информации, чаще всего пытаются найти простое решение комплексной проблемы. В материале об аудиалах, визуалах и кинестетиках мы уже упоминали, что стремление педагогов найти лучший подход к ученикам совершенно естественно. Это желание подпитывает мифы вроде «пирамиды Дейла», но они при этом только создают приятную иллюзию.
Специалисты Metiri Group приходят к выводу, что не существует идеального решения для всех учащихся и любого преподаваемого материала. В некоторых случаях практические занятия действительно более эффективны, но это вовсе не значит, что они подойдут всем или что человеку всегда будет нужен исключительно «опытный» подход, что бы он ни изучал.