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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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