Постоянно ищет примеры кода признак плохого разработчика? [закрыто]

161

Я студент CS с несколькими годами опыта в C и C ++, и в течение последних нескольких лет я постоянно работал с Java / Objective C, занимаясь разработкой приложений, и теперь я переключился на веб-разработку и в основном сосредоточен на ruby ​​на rails и я пришли к выводу, что (как и в случае разработки приложений, действительно) я слишком много ссылаюсь на другой код. Я постоянно работаю в Google с множеством функций, которые, как мне кажется, я должен был бы делать с нуля, и это немного подорвало мою уверенность.

Базовые основы не проблема, я ненавижу использовать это в качестве примера, но я могу пробежаться по javabat в java / python на спринте - очевидно, не достижение, но я хочу сказать, что у меня есть сильная основа для основ Думаю?

Я знаю, что мне нужно обычно использовать, но постоянно использую синтаксис. Хотелось бы получить несколько советов и предложений по этому вопросу, поскольку это довольно сильно сдерживает меня в плане поиска работы в этой области, хотя я и заканчиваю свою степень. Моя главная причина спрашивать не о работе, а о том, что я не хочу быть единственным парнем на хакатоне, который не набирает код без остановки и сидит там с 20 открытыми вкладками Google / github, и я воздерживался от посещения каких-либо из-за небольшого недоверия ...

Является ли человек плохим разработчиком, постоянно ища примеры кода для умеренных и сложных задач?

недавно небезопасно
источник
14
Это зависит от того, над чем я работаю, от того, над чем я работаю, вряд ли требуется поиск. Что-то более незнакомое, я постоянно ищу примеры.
Джейди
11
Зависит от того, действительно ли вы сможете написать код самостоятельно.
18
Моя жена смотрит эти соревнования по кулинарии и чемпионаты по кексам по телевизору, где у них есть нелепо небольшое количество времени, чтобы приготовить вкусную еду из случайных ингредиентов. В большинстве случаев еда ужасная или недоваренная и, конечно, не самого лучшего качества. Они хороши для шоу, но я бы предпочел, чтобы мой шеф-повар не торопился и делал это правильно. То же самое можно сказать и о хакатонах. Цукерберг и его друзья были хакатонами, которые быстро написали дрянной веб-сайт, который нужно было переписать, как только у них появилось несколько пользователей. Большинство людей предпочли бы, чтобы вы поняли это правильно с первого раза.
maple_shaft
88
Мой босс всегда говорит: «Лучшая мера мастерства программиста - его способность хорошо выполнять поиск в Google». Все знакомые мне программисты ищут примеры в интернете, но только плохие вставляют вслепую. Если кто-то уже сделал то, что вы хотите сделать, зачем изобретать велосипед?
SSumner
9
Исследование важно. Только не участвуйте в том, что я называю BSDD (блог-спам-ориентированная разработка)
Томас Диньян

Ответы:

238

Копировать-вставлять вслепую: плохо.

Ищите документацию, читайте примеры кода, чтобы лучше понять: хорошо.

Я бы предпочел работать с кем-то, кто все время смотрит на вещи и следит за тем, чтобы все работало как задумано, а не с чрезмерно уверенным человеком, который думает, что знает все, но не знает. Но хуже всего то, что кто-то не беспокоится о том, как все работает, и просто некритически копирует код из Интернета (а затем, когда начинают поступать сообщения об ошибках, он не может ничего исправить).

tdammers
источник
21
@NewlyInsecure Это хорошо ... некоторые разработчики программного обеспечения, такие как я, считают, что люди, которые ходят на хакатоны, просто смешны. Большинство из них - отличные программисты, но ужасные разработчики программного обеспечения, которые выпили слишком много красных быков.
maple_shaft
23
У разработчика есть мозги, чтобы знать, что кто-то что-то сделал заранее, искать примеры и адаптировать их. Разработчик не тратит время стучит черепа на стене.
Дэвид
19
@NewlyInsecure Сравнение убивает. Серьезно, чем больше вы сравниваете себя с другими, тем более деморализованным, немотивированным и пугающим вы становитесь. Формируйте свои собственные убеждения, основанные на правде, а не на том, что делают все остальные. Если люди в хакатонах могут быстрее набрать больше кода, кого это волнует? Даже если это показатель мастерства, всегда найдутся люди умнее, чем вы, независимо от того, насколько вы искусны.
Фил
5
Лично, если я найду пример кода, который уже делает более или менее то, что я хочу, я изучаю его, чтобы понять. Если это большой кусок кода, я буду делать заметки и, возможно, затем псевдокодировать решение для моего конкретного случая, а затем попытаться реализовать свой псевдокод с реальным кодом. Я думаю, что ключ здесь и то, что было упомянуто тдхаммерсом и Дэвидом, заключается в том, что я не слепо копирую код. Я смотрю на него, чтобы понять, что он делает, и затем включить его идеи в мое конкретное решение.
Шуфлер
3
@NewlyInsecure: у вас также есть две вещи, идущие против вас: во-первых, API стали намного больше и сложнее, чем раньше, что делает их запоминание намного сложнее. Второй - это возраст, которого у вас сейчас нет, но он будет еще до того, как вы его узнаете. Когда вы станете старше, вы обнаружите, что не можете вспомнить все, и вы начнете сохранять клетки своего мозга для того, что вам действительно нужно знать. Важным является развитие навыков, необходимых для исследования и поиска деталей, которые вы забыли.
Blrfl
110

Если вы кодируете свои решения понятным способом и фактически ПОНИМАЕТЕ то, что копируете / вставляете / модифицируете, тогда проблем не возникает.

Я умираю внутри каждый раз, когда я задаю старшему разработчику вопросы о том, почему он сделал то, и ответ: «Я не знаю, я скопировал, вставил код, и в тот момент это сработало».

Данте
источник
8
Иногда я зацикливаюсь на себе, думая, что могу быть не таким хорошим разработчиком. Затем я читаю такую ​​цитату и чувствую себя намного лучше.
Кувшин
18
@TheJug, помни, ты и лучший разработчик, и худший, чем ты себе представляешь.
Джо
71

Как и в случае умения программировать с / вне документацией API , поиск примеров кода является признаком не плохого программиста, а человека, которому не хватает беглости ...

... Здесь я говорю о беглости. О том, чтобы быть не просто способным на что-то, но и свободно.

Вы знаете, что значит быть беглым? Это когда кто-то смотрит на тебя, как будто ты кодируешь, когда ты печатаешь ...

  • ... Как будто правильный код просто течет из ваших пальцев на экран. Как будто вы не проверяете API документы, учебные пособия и руководства. На самом деле, вы делаете проверить их все, но это невидимый , потому что это все в вашей голове. У вас есть все необходимые знания прямо в вашем мозгу - заряженные, загруженные и готовые к использованию.

... Это свободное знание. Это когда вам требуется минута, чтобы сделать то, что нужно новичку в час. Это стоит усилий, правда. Пахнет победой.

... и практика является для меня единственным надежным способом овладеть беглостью.

комара
источник
14
ОТЛИЧНЫЙ пункт о беглости. Я свободно говорю на Коболе. Я 20 лет отдыхал от ИТ и возвращаюсь изучать Java. Я инстинктивно знаю, как сделать что-то в COBOL ... но частью процесса ОБУЧЕНИЯ Java беглости является поиск примеров кода, анализ того, почему они работают, и адаптация их для моих конкретных потребностей. Когда вы изучаете новый язык VERBAL, вы сначала довольно часто обращаетесь к своему итальянско-английскому словарю, неправильно понимаете грамматику и время, и в конце концов однажды вы говорите как родной язык. Время и практика являются ключевыми. Не волнуйся об этом ... :)
dwwilson66
10
@ dwwilson66 Дело в том, что на ежедневном уровне мне нужно помнить четыре «языка» - язык программирования на стороне сервера, язык сценариев на стороне клиента, синтаксис разметки на стороне клиента и синтаксис стиля на стороне клиента. Я просто не могу держать все это в голове - это все равно, что пытаться вести разговоры на итальянском, китайском, английском и клингонском языках одновременно.
Такрой
@Tacroy - ТОЧНО! Без беглости вам нужны ресурсы, чтобы помочь. Это не делает вас «менее» говорящим по-клингонски, если вам нужно время от времени искать полные фразы вместо одного слова - просто не так свободно, как другие.
dwwilson66
4
Последнее предложение заслуживает того, чтобы быть выделенным, а не скрытым в нижнем индексе. Нет другого способа стать беглым, кроме как с помощью погружения.
jmlane
@ dwwilson66 обратите внимание, что в Java есть вещи, которые должны быть сделаны совершенно иначе, чем в COBOL. Объекты - это не то же самое, что копии книг.
54

Есть теория обучения, называемая циклом Колба (по названию человека). Записи в этом цикле:

Concrete experience -> Reflective observation
    ^                        |
    |                        v
Active experimentation <- Abstract conceptualisation

Разные люди любят начинать в разных местах цикла. Так что вполне возможно учиться , ища образцы (рефлексивная фаза наблюдения), а затем переходить от этих образцов к общей картине с помощью абстракции.

Другие люди будут учиться по-разному: некоторым людям нравится начинать с попыток (то есть с экспериментов), а затем размышлять о том, что получилось правильно или неправильно. Дело в том, что это просто разные способы решения проблемы изучения вещей: ни один из них не является неправильным.

user4051
источник
2
+1 Интересно. Интуитивно, я бы ожидал, что нужно пройти хотя бы некоторые из этих этапов, чтобы научиться, верно? То есть просто наблюдения, вероятно, недостаточно для реального обучения - вам нужно подумать о том, что вы видели, и попробовать это.
Калеб
Мне действительно это нравится. Я начинаю с Reflective Observation на большинстве языков, но в PowerShell я обычно начинаю с Active Experimentation
Caleb Jares
@ Калеб правильно. Это цикл, в котором вы переходите от этапа к этапу и, возможно, не полностью усваиваете что-то, пока не пройдете все четыре этапа. Это где вы начинаете, что меняется больше всего.
39

Полное раскрытие - я пожилой человек, который обучался другому Интернету, доступному в эпоху работы. Я наблюдал, как навыки молодых разработчиков неуклонно ухудшаются, в основном из-за того, что они не сохраняют информацию или не понимают решения, которое они взяли из Интернета. Я заметил, что уровень компетентности, который был у человека после 1-2 лет опыта, 20 лет назад, теперь является уровнем компетентности, который есть у человека после 5-7 лет опыта. (Да, это личное наблюдение, но я много нанимал, у меня нет статистических данных по этому вопросу, и да, я иногда стар и капризен, прими это утверждение с недоверием. И держись подальше от моего двора. )

Поиск всего неэффективен с точки зрения времени. Это также признак того, кто не обладает большой глубиной знаний. Люди с глубоким знанием могут писать код быстрее, чем люди, которые не знают, как решить проблему, не глядя на вещи. Так что стоит научиться справляться с большим количеством вещей без необходимости постоянно их искать.

Теперь я не говорю, что вы никогда не должны искать вещи, я говорю, что вы должны научиться сохранять знания и только нужно искать вещи, которые вы используете редко или когда вы сталкиваетесь с действительно новой проблемой, языком или парадигмой. И я не говорю, что вы не должны читать, чтобы не отставать от новых решений, инструментов и языков.

Моя настоящая забота о разработчиках, которые слишком часто ищут вещи, так что слишком многие из них (не обязательно вы) никогда не развивают аналитические навыки, чтобы понять проблемы, которые у них есть, и решения, которые необходимы. Прочитайте, сколько вопросов есть в том месте, где человек вставляет сообщение об ошибке, которое он или она явно не понимает, но которое должно быть совершенно ясно любому, кто работает на профессиональном уровне. Или те, где человек говорит: «Это не работает, почему?» без ссылки на сообщение об ошибке или на то, как оно не работает, а код синтаксически правильный. Или те, кто получил кусок кода, который должен работать,

Так что, если вы ищете то, что является частью основной функциональности языка (ов) (кстати, это должно включать SQL, если вы обращаетесь к базам данных), который вы использовали более шести месяцев, я подозреваю, что вы тоже ищете много. Если то, что вы ищете, - это расширенные функции, особенно те, которыми вы редко пользуетесь, то у вас все хорошо.

Но как научиться сохранять больше информации? Сначала поймите, почему код сломался. Даже если кто-то дает вам рабочее решение, если вы не видите, почему это сработало, а ваше - нет, спросите. Если вы не понимаете сообщение об ошибке, спросите, что оно означает, а затем попытайтесь решить его самостоятельно.

И никогда не вырезайте и не вставляйте решение, которое вы не понимаете. На самом деле, не вырезать и не вставлять вообще. Если вы хотите сохранить информацию, вам нужно набрать ее. На самом деле физическое написание кода самостоятельно помогает вам его освоить. Это хорошо известная методика обучения.

Практикуйте обобщение вашего понимания кода. Я видел, как люди снова и снова задают подобные вопросы, потому что они не понимают, что решение проблемы ABC, которое они получили месяц назад, - это то же решение новой проблемы DEF.

Поэтому, когда вы что-то исследуете, уделите время тому, чтобы подумать о том, какие проблемы было бы полезно решить, и напишите себе об этом. Затем, когда вам нужно решить проблему, сначала проверьте свои заметки, чтобы увидеть, что вы уже отметили возможную технику. Если вы оцениваете несколько способов решения проблемы, сделайте заметки о типе проблемы, возможных решениях, которые вы рассматривали, а также о плюсах и минусах каждого из них. Опять же, ведение записей помогает укрепить знания в вашем мозгу, у вас уже есть свой собственный мыслительный процесс с точки зрения плюсов и минусов, и вам не нужно делать это снова (или, по крайней мере, не настолько глубоко, вы можете все еще ищите больше возможных методов) для следующей подобной проблемы.

И когда вы решаете, что изучать дальше, изучите одну из ваших основных технологий, прежде чем приступить к изучению первых 30 дней использования еще одной технологии (это предполагает, что у вас достаточно широты знаний, чтобы фактически выполнить свою работу, если вам нужно используйте 6 технологий - сначала изучите основы всех шести, прежде чем углубляться). Затем переходите назад и вперед, изучая новые вещи на базовом уровне, изучая что-то более глубокое, а затем изучая новые технологии на базовом уровне. Если вы сделаете это с течением времени, вы обнаружите, что ваш базовый уровень того, что вы хотите от новой технологии, гораздо глубже, потому что вы понимаете более сложные вопросы, чтобы задать об этом.

Еще один способ научиться сохранять знания - научить их кому-то еще. Отвечайте на вопросы в подобных местах, представляйте учебные темы для своей команды, делайте презентации в своих локальных группах пользователей, пишите записи в блогах и помогайте поддерживать вики в вашей компании информацию, чтобы помочь другим разработчикам.

HLGEM
источник
11
Здесь есть несколько очень хороших моментов, но я думаю, что это страдает из-за «старых добрых времен». Люди осуждают вырождение молодого поколения на протяжении тысячелетий. Я еще не видел убедительных доказательств, подтверждающих это.
4
+1 @JonofAllTrades .. человек, я хотел бы вернуться на двадцать лет назад и заработать миллион долларов, потому что я знал… FoxPro. только. Но нет, в настоящее время вам нужно быть компетентным в технологиях маленькой галактики, чтобы просто побороться за постоянную работу. Можете ли вы установить и настроить Apache, IIS, оба? Вы чувствуете себя уверенно на одном или двух диалектах SQL, способны писать SPROC и, по крайней мере, легко управлять? Вы компетентны в паре серверных языков и хотя бы в одном функциональном языке сценариев для манипулирования данными? ... а если вы будете программировать для Интернета, ваши вещи будут работать на основных браузерах и мобильных устройствах?
elrobis
Этот аргумент имеет смысл только для технологии, которая существует уже 20 лет назад. И да, вам очень повезло, что вы получили работу, имея в основном только знания SQL (ваш «двор»), что недостаточно по сегодняшним стандартам.
Пруссван
@prusswan, я специалист, и на моей арене гораздо больше работы, чем они могут заполнить. Но насколько это относится к тому, что я говорю в ответе, мне не по силам. То, о чем я говорю, возможно для всех технологий. Проблема в том, что люди не учатся или не понимают, что они делают, потому что им не удается сохранить информацию, а не то, что некоторые из нас используют старые технологии. Сохранять знания для новых технологий так же легко, как и для старых. А накопленные знания помогут вам выучить следующий, и вы будете развиваться быстрее.
HLGEM
24

Поиск примеров кода не является признаком плохого разработчика. Редко нужно так мало вещей, чтобы точно запомнить все необходимые им интерфейсы, поэтому естественно искать вещи, и примеры кода, как правило, являются справочными, которые проще всего использовать.

Чего не следует делать, так это копировать и вставлять примеры, потому что они работают там, поэтому они должны работать и здесь, не понимая, как они работают. Это обычно приводит к множеству бесполезных фрагментов, которые случайно копируются, и в результате их трудно поддерживать, потому что если вы не знали, как это работает, когда писали, вы не узнаете и через шесть месяцев и не сможете почини это.

Но если вы понимаете код, который копируете из примера, это верный способ ускорить работу, и это, как правило, хорошо.

Jan Hudec
источник
2
Я перебираю все, что копирую, и я понимаю все, что я читаю, это лишь часть синтаксиса и функциональности, которые так затянуты, что я не думаю, что мог бы выложить все это с нуля. Даже вещи, которые должны быть простыми и второстепенными, такие как json или запрос к базе данных и т. Д. (Вероятно, плохие примеры). Спасибо за ваш ответ, я действительно ценю это.
Недавно небезопасно
2
И вам также следует дважды подумать, прежде чем копировать и вставлять примеры кода в ваш собственный проект. Возможно, имеет смысл разделить их в классе и использовать их повторно.
stralsi
@SilviuStraliciuc: я думаю, что это больше о 1 или 2-строчных примерах. Которые не имеют смысла оборачивать в функции. Но я обычно печатаю их вместо использования ctrl-c + ctrl-v, поэтому я применяю правильное форматирование и заменяю идентификаторы и тому подобное на лету.
Ян Худек
1
Иногда примеры 1 или 2 строки сделать смысл , чтобы обернуть в функцию, особенно если есть шанс , что вы передумаете именно о том , что вы хотели, 1 или 2 линии , чтобы сделать (и теперь вы должны найти 200 места, разбросанные по всему коду, где вы использовали этот шаблон из 1 или 2 строк). С помощью функции с соответствующим именем, даже если вы получаете что-то не так, что все еще нужно исправить в 200 местах, по крайней мере, легче определить эти места.
Дэвид К
14

Эти ответы довольно хороши. Но вы страдаете от более глубокой проблемы, чем копирование / вставка, или от недостатка «навыков».

Сравнение смертельно. Чем больше вы сравниваете себя с другими людьми и позволяете их таланту влиять на то, как вы себя видите, тем больше вы будете усыхать и умирать внутри. Вы не ходите на хакатоны из-за страха, что люди увидят, насколько вы бездарны. И единственная причина, по которой вы считаете себя бездарным, заключается в том, что вы сравниваете себя с хакерами, которые могут быстрее набрать больше кода с нуля.

Даже если «Строки кода в минуту» были хорошим показателем для измерения навыка, вы должны принять тот факт, что всегда будут лучшие разработчики, чем вы . И это нормально , чтобы показать другим , что вам не хватает в мастерстве.

Вам не нужно быть таким же хорошим или лучше, чем кто-либо другой. Вы должны быть довольны тем фактом, что вам всегда будет как-то не хватать и что вы постоянно учитесь. Если вы не можете быть счастливы, будучи слабым разработчиком, вы никогда не будете счастливы.

Еще одна вещь: ваш страх быть отвергнутым людьми, которых вы считаете «превосходящими», - это именно то, что мешает вам общаться с лучшими разработчиками и учиться у них. Таким образом, ваш страх мешает вам расти, что поддерживает ваш страх. Что мешает вам расти. Видишь цикл? Вы должны где-нибудь разорвать цикл.

Фил
источник
8
Хороший ответ, но его не следует читать, чтобы означать, что нормально принимать посредственность. Следите за своей работой и не беспокойтесь о том, что другие люди лучше вас, но работайте над улучшением.
Калеб
12

Я думаю, что многое зависит от того, как работает ваш разум. Моя память воняет, поэтому я бы предпочел взять код, максимально приближенный к тому, что я хочу, и переработать его, чтобы он выполнял новую работу. Это служит примером и напоминанием обо всех вещах, которые я должен сделать. Например, я использовал простой SQL в течение 20 лет, но я никогда не могу вспомнить структуру оператора SELECT или UPDATE. (Я думаю , что нужно круглые скобки, но я не могу вспомнить , какой.) С другой стороны, некоторые несколько вещей , которые я помню; Я могу собрать реализацию Java Iterator с закрытыми глазами.

Большая часть кода, который я копирую, принадлежит мне, но я, конечно, копирую другой, когда узнаю что-то новое.

Я не знаю о хакатонах. Они могут привлекать программистов с фотографическими воспоминаниями. Я бы попробовал и увидел. Если вас беспокоит внешний вид идиота, вам не следует программировать.

Я призываю вас полностью понять весь код, который вы копируете и модифицируете, но пока я не прочитал некоторые другие ответы, мне никогда не приходило в голову, что кто-то может скопировать без понимания. (Кажется, я все время изучаю новые пороки на этом сайте ...)

RalphChapin
источник
Psst, ни один не нуждается в круглых скобках, если вы не делаете подзапросы в SELECT или сложную логическую логику в WHERE. ;)
Изката
2
@Izkata: нет? Позвольте мне взглянуть на старый код. О, это оператор INSERT, который нуждается в скобках.
RalphChapin
8

... Я пришел к выводу, что ... я слишком много ссылаюсь на другой код. Я постоянно гуглю функционал по многим вещам, которые, как мне кажется, я смог бы сделать с нуля, и это немного подорвало мою уверенность.

Тогда остановись. Пройдите некоторое время в другом направлении. Реализуйте все самостоятельно, даже если вы знаете, что сможете найти именно то, что вам нужно, за гораздо меньшее время.

То, что произошло, так это то, что ваша мышца для решения проблем (латинское название gluteus mojo ) атрофировалась от неиспользования, и теперь вы избегаете ее использовать, потому что знаете, насколько она слабая. Вы должны начать наращивать и тонизировать эти мышцы так же, как вы работаете на бицепс в тренажерном зале. Начните с высоких повторений и низкого сопротивления - множество простых проблем. По мере того, как вы набираетесь уверенности, переходите к более долгим и сложным проблемам.

Вы постепенно почувствуете, что ваш моджо возвращается, и ваша потребность полагаться на Google уменьшится. Продолжайте тренировать эти мышцы, и убедитесь, что вы не вернетесь к своим старым способам. Испытайте себя, чтобы сначала решить проблему, и только потом ищите другие решения. Иногда вы обнаружите, что другие нашли лучший способ сделать то же самое, в других случаях вы решите, что ваше собственное решение лучше.

Является ли человек плохим разработчиком, постоянно ища примеры кода для умеренных и сложных задач?

Человек, который не может ничего сделать, не найдя примеров, является плохим разработчиком. Дело в том, что вы не будете знать, сможете вы или нет, пока не попробуете.

Калеб
источник
7

Вы молоды, и вы работали со многими языками программирования. Я собираюсь догадаться, что вы, вероятно, освоите новые языки быстрее, чем старые. Вы по-прежнему не уделяете достаточно времени одному языку в достаточно большом приложении, чтобы развить беглость.

Ищете ли вы широкие решения каждый раз, например: весь процесс подключения веб-сетки к таблице базы данных или меньшую часть, например форматирование строки подключения (мне приходится искать это почти каждый раз, так как я пишу около четырех раз в год. )?

Вы всегда будете искать ссылки на синтаксис различных строк кода или функций. Чем больше вы программируете, тем больше проблем и различных сред и языковых изменений вы сталкиваетесь. Если вам нужен полный урок каждый раз, когда вы что-то делаете, у вас есть проблема.

JeffO
источник
Я согласен - всегда есть вещи, которые, хотя и достаточно распространенные действия (чтение из файла, подключение к БД, создание HTTP-запроса и т. Д.), Синтаксис и подход отличаются настолько сильно от языка к языку, что мне обычно приходится проверять. Это то, как вы затем соединяете эти основные строительные блоки, чтобы создать что-то новое и полезное, что является умным кусочком
Kris C
5

У меня был профессор, который обычно говорил, что он ненавидел давать тесты, основанные на попытках сохранить кучу информации, которую вы забили прошлой ночью, потому что вы все равно потом много ее забываете. Лучше знать ваши ресурсы и чтобы вы могли их правильно использовать, чтобы найти информацию, которую вы не знаете. Мне нравится применять подобный принцип ко всему, что я делаю, включая работу.

Я думаю, что наиболее важными инструментами, которые у вас есть, являются ваши ресурсы, если вы используете их правильно. Поэтому, когда я пишу код, я делаю все возможное, используя имеющиеся у меня знания, а затем провожу исследование, спрашивая других программистов или ища в Интернете, чтобы лучше понять соответствующее решение. Знания будут накапливаться со временем, и через некоторое время вы, естественно, будете лучше понимать и понимать навыки. Я постоянно ищу вещи, нужна ли мне эта информация или нет, и я могу честно сказать, что каждый день узнаю что-то новое.

jb11
источник
6
«Я никогда не запоминаю ничего, что можно легко найти в книге». - Альберт Эйнштейн, 1922.
gbjbaanb
3
@gbjbaanb Альберт Эйнштейн использовал контроль версий в 1922 году? Вау, он был действительно потрясающим.
svick
4

Если вы понимаете проблему, которую пытаетесь решить, и понимаете, как вы хотите ее решить, поиск правильного синтаксиса, по моему мнению, не имеет большого значения.

Я закончил около двух лет назад и был брошен на волков, когда я получил свою работу. Мне пришлось изучать, поддерживать и обновлять большое приложение, написанное на языке, которого я никогда раньше не трогал. Я получаю отчет об ошибке, просматриваю код и выясняю, как я хочу это исправить, а затем мне приходится гуглить примеры того, как делать то, что я хотел на этом языке.

Если вы делаете что-то, и понимаете это достаточно, чтобы не создавать ненужный отток, то вы, вероятно, в порядке.

Крис
источник
3

Чистое некритическое копирование и вставка, как указано много раз в этих ответах, плохо. Но так же пишет все с нуля. Если это не критический компонент, который является ключевым для вашего бизнеса, сначала найдите библиотеку или фрагмент кода. Исключением из поиска фрагмента будет то, что проблема очень проста, у вас есть четкое представление о том, как это сделать, и если вы не используете библиотеку: вам вряд ли понадобится что-то еще делать.

Лично я знаю, что если я напишу что-то общее, у меня, скорее всего, будут какие-то тонкие ошибки и, возможно, одна или две не очень тонкие без большого количества тестирования. Поэтому я ищу похожее решение, модифицирую и тестирую его, чтобы сэкономить время на тестировании и разработке в целом. Потому что, в конце концов, я несу ответственность за поставку продукта, который работает, является расширяемым, находится в рамках или в рамках бюджета и соответствует срокам. Повторное использование кода и библиотек - хороший шаг к этой цели.

Питер Смит
источник
3

Я думаю, что чтение примеров кода и просто чтение исходного кода того, что в целом разработали другие люди, является лучшим способом улучшить ваши навыки. Я действительно думаю, что это открывает двери в вашем мозгу, которые иначе не были бы открыты.

Если вы придумали решение A, а кто-то еще придумал решение B, когда каждый из вас поделится своими решениями, вы можете реализовать решение C, которое может быть даже лучше, чем A или B.

Майкл Батлер
источник
2
Как разработчик, работающий преимущественно соло, у меня нет коллег, которые могли бы проверить мой код, разобраться со своими проблемами и вдохновить меня. Примеры в сети важны для меня как для решения конкретных проблем, так и для изучения новых навыков / лучших практик.
cjmUK
3

Я думаю, что есть много уровней мастерства разработки программного обеспечения. Просто так, потому что есть также много уровней владения документацией по разработке программного обеспечения . Честно говоря, в наши дни системы на порядок сложнее, чем когда я начал программировать компьютеры в середине 1980-х годов.

Затем вы должны были знать, что вы хотите, чтобы компьютер делал, и вы написали документацию толщиной 6 дюймов, в которой рассказывалось, как компьютер делал некоторые более простые вещи. Чтобы превратить то, что вы хотели, в форму, которую мог принять компьютер, нужно было знать содержание индексов этих книг и язык программирования (или два. Действительно, после изучения четырех или пяти языков остальные - просто диалекты).

Сегодня эта задача требует знания языка, знания системы, знания парадигмы, модели программирования и хотя бы одного набора API, и все они являются движущимися целями.

Таким образом, человек с определенным уровнем базовых знаний, который спрашивает вокруг, не является хорошим программистом. Он является лучшим программистом, учитывая сегодняшнюю среду и незаинтересованность фирм, таких как Microsoft, в том, что они применяют любые строгости к своей основной документации. Большая часть их материалов - это справочные материалы, на которые есть ссылки, и некоторые очень плохие примеры кода. (Два случая, с которыми я столкнулся, это «Установщик Windows» и API для создания файлов фильмов WMV.)

Поскольку Microsoft, Google и, в меньшей степени, Apple, все полагаются на «сообщество», чтобы восполнить этот очень реальный недостаток, опросы не просто важны, это жизненно важно. И быть человеком, которого можно спросить и который может дать твердые ответы и обратную связь в сегодняшних условиях, так же важно. Вот почему такие сайты, как сайты stackexchange.com , так же полезны, как и они.

Поэтому задавайте вопросы (задавайте вопросы грамотно!) За образцы и уважайте людей, которые предоставляют ответы, и это не будет восприниматься как признак «плохого разработчика».

И еще одна вещь: предоставление плохих образцов действительно является признаком плохого разработчика. Это облегчает поиск плохих разработчиков, а также скучает в поиске Google. Если вам не хватает уверенности в простых, простых, конкретных примерах кода, не давайте их.

И, пожалуйста, не издевайтесь над теми, кто спрашивает.

Роб Перкинс
источник
3

Мне кажется, что проблема для вас заключается не столько в понимании того, на что вы ссылаетесь, сколько в проблемах со средствами и памятью. Если это подрывает вашу уверенность, то да, это проблема, но она, безусловно, может быть решена!

Для меня такие проблемы возникают во многих аспектах моей жизни. Например, чтобы научиться исполнять музыкальное произведение, мне нужно обрести независимость от нот, которые мне дают - как вы на самом деле чувствуете музыку, если ваш нос все еще утопает в вашем буклете? Иногда, если у меня есть время, я запоминаю всю музыку - даже если она не требуется для моего выступления. Почему? Когда ноты пропали, мне намного легче сосредоточиться на более сложных и всеобъемлющих аспектах музыки, которые мне нужны, чтобы получить правильные результаты, и мне намного легче попасть в эту невероятную зону чистого создания музыки. Поэтому я считаю, что это часто стоит дополнительных хлопот.

Мой опыт программирования был похожим. Я думаю, что ключи:

  1. попрактикуйтесь в языке - наберите его, запустите, говорите, если это поможет; делать это неоднократно.
  2. построить свой объект - использовать одну и ту же функцию или шаблон в разных ситуациях; объединить функции; делать программы.
  3. уделите достаточно времени между повторениями, чтобы убедиться, что вещи действительно проникают в вашу долговременную память.

Эти принципы, кажется, применяются при изучении любого языка, на самом деле! См. Например, как запомнить новые слова . Метод Пимслера также работает следующим образом.

Я обнаружил, что с помощью этих ключей можно полностью запомнить почти все принципы, синтаксис и общие библиотеки языка и технологий, которые я регулярно использую. Тем не менее, я до сих пор постоянно рыщу в Интернете за примерами и мудростью! Но в этот момент я ищу подтверждение проблемы, которую пытаюсь решить, различные подходы, которые можно использовать, инструменты, которые могут помочь, и консультации для менее часто используемых библиотек. Это совершенно другой вид поиска, чем я использую, когда я впервые изучаю язык и по уши в учебниках и руководствах.

Из вашей истории, вот некоторые конкретные камни преткновения, я думаю, вы можете столкнуться.

  1. Если вы боретесь с синтаксисом, возможно, вам не хватает практики. Это особенно верно, если вы копируете и вставляете прямо в свой код, вместо того, чтобы развивать повторение и - могу ли я сказать? - мышечная память , которая поможет вам стать действительно хорошим. Чтобы противостоять этому, просто разработайте упражнения и дисциплину, сосредоточив внимание на повторении и времени, которые улучшат ваши возможности в нужных вам областях. Предложения:
    • Напишите простую программу на одном языке один раз в день, каждый день.
    • Напечатайте примеры вместо того, чтобы копировать и вставлять их.
  2. Если вы боретесь с созданием решений для задач среднего размера, возможно, у вас недостаточно опыта в строительстве. Попробуйте это:
    • Начните проект среднего размера с использованием какой-либо технологии или языка, который вы хотите освоить. Или попробуйте свою более короткую функцию в интересующем вас проекте с открытым исходным кодом. Делайте это каждый день. (Помните, когда вы идете за этими более крупными проектами: идите к ним по кирпичику. Не пытайтесь построить все это сразу!)
    • Используйте одну и ту же новую функцию четыре дня подряд в четырех разных контекстах.
    • Испытайте себя, чтобы кодировать что-то с выключенным веб-браузером!
    • На самом деле делать заметки на вещи, которые вы изучаете. Синтезируйте то, что вы изучаете, и запишите свои наблюдения. (На самом деле записывать вещи и заставлять себя выражать что-то своими словами, мне очень помогает.)
    • Пишите ответы и проверяйте их для вопросов StackOverflow о технологиях, которые вы изучаете. (Это часто дает дополнительное преимущество, так как зарабатывает немного репутации во время обучения. :-))
  3. Вы можете распространять свою практику слишком тонко. Вы, кажется, работаете на разных языках. У этого есть много преимуществ, но у этого есть недостаток разбавления Вашего опыта. Если вы проводите время на пяти разных языках, вы запомните меньше, чем если бы вы проводили одно и то же время на одном языке. Хуже того, есть много не совсем похожих сородичей между разными языками (если это еще не было, elsif или elif ??), чтобы сбить вас с толку. Чтобы противостоять этому, заострить внимание. Выберите одну вещь, чтобы учиться и учиться этому холодно. Затем перейдите к следующему.
Оуэн С.
источник
3

Я думаю, что если вы сконцентрируетесь на разработке умеренного кода, ваша эффективность и производительность увеличатся. Вероятно, потребуется больше времени, чтобы найти код, прочитать / понять его, скопировать его в исходный код, соответственно изменить его и т. Д.

Если вы придумаете это сами, скорее всего, оно будет более приспособлено к вашей конкретной ситуации, и через некоторое время эти решения придут к вам быстрее, чем их поиск.

Я смотрю на это так, будто вам нужно второе мнение по поводу определенного решения, поэтому вы смотрите, как это делают другие (в Интернете). Если вы обнаружите, что делаете слишком много или хотите этого, подумайте о том, чтобы спросить коллегу о том, что он думает о решении. Если вы будете задавать вопрос своему коллеге каждые 15 минут, он, вероятно, будет раздражен. Поэтому вы будете задавать меньше вопросов и попытаться придумать это сами.

Визуализируйте это, когда хотите поискать вещи в Интернете.

Geerten
источник
3

Лучший способ узнать то, чего вы не знаете: это Google! Я чувствую, что вы правы с большинством разработчиков. Положите комплекс неполноценности в свой рюкзак и входите с открытым разумом.

Не бойтесь задавать вопросы, изучайте Google, пытайтесь потерпеть неудачу. Это все часть этого.

Peter Mortensen
источник
3

Разработка программного обеспечения в корпоративных условиях требует значительного количества повторного использования кода. Зачем переписывать функцию / метод, если API уже существует и широко используется? Скорее всего, это будет так же эффективно, как и все, что вы пишете, и займет меньше времени.

Конечно, успех в разработке программного обеспечения также требует от клавиатуры отрыва, чтобы вы могли читать и понимать, что на самом деле происходит. Возьми любой веб-фреймворк. Вы должны знать, что происходит ниже, чтобы понимать код, который вы пишете, но вам, вероятно, никогда не придется писать веб-фреймворк с нуля.

Вам просто нужно написать код, который использует преимущества типа фреймворка (скажем, компонентный фреймворк требует определенного стиля), и это происходит из понимания более широкой картины. Изучите большую картину, и у вас все будет хорошо.

Peter Mortensen
источник
2

Из уже полученных ответов ясно, что нет ничего плохого в исследовании вашей проблемы, а не в слепом кодировании. Но вопрос, который не был затронут, потому что вы не задавали его напрямую, почему вы чувствуете себя так неуверенно - и что вы можете с этим поделать? В конце концов, многие люди решают свои проблемы и имеют много уверенности (даже те, кто не должен ...)

Так что делать? Возможно, вам просто нужно было несколько сотен похлопываний по спине, которые вы только что получили, и теперь можете кодировать с уверенностью. Но если это не помогло, я предлагаю вам изучить автоматизированное тестирование и разработку через тестирование. Ничто не говорит «хорошо сделано», как «Все тесты пройдены» из вашего набора тестов: когда вы туда попадаете, вы знаете , что сделали все правильно.

Вы также должны попытаться немного испытать себя: вы говорите, что всегда ищите синтаксис, который вы уже знаете; поэтому заставьте себя написать некоторый код, не просматривая синтаксис, и вы (скоро, если не сразу) узнаете, что у вас все в порядке в конце концов.

Alexis
источник
2

Разработчики не рождаются «великими», но величие не приходит автоматически с опытом. И наоборот, недостаток опыта не делает разработчика «плохим». Разница между хорошим разработчиком и плохим разработчиком заключается не в их знании предметной области, а в их методологии. Отличительной чертой великого разработчика является то, что он кодирует сознательно. Иными словами, хороший разработчик всегда знает, почему он что-то делает. С точки зрения личной этики это требует интеллектуальной смелости и честности.

Очень важно потратить некоторое время и понять основы, более сложные вещи в значительной степени основаны на этом. Если нет понимания языка и того, что происходит за кулисами, кодирование будет просто взломом ...

Маниш Моди
источник
1

Так что чтение книг с примерами и ссылки на них - это плохое программирование, это контекст вашего вопроса. Хорошо видеть, что только немногие люди документируют их API, книга - все, что мы оставили.

Я не знаю, по каким причинам вы задаете этот вопрос, возможно, вы сможете ответить на этот вопрос самостоятельно, прочитав мою ситуацию, поскольку я ссылаюсь на множество примеров кода.

У меня никогда не было возможности поступить в университет, поскольку я был на улице в 16 лет. Каким-то образом в 24 года я был в состоянии учиться в заочном колледже и делать сертификаты продавцов, такие как SCJP, SCJD, SCBCD и SCWCD. Я должен признать, что время от времени я боролся и должен был обратиться в Интернете за примерами. Не зная, что в то время у меня в голове росла опухоль головного мозга (к 2010 году она была размером с апельсин). После 5 операций на головном мозге, 6 недель сочетания химиотерапии и лучевой терапии и 10 месяцев химиотерапии я все еще занимаюсь программированием сайтов, написанных от руки, которые можно просмотреть из моего профиля.

Да, сейчас мне нужно много примеров кода с повреждением мозга, так что, делает меня плохим программистом?

thejartender
источник
У тебя есть веская причина. Конечно, можно легко утверждать (даже используя свою собственную историю!), Что это только дефектный программист, который не может обойтись без того, чтобы кто-то дал им кодекс. Вопрос в том, является ли это справедливой оценкой.
Цао
1

Итак, я вижу, вы упомянули, что вы собираетесь на хакатон. В прошлом году я побывал в немало (более 15) и заметил, что они отлично подходят для обучения. И под «великим для обучения» я имею в виду обучение тому, как никогда больше никогда не писать подобный код. Я в основном стараюсь делать что-то новое на каждом хакатоне, на который я хожу, просто чтобы узнать что-то новое. Поскольку существует огромное ограничение по времени, вы полагаетесь на простое копирование и вставку всего кода, который можете найти, и это приводит вас в замешательство, когда вы его тестируете.

Однако, из этого получаются хорошие вещи, вы: A) так много УЗНАЕТЕ во время тестирования на ошибки (также сильно плачете) B) знаете, что никогда больше не будете писать такой код и изучите лучшие практики кодирования. Кроме того, на хакатонах вы встретите людей, которые могут научить вас многому новому, о чем вы никогда не знали, и вы будете делать то, чего никогда не будете делать в школе.

Так что я говорю, что копирование плохо, и вы ничего не узнаете, а время, которое вы сэкономили, копирует вас позже во время тестирования ошибок, и вы не представляете, что вы даже написали, это 8 утра, и заправлен всем кофеином. Но я думаю, что до тех пор, пока вы будете тестировать свой код, вы ДОЛЖНЫ узнавать все, что копировали ранее.

jreptak
источник
0

Ну, я не называю себя хорошим программистом. Но то, что я делаю, просто. Если я не знаю, как что-то сделать, я на самом деле смотрю код / ​​пример в Интернете. Затем, прочитав его, я пытаюсь переписать его, оптимизировать и использовать то, что лучше всего подходит для кода, который я хочу.

Примечание: чтение кода из Интернета не делает вас плохим разработчиком. Всегда хорошо смотреть, как это делают другие люди, и ты всегда чему-то научишься. Но тогда, копировать это вслепую не хорошо.

Blastcore
источник
-1

Если разработчик / ученик скажет ... Википедия ... чтобы скопировать / вставить код в свой проект, то просто попытается заставить его "работать", тогда единственные навыки, которые этот человек развивает, - это "Как Google". Там может быть какой-то процесс осмоса, но не целая куча. (Вы не поверите, сколько людей делают это на курсах колледжа)

ОДНАКО, если вы анализируете код других людей и действительно думаете о том, что происходит в самом коде, то это не делает человека плохим разработчиком. Это делает их решительным разработчиком и, вероятно, указывает на стиль обучения, который является более тактильным или визуальным. Я хорошо учусь на примере. Если кто-то говорит мне что-то или пытается мне это объяснить, я обычно прошу его показать мне, о чем он говорит.

Поиск, анализ и изучение кода на самом деле делает их хорошим разработчиком с течением времени , потому что они читают и изучают на языке, который они используют.

Я часто шучу, что знаю все тонкости компьютерных языков, чем родной английский. Что напрашивается вопрос; "Вы объясните мне это на Java, плз?"

Styler
источник
-1

Я думаю, что это немного похоже на игру в шахматы. Мы проверяем фрагменты индивидуально и прослеживаем, где они могут двигаться в соответствии с правилами, и мы должны пройти через эту сознательную проверку в течение некоторого времени, пока подсознание не включится, выявив паттерны и вдохновенные последовательности.

В программировании может быть больше частей и правил, я часто сталкиваюсь с синтаксисом и застреваю на ошибках, которые можно найти навсегда, пройдя по «правилам», но в конце концов подсознание сработает. Когда оно останется достаточно длинным, я смогу прочитать вернуться иногда и удивляться тому, что он может сделать.

стяжка
источник