Что вы наиболее противоречивое мнение программирования?

Не все программисты созданы равными

Довольно часто менеджеры думают, что DeveloperA == DeveloperB просто потому, что у них одинаковый уровень опыта и так далее. На самом деле производительность одного разработчика может быть в 10 раз или даже в 100 раз выше, чем у другого.

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

XML сильно переоценен

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

Мои 5 центов

Большинство комментариев в коде на самом деле являются пагубной формой дублирования кода.

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

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

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

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

«Гуглить» - это хорошо!

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

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

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

(хотя, если вы получаете ответы от галлюцинаторных говорящих лягушек, вам, вероятно, все равно придется получить некоторую помощь)

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

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

РЕДАКТИРОВАТЬ: Просто чтобы уточнить - я не думаю, что люди должны игнорировать лучшие практики, ценные мнения и т. Д. Просто люди не должны просто вслепую прыгать на чем-то, не задумываясь о том, ПОЧЕМУ эта «вещь» настолько велика, применима ли она к тому, что я делаю, и КАКИХ преимуществ / недостатков она приносит?

Производительность имеет значение .

Миру нужно больше GOTO

GOTO часто избегают религиозно, без каких-либо объяснений, кроме «мой профессор сказал мне, что GOTO плохие». У них есть цель, и она значительно упростит производственный код во многих местах.

Тем не менее, они на самом деле не нужны в 99% кода, который вы когда-либо будете писать.

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

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

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

PHP отстой; -)

Доказательство в пудинге.

1) Фарс Business Apps :

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

Возьмите любой обычный Java или .NET ORM, или любой предположительно современный MVC-фреймворк, который делает «магию» для решения утомительных и простых задач. Вы заканчиваете тем, что пишете огромное количество уродливого шаблона XML, который трудно проверить и написать быстро. У вас есть массивные API, половина из которых предназначена только для интеграции работы других API, интерфейсов, которые невозможно переработать, и абстрактных классов, которые нужны только для преодоления негибкости Java и C #. Нам просто не нужно больше всего этого.

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

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

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

2) Требуемый n-летний опыт работы:

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

3) Общая учебная программа по специальности «информатика»:

Большинство степеней по информатике и разработке программного обеспечения - бык. Если ваш первый язык программирования - Java или C #, то вы делаете что-то не так. Если вы не получаете несколько курсов, полных алгебры и математики, это неправильно. Если вы не углубляетесь в функциональное программирование, оно неполное. Если вы не можете применить инварианты цикла к тривиальному циклу for, вы, как предполагаемый специалист по информатике, не стоите затрачивать столько сил. Если у вас есть опыт работы с языками x и y и ориентацией на объекты, он полон s ***. Настоящий ученый-компьютерщик видит язык с точки зрения понятий и синтаксисов, которые он использует, и рассматривает методологии программирования как одну из многих, и обладает таким хорошим пониманием основополагающих принципов, как выбор новых языков, методов проектирования или языков спецификаций. быть тривиальным.

Степень в области компьютерных наук или в других областях ИТ делает вас более разносторонним программистом

Мне все равно, сколько у вас лет опыта, сколько блогов у вас » Вы читали, сколько проектов с открытым исходным кодом вы участвуете. Квалификация (я бы рекомендовал более 3 лет) открывает вам другой способ мышления и дает вам хорошую основу.

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

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

Я не был бы удивлен, если бы этот ответ был отклонен.

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

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

Вы должны знать, как печатать, чтобы быть программистом.

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

Я никогда не встречал никого, кто знает , как печатать, но настаивает, что это не имеет значения.

См. Также: Самый грязный маленький секрет программирования

SESE (однократный однократный выход) - это не закон

Пример:

public int foo() {
   if( someCondition ) {
      return 0;
   }

   return -1;
}

против:

public int foo() {
   int returnValue = -1;

   if( someCondition ) {
      returnValue = 0;
   }

   return returnValue;
}

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

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

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

Если вы хотите стать программистом, изучите Java. Если вы хотите стать специалистом по информатике, выучите как минимум три почти совершенно разных языка. например (ассемблер, c, lisp, ruby, smalltalk)

Большинство профессиональных программистов сосут

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

Меньше кода - лучше, чем больше!

Если пользователи говорят: «Это все?», А ваша работа остается невидимой, она сделана правильно. Слава может быть найдена в другом месте.

C ++ является одним из худших языков программирования - НИКОГДА.

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

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

Это не очень хороший язык для изучения ОО-концепций. Он ведет себя как «C с оберткой класса» вместо правильного языка OO.

Я мог бы продолжать, но пока оставлю это. Мне никогда не нравилось программирование на C ++, и хотя я «порезался» на FORTRAN, я полностью любил программирование на C. Я все еще думаю, что C был одним из замечательных «классических» языков. Что-то, что C ++, конечно, НЕ, на мой взгляд.

Приветствия,

-R

РЕДАКТИРОВАТЬ: Ответить на комментарии по обучению C ++. Вы можете преподавать C ++ двумя способами - либо преподавать его как C "на стероидах" (начните с переменных, условий, циклов и т. Д.), Либо преподавать как чистый язык "OO" (начните с классов, методов и т. Д.). Вы можете найти учебные тексты, которые используют тот или иной из этих подходов. Я предпочитаю последний подход (сначала ОО), поскольку он подчеркивает возможности С ++ как языка ОО (который был первоначальным акцентом на дизайн С ++). Если вы хотите преподавать C ++ «как C», то я думаю, что вы должны преподавать C, а не C ++.

Но проблема с C ++ как с первым языком в моем опыте заключается в том, что язык просто слишком БОЛЬШОЙ, чтобы преподавать за один семестр, плюс большинство «вводных» текстов пытаются охватить все. Просто невозможно охватить все темы в курсе «первого языка». Вы должны по крайней мере разделить его на 2 семестра, и тогда он больше не будет «первым языком», ИМО.

Я преподаю C ++, но только как «новый язык», то есть вы должны хорошо владеть каким-то предшествующим «чистым» языком (не скриптами или макросами), прежде чем вы сможете записаться на курс. C ++ - это очень хороший «второй язык» для изучения, IMO.

-R

'Нет Редактировать: (к Конраду)

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

Я написал MIDI-движок, сначала на C, затем на C ++ (по запросу производителя) для встроенного контроллера (звуковой карты). В конце концов, чтобы удовлетворить требования к производительности (тайминги MIDI и т. Д.), Нам пришлось вернуться к чистому C для всего основного кода. Мы могли использовать C ++ для высокоуровневого кода, и иметь классы было очень приятно - но нам нужен был C, чтобы получить производительность на более низком уровне. Код на C был на порядок быстрее, чем код на C ++, но ассемблер с ручным кодом был лишь немного быстрее, чем скомпилированный код на C. Это было еще в начале 1990-х годов, просто чтобы правильно описать события.

-R

Не существует подхода «один размер подходит всем» к развитию

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

Вещи, которые я видел, как правильный подход для любого проекта - до того, как станет известна какая-либо информация о нем - это такие вещи, как использование Test Driven Development (TDD) Проектирование, управляемое доменом (DDD), объектно-реляционное сопоставление (ORM), Agile (заглавная A), объектная ориентация (OO) и т. Д. И т. Д., Охватывающее все - от методологий до архитектур и компонентов. Конечно, с хорошими товарными сокращениями.

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

Это не так.

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

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

Разработка программного обеспечения - это просто работа

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

Но, по большому счету, это просто работа.

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

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

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

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

Ленивые программисты - лучшие программисты

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

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

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

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

Code == Design

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

Вот статья на тему Код как дизайн .

Можно время от времени писать код мусора

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

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

Я думаю, что метод должен быть создан везде, где вы можете назвать его.

Модульное тестирование не поможет вам написать хороший код

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

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

На самом деле, я обобщу это еще дальше:

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

Они здесь, чтобы держать в руках плохих разработчиков и удерживать их от глупых ошибок. Конечно, поскольку большинство разработчиков плохие, это хорошо, но хорошие разработчики должны получить пропуск.

Архитекторы / дизайнеры программного обеспечения переоценены

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

Как это для спорных?

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

Две строки кода слишком много.

Если у метода есть вторая строка кода, это запах кода. Рефакторинг.

Пользователи не идиоты, а вы.

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

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

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