Кодинг — это просто, а вот программирование — совсем другое дело
В моей жизни был период когда я только начинал заниматься программированием. Я тогда думал: «Программировать так просто… Зачем люди специально ходят учиться этому?», но с опытом и образованием пришло понимание, что программирование — дело трудное.
То ли программирование — это легко, то ли я просто ничего не понимаю. MemeGenerator.net
Оценка своих успехов всегда была важна для меня, поскольку в конечном счете неважно, что думают остальные, важно что думаешь о себе ты. Анализируя свой опыт, я размышлял о сильных и слабых сторонах, образовании, практике и личностном росте. Этот процесс позволял мне учиться новому и размышлять о том, что значит быть программистом.
Кодинг, программирование и стучание по клавишам
«Опыт научил меня, что все это время я на самом деле лишь неистово стучал и бил по клавишам, а не программировал»
Программирование требует вдумчивого подхода и понимания различных типов данных, структур, а также технологий, ради обслуживания которых были придуманы языки программирования. Разница заключается преимущественно в выборе процесса, который используется в работе над конкретными задачами. Я уделял основное внимание не типам данных или алгоритмов, паттернам проектирования, производительности или чему-либо еще, связанному с качеством кода и приложений. Вместо этого, акцент делался на рабочем механизме и его эстетической составляющей, что часто приводило к появлению на свет огромных неукротимых чудовищ. Это сопровождалось лихорадочным тестированием выходных данных до тех пор, пока результат не начинал хотя бы немного походить на фичу. Все это давало мне некоторое ощущение того, что я занимаюсь программированием, однако мой подход нельзя было назвать прагматичным или продуманным.
Размышляя о данных
Структуры данных — область, благодаря которой я понял, насколько мне не хватает образования. Основная идея заключается в том, что у Вас есть различные способы хранения, вызова, сортировки и поиска по данным. Когда я только начинал программировать, я никогда не задумывался о различных задачах по работе с данными и производительности при работе с теми или иными типами данных. Очень часто я по умолчанию пользовался массивами (в том числе хэшами, json, словарями и другими терминами для наборов данных с доступом по именам полей) всякий раз, когда требовалось сохранить набор, отсортировать его или обработать в цикле.
Наборы, стэки и очереди казались мне очень интересными с точки зрения информатики, но когда дело доходило до их применения на практике в Ruby, мой энтузиазм уменьшался. В моем понимании стэки и очереди — одно и то же. Они позволяют вам получить информацию с разных концов набора данных. Единственное отличие очередей в том, что в них вы можете получить только объект, добавленный первым. Познакомившись с этими понятиями, я представлял их себе как помещение объектов в список обработки, в теории позволяющий снизить нагрузку и отправить несрочные задачи для фонового выполнения. Однако практическое применение на высокоуровневом языке программирования, таком, как Ruby выглядит практически бессмысленно, поскольку весь процесс, по сути, представляет собой заталкивание элементов в массив или изменение положения в нем.
К примеру, реализовать стек на Ruby можно с помощью вот такого простого кода:
С очередями все примерно также в плане типов создаваемых данных. Вдобавок к этому в Ruby есть свой класс для очередей:
Несмотря на свою простоту, по сути, перед нами обычный массив. В этом безусловно есть своя красота. В общем я могу представить себе их потенциальную пользу в скриптах командной строки, однако в остальном мне трудно навскидку придумать, где еще им можно найти применение.
Двоичные деревья поиска вызывают у меня неподдельный интерес из-за оптимизации времени поиска, которой они позволяют добиться и скорости получения выборки. На практике я часто с легкостью извлекал данные из массивов, но по мере увеличения размера массива поиск по нему начинает занимать много времени. Вот где в игру вступают бинарные деревья поиска, описанные в этом классном видео Гарварда. И хотя мне еще не довелось воспользоваться ими на практике, я очень хочу попробовать сделать это в реальном проекте чтобы сравнить этот алгоритм с нативными методами работы с массивами в Ruby и посмотреть, насколько быстро бинарные деревья будут работать в сравнении с обычными массивами или хэшами. В ходе их изучения и попытках найти способы и сценарии их применения, я нашел вот эти интересные статьи:
Удобство сопровождения
Мое первое веб-приложение было написано просто из рук вон плохо с точки зрения удобства сопровождения. Я совершенно не пользовался какими-либо требования к оформлению, паттернами проектирования, порядками определения методов, пространствами имен, объектами или моделями. Если бы мне пришлось вернуться к коду, чтобы пофиксить баги (которые, я уверен, там есть), вероятно проще было бы переписать все с нуля, нежели пытаться определить метод, вызывающий баг.
Плохой дизайн порождает спагетти-код. Спагетти код порождает страдания
Одной из проблем, решение которой давалось мне с трудом, были вложенные условные операторы и циклы. В таких циклах зачастую есть целый вагон if-утверждений и проверок, однако эта проблема на самом деле вытекает из другой — непонимания того, как следует правильно организовывать и разделять различные части программы. Я пытался выполнить все в больших методах и не обращал внимание на отдельные составные части, которые можно было использовать повторно или создавать в качестве модулей, расширяющих функциональность всех объектов или методов. Ниже реальный фрагмент программы, сокращенный и измененный чтобы сэкономить место.
Я конечно не собираюсь перекладывать вину на кого-то другого. Это код был написан мной, и отвечаю за него я, но все могло быть лучше, будь у меня наставник, возможность отправить код на обзор или pull-реквесты. Сегодня мне стыдно смотреть на это код, но есть и положительный момент, поскольку это говорит о том, насколько я вырос как разработчик. Следует также упомянуть о свободе и ограничениях, с которыми я столкнулся. Для этого проекта я был вынужден работать на LAMP-стеке, и вопрос этот обсуждению не подлежал. В то же время это было единственным ограничением. Мне не нужно было пользоваться паттернами проектирования или статистическими анализаторами и следовать каким-либо стилевым гайдам или политикам по формату кода. Это создает систему, в которой разработчик волен делать все, что посчитает нужным, но незнание о продолжительности жизни приложений и баг-фиксах может серьезно отразиться на конечном результате.
Со временем я стал по-настоящему ценить текстовые редакторы и экономию времени, которую они обеспечивают, анализируя потенциальные ошибки в коде по мере его написания. Но, кроме того, я также начал ценить и другие более мелкие, связанные с программирование подробности. Хорошо написанная кодовая база, следующая стандартам документации, четким требованиям и руководству по стилевому оформлению читается также бегло и просто как электронное письмо или интернет-статья (при условии, что иногда используемый язык программирования сам по себе этому способствует). В целом я также понял, что мне очень нравятся многие принципы, описанные в книге Clean Code A Handbook of Agile Software Craftsmanship Роберта Мартина и других авторов.
Разработка посредством тестирования
Преимущества разработки через тестирование, на мой взгляд, говорят сами за себя, но я понимаю, что не все согласны с тем, что тестирование несет какую-либо ценность для кодовой базы. Не буду спорить про обоснованность тестирования, но хочу поделиться с вами тем, как она помогла мне. Написание интеграционных и модульных тестов для кода еще до его фактического создания оказало мне немалую помощь. Этот подход позволил мне писать более чистый код, делать это эффективнее, и справляться с задачами, решение которых вызывает у меня затруднения.
Написание более чистого и эффективного кода находится на пересечении многих других хороших практик программирования. Разработка через тестирование, в частности, помогла мне улучшить читабельность, производительность и скорость написания. Я обнаружил, что научился писать код, который не нуждается в перепроектировании (или нуждается в нем гораздо меньше) перед отправкой в продакшн или систему контроля версий. Тестирование помогло мне не только снизить количество багов, но и количество времени, которое я затрачиваю на их отслеживание и исправление. Я обнаружил, что во время исправления бага я могу взять ожидаемый ввод или вывод, написать соответствующий тест, и поработать над тем, чтобы этот и все остальные тесты начали давать корректный результат. Это позволяет устранить баг, а код при этом продолжает делать то, что ему положено.
Разработка через тестирование помогает мне упорядочить мысли до начала написания методов или объектов. В случаях написания более комплексных фич, она помогает мне разбить ее на минимальный набор элементов, который необходим для ее корректной работы. Часто она напоминает мне о полезности написания псевдо-кода, поскольку текущие тесты рано или поздно теряют свою полезность и нуждаются в изменениях по мере развития самого кода. Однако в целом пограничные случаи есть пограничные случаи: продумывать их заранее во время создания кода гораздо сложнее. В сухом остатке я считаю, что разработка посредством тестирования помогает мне как программисту расти.
Кодинг стал частью поп-культуры (а программирование – нет)
Автор (издание РБ.РУ).
Атилла Ваго (Attila Vágó), веб-разработчик, инженер по материалам и контенту eLearning, рассказал Hackernoon, чем отличается кодинг от программирования и почему он становится все более популярным.
Кодинг стал частью поп-культуры. А программирование — нет.
И я объясню, почему.
Пятнадцать лет назад мне советовали стать программистом из-за того, что я был интровертом и стеснительным человеком, а также имел аналитический склад ума и полное отсутствие социальной жизни, но я лишь посмеялся и отмахнулся от таких советчиков. Тогда я был подростком, и в моем подростковом представлении программист вечно жил в подвале родительского дома, был прыщавым и носил уродские очки, у него никогда не было девушки, но это окупали фантазии о принцессе Лее (и довольно частые). Такой образ жизни был мне не по душе. Вдобавок, тогда у меня уже была девушка, и довольно красивая.
Кем я не хотел стать.
Перенесемся на шесть лет вперед: я сижу в аэропорту Будапешта и читаю книгу о HTML…
Спустя еще шесть лет меня взяли в североирландскую стартап-компанию в качестве широкопрофильщика. Да, похоже, на это ушло определенное время. Но сколько именно? Не могу сказать точно. Но много. Мифические 10 тысяч часов? Нет. Если бы меня попросили назвать приблизительную цифру, то я бы сказал, что к тому дню я «накодировал» около 8 тысяч часов. Технически говоря, если верить правилу 10 тысяч часов, то через 2 тысячи я стал бы экспертом в этой области.
Но стану ли?
Вот, чего мне удалось достичь за 8 тысяч часов. Усаживайтесь поудобнее, так как мой рассказ будет долгим. Я кодил на следующих языках: C, HTML, CSS, JavaScript, Java (Android), Swift, PHP, Ruby, Python, Chuck, SQL, работал со следующими фреймворками: Node, Angular, Bootstrap, Foundation, React, Rails, CodeIgniter, Ionic и создавал целевые страницы, сайты вордпресс, решения по электронной коммерции, контент электронной среды обучения (eLearning), сайты Moodle и Totara, сайты Mahara, пакеты Common Cartridge и SCORM, программы для Android и iOS, гибридные программы, внутренние веб-приложения, электронные книги, журналы, игры, а также дополнительные приложения для настольных игр. Итак, к чему я веду?
Я хочу сказать, что области как таковой нет, поэтому задача стать в ней экспертом является недостижимой. Кодинг — не область. Информатика — да, но это совершенно другое.
Кодинг — это то, к чему толкают молодое поколение президенты, учителя и родители, словно ведут овец на золотые поля возможностей.
Это обещание — мечта, пропаганда настолько хорошо созданная и выраженная (сейчас ее даже не выражают словами), что ее до абсурда упростили до картинок, чтобы милые ползающие карапузы уяснили, что логическое мышление важнее, чем стремление прокормить себя (прошу обратить внимание на сарказм).
Спустя 15 лет кодинг стал поп-культурной версией программирования, и сейчас население возлагает большие надежды на будущую армию кодеров, благодаря которой у нас появятся управляемые искусственным интеллектом дома, дорожное движение, розничная торговля, развлечения, а также революция в медицине, индустрии и сексе — просто дурдом, другого слова не найти. И все из-за того, что программирование выставляют за кодинг, а его, в теории, легко освоить. Но это так далеко от правды…
Давайте разберемся. Принятый за «факт» миф о том, что любой может освоить один из языков программирования всего за несколько часов, лишь верен до определенного момента, и этот момент настает на ранней стадии обучения. Действительно, язык программирования можно выучить за один день. Вообще, если вы поставили себе цель стать полиглотом в программировании за месяц, при этом имея работу, можно освоить 8-10 языков, если учиться по выходным. Но вот где загвоздка. Каждый язык программирования имеет свои библиотеки, а также синтаксические особенности, и все это нельзя выучить легко или быстро или за выходные. Собственно, в реальном мире язык программирования будет далеко не главной проблемой.
Только то, что вы владеете английским, не означает, что вы сможете писать романы или даже рассказы. Это же можно сказать и про кодинг.
То, что вы выучили язык, вовсе не означает, что вы знаете, как написать программу. Добавим к этому мириады фреймворков, плагинов, библиотек, препроцессоров, постпроцессоров, стандарты кодирования, отраслевые стандарты, разработку через тестирование (TDD), разработку через реализацию поведения (BDD), системы управления контентом, версификацию файлов, непрерывную интеграцию (CI), управление релизами и развёртыванием, отладку, тикетинг, каскадные модели, agile- и scrum-методы, а также их комбинации, и я не уверен, что еще все назвал. Суть в том, что понятие «кодер» охватывает примерно все упомянутое выше. Программирование же затрагивает лишь небольшую часть. Важную, но все же небольшую.
Тем не менее, программирование продолжают упрощать.
Apple запустила Playgrounds, MIT — Scratch, а Lego готовит Boost, и все пытаются продать кодинг молодому и подрастающему поколению, будто хотят заполнить рабочие места новых программистов в 2020-х.
Я это вижу следующим образом: «Не беспокойтесь о коде, возьмите эти виртуальные части пазла и все, вы можете программировать». Если бы такое было правдой. Вот, что нужно знать о программировании: оно основано на тексте. Всегда было и будет на много лет вперед. Дети, играющие в Lego Boost, Playgrounds или Scratch, не станут более опытными программистами к 22 годам, чем те, которые начали изучать программирование с 16 и работали с настоящим языком программирования. Собственно, откуда вообще такие ожидания? Я не думаю, что мой ребенок научится сам зарабатывать на хлеб до 22 лет. А вот если он будет изучать кодинг в течение 6 лет, то я гарантирую, что он быстро найдет работу.
Playgrounds от Apple. Источник: DigitalTrends
Графический интерфейс также не имеет никакого отношения к реальному программированию, а логическому мышлению можно научить ребенка и другими способами. Когда вы в последний раз видели, чтобы ребенок собирал пазл из 1000 частей на столе? Вот именно.
Дети по умолчанию имеют склонность к логике. Собственно, благодаря ей они познают мир.
Они узнают ценность фразы «что-если» с первого дня рождения. «Если я заплачу, то мама все исправит, иначе я продолжу плакать, пока не придет отец (а он, скорее всего, сделает только хуже, но я все равно рискну)». Дети очень логичны, отсюда их нередко жестокая прямота. Вы называете это невинностью, а они — миром, поделенным на черное и белое. У них пока нет множественного выбора. Нет оттенков серого. Все это появится позже в буквальном и литературном смысле (как минимум, в трех томах). В общем, они более чем способны думать логично, но посадите их перед телевизором или позвольте им пользоваться планшетом по 6 часов в день, и все это превратится в кучу искаженных ценностей, так как такие активности обычно не требуют напряженных размышлений.
Кодинг — не музыкальный талант, не пианино и не скрипка, которые потребуются ребенку для развития мышечной памяти. Это инженерное искусство.
Для программирования необходимы аналитическое мышление, стремление к решению проблем, устойчивость к ошибкам, появившихся в попытках найти верное решение, интерес к технологиям, чувство гордости за написанный код и признание замечаний и улучшений другого человека, а также чувство ответственности за свой код.
Поправьте меня, если я ошибаюсь, но все эти качества не так уж легко развить. И уж точно не в возрасте 5 лет! Тем не менее никто не продает кодинг как продукт, которым он является — увлекательный, но сложный путь к открытию, успехи и неудачи и возвращение к началу весь год напролет.
Только то, что кодинг звучит круто, вовсе не означает, что он не является старым добрым «хардкорным» программированием. Если уж на то пошло, то сейчас это более правдиво, чем 15 лет назад. Только сейчас мы носим обтягивающие джинсы, тонкие ноутбуки, вылезли из подвалов и даже можем найти красивых девушек.
Программирование и кодирование. В чём разница?
Кодирование против программирования: Проще говоря, кодирование означает написание кода для программ или веб-разработки. С другой стороны, программирование смотрит на более широкую картину при создании приложений, в то время как кодирование — только один аспект их работы.
Если вы знакомы с миром разработки, вы, вероятно, слышали, что термины кодирование и программирование взаимозаменяемы. В сознании большинства людей кодировщики и программисты — это одно и то же, и они напоминают человека, использующего язык, понятный только компьютеру, для создания автоматизированных задач. В этом нет ничего плохого, но это ещё не всё, что касается кодирования и программирования. По правде говоря, компьютерное программирование и кодирование отличаются друг от друга. Итак, в чём разница между ними?
Наша статья включает в себя важную информацию, которая даст вам информацию и поможет вам начать принимать решения о своей карьере. Мы покажем вам различия в программировании и кодировании и рассмотрим, как эти действия работают вместе для создания приложений и сайтов, которые делают работу современного бизнес-сообщества. И, что наиболее важно, вы узнаете, как кодирование играет важную роль в общем процессе программирования и как кодирование может способствовать вашему карьерному росту.
Что такое программирование
Определение программиста — это тот, кто создаёт сложные программы, которые машины могут читать и выполнять, то есть программирование включает в себя предоставление законченного набора инструкций для выполнения компьютерами. Если вы можете создать такую программу и убедиться, что в ней нет ошибок, вы можете с гордостью носить свой значок программиста.
Что такое кодирование
На самом базовом уровне кодирование — это акт перевода с человеческого языка на машинный. Кодер многоязычен и работает так же, как и тот, кто способствует общению между людьми, говорящими на разных языках. Когда вы работаете с кодом, вы убедитесь, что компьютер получает предоставленные вами инструкции и информацию. Другими словами, кодирование относится только к процессу написания кода.
Создавая свои приложения, программисты смотрят на более широкую картину, а кодирование — лишь один из аспектов их работы. Когда вы работаете программистом, вы одновременно занимаетесь сложными задачами и кодированием, такими как отладка, тестирование и реализация вашего кода, с конечной целью получить качественный программный продукт.
Наборы навыков программирования
Каждая профессия имеет определённый набор навыков.
К настоящему времени вы понимаете, что программирование и кодирование требуют разных уровней знаний и способностей. Программисту в этой роли проще — чтобы научиться программировать, вам нужно хорошо владеть одним или несколькими языками программирования. Ваша основная задача при программировании — общаться, поэтому чем больше способов вы знаете, тем больше на вас будет спрос. Однако в интересах программиста также развивать свою логику и навыки разработки.
Программистам есть чему поучиться. Поскольку вы несёте ответственность за то, чтобы разрабатываемая вами программа работала и работала должным образом, чем больше вы понимаете этот процесс, тем лучше. Помимо того, что они являются первоклассным программистом, программистам также необходимо разбираться в математике и естественных науках и иметь полное представление о том, как их приложения интегрируются в существующие системы. Вы можете стать полноценным программистом через саморазвитие, высшее образование или учебный курс по продвинутому программированию. Тем не менее, чтобы стать успешным программистом, часто требуются годы опыта.
Как кодирование и программирование работают вместе
Одна большая счастливая семья разработчиков приложений
Теперь у вас есть достойное представление о том, что связано с программированием и кодированием, и как они вписываются в отрасли разработки программного обеспечения. Но чтобы понять сходства и различия, лучше всего понаблюдать за ними в действии. Представим, что программист только что получил заказ на создание мобильного приложения для наблюдения за обезьянами в Центральном парке. Какой процесс разработки и когда в игру вступают кодеры?
Программист начинает с того, что делает шаг назад и планирует приложение от А до Я. Они разрабатывают программу для получения отчётов об обезьянах из различных онлайн-источников и определения выходных и интерактивных компонентов, а также множества других факторов. Затем кодер (который часто является программистом) преобразует эти идеи в код, который компьютер может переварить. Как только кодер сделает своё волшебство, программист может отшлифовать и опубликовать конечный продукт.
Хотя может показаться, что они одной профессии, различия между кодированием и программированием реальны.
Разработка vs Кодинг: в чем разница?
Скот Риздал, разработчик с 30-летним стажем, опубликовал статью, в которой рассуждает, в чем разница между разработчиком и кодером и о важности высшего образования для инженера. Редакция techrocks.ru публикует адаптированный перевод материала.
Сейчас все говорят о недостатке ресурсов для разработки и что с этим делать. Часто разговор фокусируется на необходимости иметь ”кодеров”, как будто разработка ПО это производственный процесс и сводится просто к написанию кода. Да, технически вы не можете получить приложение без кодирования, но так ли это всё просто? Вот список требований — просто идите и закодируйте это?
Давайте копнем немного глубже…
Например, вы хотите создать ПО, которое делает что-то такое специфичное, что вы не можете просто использовать готовое решение. Разработка может быть дорогой, но вы чувствуете, что она легко и быстро окупится и увеличит продуктивность и ценность ПО для пользователей. И у вас есть только один шанс сделать все правильно. Кому в таком случае вы доверите разработку вашей идеи?
Есть причина, почему разработка называется разработкой
Разработка ПО – это вид инженерии. Если все правильно сделано, вы получите продукт, который предоставляет необходимую функциональность, обрабатывает все непредвиденные действия пользователя и других внешних систем. Он будет легок в поддержке и выдержит проверку временем. Когда вы строите продукт с нуля, продуманные дизайн и разработка просто необходимы на каждом уровне построения решения. Лучший архитектурный дизайн может быть испорчен какой-нибудь мелочью. Так же, как и плохо спроектированная часть может испортить в целом хорошо спроектированную машину.
Если вы не живете в лесу, вы слышали, что сейчас существует недостаток разработчиков ПО, или, как их иногда называют, ”кодеров”. Существует много способов бороться с этим, но наиболее очевидный способ – это учебные курсы. Это такие школы, которые предлагают пройти интенсивную краткосрочную (около 12 недель) программу по обучению студентов написанию и кодированию приложений. Сравните это с четырехлетним университетским обучением по информатике, которое включает интенсивные тренинги по проектированию ПО, кодингу и высшей математике, не говоря уже о факультативах и публичных выступлениях. Даже в этом случае, выпускникам требуются месяцы тренингов на работе и менторинга до того, как они действительно станут инженерами.
Быстро, Хорошо или Дешево: выбери два
Почему же всё это образование и обучение имеет значение? Ощутимые и быстрые результаты впечатляют, но менее очевидный и время-затратный результат, который создает профессиональная команда – это приложение, которое не потребуется в итоге переписывать и которое не станет нестабильным при добавлении или изменении функциональности. Например, одна из наоболее часто встречающихся ошибок среди неопытных кодеров – это незнание, куда поместить код для новой функции. Тенденция такова, что они кладут всё в одно место, или, что еще хуже, копируют во множество мест, а также предоставляют неполное решение, которое не покрывает все Use Cases. Это происходит потому что шаблоны проектирования не всегда очевидны для неопытного разработчика, и просто знаний о кодинге и базовых логических навыков недостаточно, для того чтобы разобраться в сложном приложении. А подход инженера-программиста – это анализировать требования, разделяя их на бизнес-логику, пользовательский интерфейс и данные, определять лучший способ разработки функциональности. К сожалению, разница между этими подходами не очевидна до тех пор, пока вы не получите на руки нестабильное, требующее поддержки хранилище кода.
Как и в любых сложных ситуациях, если ”вы не знаете, чего вы не знаете”, вы можете получить кучу проблем. Дипломированные инженеры-программисты знают, как найти пробелы в своем мышлении, и будут искать способ заполнить их до разработки решения. Интересная статистика от 2017 Stack Overflow Developer Survey показывает, что дипломированные разработчики придают большое значение образованию.
„…дипломированные специалисты в области компьютерных технологий и компьютерной инженерии сказали (49.4%), что образование было важно или очень важно.„ Stack Overflow
Кодеры имеют право на существование, а учебные курсы предоставляют отличные возможности для тех, кто хочет войти в индустрию. И какой-то процент учащихся имеют врожденный талант к работе, что в итоге сделает их инженерами. Но давайте перестанем думать, что есть легкий способ создания инженеров-программистов, когда в 21-ом веке так много зависит от надежного ПО. Мы же не нанимаем инженеров, прошедших курсы, чтобы они спроектировали и построили наши дороги и мосты. Так почему тогда мы так поступаем в информационных технологиях? В следующий раз, когда собираетесь аутсорсить разработку ПО, по крайней мере спросите компанию об образовании и опыте их команды разработки.