Фото используется в иллюстративных целях
На Quora один из разработчиков обратился к пользователям сервиса с вопросом: «Я работаю фейковым программистом, копируя и вставляя код уже около 9 лет. Я хочу научиться программировать как следует, и стать настоящим программистом. Что я должен делать?». Dev.by приводит ответы опытных девелоперов.
Ричард Ледди (Richard Leddy), программирует более 35 лет:
Я только что понял, что сам работал с парнем, который только и делал, что копировал и вставлял код (он даже пытался быть моим боссом). Однажды он показал мне Arduino скетч и сказал, что гордится тем, что сделал его сам. А потом я наткнулся на точно такой же скетч в интернете. И однажды, когда он, грубо говоря, «опускал» меня и мой код, я «взорвался». Дело в том, что я делал свою работу добросовестно и получал гроши. А он ездил на новом мотоцикле, приобрел неплохое жилье и был убежден, что все получают по справедливости.
В конечном итоге я ушел из этой фирмы, но меня не покидает вопрос: почему таким людям, как этот парень, все сходит с рук, когда дело касается денег? А те из нас, кто действительно много лет работает над каждым аспектом нашего ремесла, в результате страдают?
Отвечая на вопрос, как стать настоящим программистом, могу сказать, что вам нужно передать свою работу кому-то, кто владеет реальными навыками, а не фейковыми, и отправиться в монастырь или еще куда-то осваивать профессию. Конечно, на это уйдёт время, вам придётся сесть и начать писать циклы и структуры данных, но другого выхода нет. Вы должны знать хоть что-нибудь о контексте предмета, с которым работаете. Возможно, вам придется выучить алгоритмы и разобраться в железе. Для некоторых из этих задач нужна математика, поэтому вам нужно освежить эту область знаний.
На самом деле я не сочувствую вам: вы, как «копипаст гай», не можете сделать что-нибудь принципиально новое. Вы как машина. Но есть надежда — вы хотя бы честно смотрите на себя. И пока вы не пытаетесь произвести впечатление на окружающих своей «подделкой», не все потеряно.
Курт Гюнтерот (Kurt Guntheroth): 20+ в разработке на С ++.
Вы знаете байку про консультанта, который берёт 10000 долларов за решение проблемы? Когда клиент наблюдает за ним, он подходит к неработающей машине, берёт молот, ударяет им в определённом месте, и устройство начинает работать. После этого консультант объясняет, почему его услуга стоит так много: 1 доллар — за удар молотом, 9999 — за знание, где нужно ударить. Вы — тот самый парень. Копировать и вставлять — проще простого. А вот знать, что копировать и где вставлять — это уже совсем другое дело. Конечно, было бы лучше, если бы вы могли писать код сами с нуля. Тогда вы могли бы делать гораздо больше интересных вещей. Но и при таком раскладе вещей ваш вклад нельзя назвать незначительным, если работа в итоге сделана.
Чтобы ответить на исходный вопрос, могу сказать, что вам нужно пытаться решать каждую проблему самостоятельно, прежде чем вы пойдёте искать решение и копировать. Кстати, а как вы отличаете правильное решение для вставки от множества неправильных? Просто методом проб и ошибок?
Рон Тейтельбаум (Ron Teitelbaum), директор 3D Immersive Collaboration Consulting:
Единственный способ стать программистом — это программировать. Т.е. проектировать и строить реальные программы. Для этого вам нужно разбираться в производительности, масштабируемости, юзабилити, секьюрити и многом другом. Да, скорее всего вы не будете в будущем отвечать за всё сразу, но это поможет вам понять, что есть хорошее программирование.
Мой вам совет — представляйте в уме, как должна выглядеть программа, затем проектируйте и разрабатывайте. Делайте это сначала на листе бумаги, используя псевдокод и продумывая каждый аспект. Запишите требования, дизайн, юзер стори, юзкейсы и пр. Составляйте схемы, разрабатывайте пользовательский интерфейс и пытайтесь понять все, что вы делаете.
Затем соберите лучшие языки, которые подходят для создания вашей программы, учитывая безопасность, масштабируемость, варианты развертывания, простоту использования, актуальность и популярность языка. Заметьте, вы все еще не написали ни строчки кода. Почему? Потому что программирование не связано только с синтаксисом. В конце концов вы поймете, что кодинг — это элементарно. Поэтому на протяжении девяти лет вы и могли копировать и вставлять. Когда ваша работа заключается в том, чтобы выполнять последний шаг сложного процесса, вы не ощущаете челленджа, потому что вся тяжелая работа на этом этапе, как правило, уже сделана.
Джон Бразье (John Brazier), программист:
Очень странный вопрос, потому что, когда вы копипастите, вы уже понимаете контекст — что вы берете и куда вставляете. Этот процесс подразумевает знание языка и понимание того, что вы делаете. Если бы вы просто случайным образом выбирали код для копирования, вы бы не продержались и нескольких недель, и даже в этом случае вам понадобилась бы булшит-дипломатия.
На самом деле ни один программист не обязан поддерживаться 100-процентной уникальности кода. Как правило, он использует только 1 процент нового кода, остальные 99 — уже выполнены, протестированы, гораздо более надёжны, чем мог бы написать любой отдельно взятый программист. Но 1 процент — это то, где происходит само важное, волшебство: нужно знать, как собрать весь этот скопированный код, чтобы он решал твою проблему. И есть огромное количество программистов, которые никогда не делают этот 1 процент должным образом. В этом и есть искусство программирования.
Я делаю вывод, что этот вопрос либо фейковый, либо у вас профессиональное выгорание. Если последнее, не волнуйтесь, за 9 лет вы стали консультантом.
Суйог Гупта (Suyog Gupta), руководитель проектов в Oracle:
Исходя из вашей логики, многие люди/продукты являются фейковыми.
Позвольте уточнить: Starbucks, Dunkins и т. д. — все продают кофе. Они мучаются угрызением совести, думая, что скопировали идею продажи кофе? Нет! Чувствуют ли их клиенты, что платят Starbucks немалые деньги за скопированный продукт? Опять же нет! Ваш код решает проблему, которую вы хотели решить, значит, он уникален. Даже если базовая логика скопирована, это все равно ваша собственность! Пожалуйста, гордитесь этим.
Быть инновационным — это хорошо, но для этого не обязательно обладать чем-то. Нет ничего плохого в том, чтобы копировать и вставлять код в свое решение. Как вы сказали, вы провели 9 лет в этой отрасли, так что, я полагаю, все это время ваши работодатели находили ваш код приемлемым, потому что он решал их проблемы. Если бы это было не так, вам было бы трудно продержаться в индустрии даже 9 месяцев.
Переходя ко второй части вопроса, могу сказать, что пока вы работаете над кодом, который нужен кому-то другому (работодателю), вы не станете настоящим разработчиком. Вы должны найти проблему, которая вас лично беспокоит, и решить ее самостоятельно. Например, несколько лет назад я захотел, чтобы моя музыкальная библиотека находилась в облаке. Я поместил несколько песен на Amazon S3, написал одностраничное приложение на Node.js (оно использовалось для перечисления всех песен из хранилища), создал некоторую логику для добавления трека в плейлист и т. д.
Проделав все это, я многому научился, например, узнал о передаче функции в качестве параметра, функции обратного вызова и т. д. Вы можете сделать что-то подобное, например, расспросить ребенка о его занятиях, экзаменах и т. д. и сделать приложение для школьного расписания. Таким образом вы изучите объектно-ориентированные концепции, структуры данных и т. д.
Стивен Оуэнс (Steven J Owens), разработчик:
Если вы «притворялись» 9 лет, предполагаю, вы имеете какие-то знания и владеете определенной степенью квалификации. Согласно эффекту Даннинга-Крюгера, умные люди лучше осознают, как многого они не знают.
Не поймите меня неправильно, но чтение статей и учебных пособий, посещение занятий, работа с наставником, изучение концепции и теорий — это все бесценно и эффективно, но при условии, что вы читаете чужие программы и пишете свои собственные. Конечно, я имею в виду больше, чем просто пропустить поток исходного кода перед глазами. Чтение здесь предполагает гораздо более активный процесс и включает в себя анализ и понимание кода. Аналогично и с написанием программ: не просто печатание исходного кода (хотя на самом деле и это важно), а проектирование структуры вашего кода.
Могу дать вам один совет: даже если вы продолжаете время от времени копировать и вставлять, вы должны выработать привычку фактически переписывать код вместо того, чтобы просто «копипастить». Это поможет вам развить важные качества: дисциплину и внимание к деталям при написании программы и чтение и понимание исходного кода. На самом деле для чтения кода требуется большая подготовка, чем думает большинство программистов. Да, мы учимся читать, рассматривая буквы как группы символов, но по мере улучшения навыка мы фактически узнаём целые фразы и даже предложения сразу.
Переписывая код, который вы собирались просто скопировать, вы заставляете свои глаза работать с кодом, практикуетесь в его чтении. В долгосрочной перспективе это значительно улучшит ваше чтение и понимание кода.
После того как вы отточите этот навык, вы перейдете к следующему шагу — не просто набирать пример слово в слово, а писать собственный код на основе найденного вами решения или модифицировать его так, чтобы он работал по-другому. И вот здесь уже вы будете программировать, хотя вам все еще нужно будет работать над концепциями, теорией и т. д. Но это именно тот уровень, с которого начинается программирование.
Дэвид Гарратт (David Garratt), программист:
Все зависит от того, что и как вы копируете. Случайный код из stackoverflow? Скорее всего да, поэтому лучше забросьте это дело, иначе плохо кончите.
В кругах программистов есть снобизм относительно того, что нужно сидеть и писать код самому по памяти. Все остальное — плохо, неполноценно. С одной стороны, это правильно. Что бы вы ни делали, оригинальным копипаст не будет. Новый код должен предоставлять уникальную бизнес-логику, которая делает ваше приложение особенным. А с другой стороны, пытаясь писать код самостоятельно, можно нарваться на неприятности. Был у меня случай, когда команда разработчиков сильно пожалела, написав решение для распределения работы по многим узлам через систему сообщений и очередей. Конечно, самым простым и надежным вариантом было бы использовать RabbitMQ, ActiveMQ, IBM MQ и т. д. Но ребята придумали свой способ сопоставления POJO (обычного-Java-объекта) с сущностями БД. Да, это был фейспалм.
Вывод: ищите опенсорсную, хорошо устанавливаемую и протестированную библиотеку и работайте с ней. Я постоянно задаю вопрос: почему мы до сих пор пишем так много кода? В программном обеспечении мало нового, к настоящему моменту основные концепции уже реализованы. На мой взгляд, совсем не стыдно стоять на плечах гигантов, но делать это нужно правильно.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.