Неужели использование документации в качестве разработчика заставляет меня выглядеть непрофессионально?

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

Большинство из нас, разработчиков, не могут запомнить тысячи строк документации… все время, _ особенно когда мы переключаемся между технологиями_

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

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

Кто-то однажды сказал мне что-то вроде: “Хирург не может читать свои книги каждый раз, когда ему приходится оперировать пациента”.

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

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

Профессионализм и знания - две совершенно разные вещи.

Поиск вещей из сторонних источников означает, что вам не хватает знаний, а не профессионализма.

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

Не искать вещи, не зная, что вещи являются непрофессиональными, но это не ваш случай.

Дальнейшее чтение об эффекте, который контрастирует с вашей “стратегией использования документации”: Эффект Даннинга-Крюгера

Неужели использование документации в качестве разработчика делает меня непрофессионалом?

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

Меня так часто высмеивают за использование SO/Documentation, что заставляет усомниться в моих способностях

Это может быть не самым эффективным способом решения ваших задач.

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

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

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

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

Другие предоставили твердые ответы, но никто на самом деле не обращается к этому лоб в лоб; смелый акцент мой:

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

Кто эти люди “высмеивают” вас и откуда вы знаете это “…заставляет других сомневаться в [ваших] способностях?”

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

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

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

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

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

На самом деле, я защищал других разработчиков несколько раз, когда клиент консалтинговой компании сказал что-то вроде “почему я плачу хорошие деньги за того, кто не может даже написать код, не посмотрев его в интернете?”

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

Это, конечно, не непрофессионально, чтобы искать вещи, когда вы незнакомы.

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

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

Возьмем, к примеру, функцию mail() . Знаете ли вы…

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

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

При отправке почты, письмо должно содержать заголовок From (От). Это может быть установлено с помощью параметра additional_headers, или по умолчанию в php.ini.

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

• Параметр $to должен соответствовать RFC 2822 .

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

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

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

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

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

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

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

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

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

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

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

У вас уже есть несколько хороших ответов, но позвольте мне добавить небольшой поворот…

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

Не используя документацию

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

Только учебники?

Люди часто ищут учебники или фрагменты кода, включая SO, withwith никогда не ссылаются на документацию, раздражайте меня до бесконечности. Это поведение, на мой взгляд, огромная ловушка. Оно приводит к своего рода программированию, подпитываемому полузабудочными, произвольными, несистематическими “знаниями”. Эти программисты имеют тенденцию заканчиваться множеством предрассудков. Вот откуда берутся такие самородки, как “никогда не используй git rebase”, “никогда не используй not in в SQL”, “всегда делай XXX”, “никогда не делай YYY”. Им будет очень трудно придумать что-то из коробки, придумать новые идеи, сформировать интуицию о том, как структурировать свои приложения и все такое, что делает их отличными разработчиками.

Я бы призвал вас сначала решить любую проблему, посмотрев документацию/ссылку, а then ищите SO или другие фрагменты.

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

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

Документация

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

я не нахожу странным читать, например, старую классику C++ (старую добрую бумагу), Gang of Four Design Patterns, (он-лайн версию) “Programming Ruby” manual, очень хорошо сделанные Perl manpages, книгу Git, некоторые RFC, HTML/XML/etc. спецификации и т.д. спереди и сзади. Я бы делал и делал это даже в свободное время и, честно говоря, ожидал бы этого от любого программиста, стоящего его соли (в зависимости от того, с чем они работают, очевидно). Я также прекрасно понимаю, что я (по крайней мере, в компаниях, в которых работал, в последние десятилетия) совершенно один с этим мнением.

(N.B.: Очевидно, что не нужно запоминать огромные списки ссылок на API, но хотя бы замалчивать их, чтобы посмотреть, что доступно и в чем “дух” API, кажется. )

После тщательного изучения темы, then пришло время взглянуть на сторонний код для вдохновения, или посмотреть на старые вопросы по SO (или задать новые вопросы самостоятельно).

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

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

Меня так часто высмеивают за использование переполнения стека/документации

Мнение других людей о вас не определяет you, они только определяют them

Неужели использование документации в качестве разработчика делает меня непрофессионалом?

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

“Хирург не может читать свои книги каждый раз, когда ему приходится оперировать пациента”.

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

Если мне придется писать код во время собеседования на другую работу, то, наверное, не стоит использовать документацию

Зависит от правил собеседования, некоторые разрешают, некоторые - нет. В частности, если это тест, он может быть разрешен. Хорошая идея сначала проверить!