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

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

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

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

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

159 голосов | спросил 6 revs, 4 users 58%
Newly Insecure
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

26 ответов


237

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

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
109

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
70

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

  

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

     

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

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

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
54

Существует теория обучения, называемая Kolb cycle (после человека, который ее описал). Записи в этом цикле:

  Конкретный опыт -> Отражательное наблюдение
    ^ |
    | v
Активное экспериментирование <- Абстрактная концептуализация
 

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
39

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

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

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

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

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

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

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

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

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

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
24

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

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
14

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

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

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

Вам не нужно быть таким же хорошим, ни лучше, чем кем бы то ни было. Вы должны довольствоваться тем, что вам всегда будет недоставать, и что вы постоянно учитесь. Если вы не можете быть довольны тем, что являетесь разработчиком низшего уровня, вы НИКОГДА не будете счастливы.

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
12

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

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

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
8
  

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

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

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

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

  

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
7

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

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
5

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
4

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

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
3

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
3

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
3

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

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

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

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

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

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

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
3

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

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

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

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

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

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

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

  1. Если вы боретесь с синтаксисом, вам может не хватить практики. Это особенно верно, если вы копируете и вставляете прямо в свой код вместо того, чтобы разрабатывать повторение и, может, я могу сказать? â € ™ мышечная память , которая поможет вам стать действительно хорошими. Чтобы противостоять этому, просто создавайте упражнения и дисциплину, фокусируясь на повторении и времени, которые улучшат ваш объект в тех областях, которые вы хотите. Предложения:
    • Напишите простую программу на одном языке один раз в день, каждый день.
    • Введите примеры вместо копирования и вставки.
  2. Если вы боретесь с построением решений для проблем с умеренным размером, вы, возможно, не получите достаточного опыта в строительстве. Попробуйте эти:
    • Начните проект среднего размера по какой-либо технологии или на языке, который вы хотите получить. Или попробуйте свою руку, используя функцию chunkier в проекте с открытым исходным кодом, в котором вы заинтересованы. Сражайтесь с ним немного каждый день. (Помните, когда вы идете по этим более крупным проектам: идите по ним кирпич за кирпичом. Не пытайтесь все это сразу создать!)
    • Использовать ту же самую новую функцию в течение четырех последовательных дней в четырех разных контекстах.
    • Задайте себе код, чтобы отключить веб-браузер!
    • Соблюдайте заметки о материалах, которые вы изучаете. Синтезируйте то, что вы изучаете, и запишите свои наблюдения. (На самом деле, записывая вещи и заставляя себя что-то выражать своими словами, мне очень помогает.)
    • Напишите ответы и проверьте их, чтобы вопросы StackOverflow касались технологии, которую вы поглощаете. (Это часто имеет дополнительное преимущество, когда вы получаете небольшую репутацию, пока вы учитесь. :-))
  3. Возможно, вы слишком тонко распространяете свою практику. Кажется, вы работаете на разных языках. Это имеет много преимуществ, но у него есть недостаток в разбавлении вашего опыта. Если вы проводите время на пяти разных языках, вы запомните меньше, чем если бы вы проводили одно и то же время на одном языке. Хуже того, есть много не совсем похожих родственников между разными языками (это было еще, если, elsif, или elif?), Чтобы покончить с вами. Чтобы противостоять этому, заострите внимание. Выберите одно, чтобы учиться и учиться холодно. Затем переходите к следующему.
ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
3

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

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

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
3

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
3

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

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
2

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

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
2
  

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
1

Поэтому чтение книг с примерами и обращение к ним - плохое программирование - это контекст вашего вопроса. Хорошо видя, что мало кто документирует свой API, книга - это все, что у нас осталось.

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

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
1

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

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
0

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
-1

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

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

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27
-1

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

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

ответил Wyatt Barnett 2 J0000006Europe/Moscow 2011, 06:39:27

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132