Что вы наиболее противоречивое мнение программирования?
Это определенно субъективно, но я бы хотел, чтобы это не стало спорным. Я думаю, что это может быть интересным вопросом, если люди будут относиться к нему соответствующим образом.
Идея этого вопроса возникла в ветке комментариев из моего ответа на вопрос "Какие пять вещей вы ненавидите в своем любимом языке?" вопрос Я утверждал, что классы в C# должны быть запечатаны по умолчанию - я не буду приводить свои рассуждения в вопросе, но я мог бы написать более полное объяснение в качестве ответа на этот вопрос. Я был удивлен теплом обсуждения в комментариях (25 комментариев в настоящее время).
Итак, какие спорные мнения вы придерживаетесь? Я бы предпочел избегать таких вещей, которые в конечном итоге оказываются довольно религиозными с относительно небольшой базой (например, размещение фигурных скобок), но примеры могут включать такие вещи, как "модульное тестирование на самом деле не очень полезно" или "публичные поля действительно хороши". Важно (для меня, во всяком случае), что у вас есть причины, стоящие за вашим мнением.
Пожалуйста, представьте ваше мнение и аргументацию. Я бы посоветовал людям голосовать за обоснованные и интересные мнения независимо от того, согласны ли вы с ними или нет.
407 ответов
Программисты, которые в свободное время не занимаются программированием, никогда не станут такими же хорошими, как те, которые это делают.
Я думаю, что даже самые умные и талантливые люди никогда не станут по-настоящему хорошими программистами, если они не будут относиться к этому больше, чем к работе. Это означает, что они делают небольшие проекты на стороне, или просто возятся с множеством разных языков и идей в свободное время.
(Примечание: я не говорю, что хорошие программисты ничего не делают, кроме программирования, но они делают больше, чем программируют с 9 до 5)
Единственная "лучшая практика", которую вы должны использовать постоянно, - это "Используйте свой мозг".
Слишком много людей, прыгающих на слишком большом количестве повозок и пытающихся навязать методы, шаблоны, рамки и т. Д. Вещам, которые их не оправдывают. Если что-то новое или кто-то уважаемый имеет мнение, это не значит, что оно подходит всем:)
РЕДАКТИРОВАТЬ: Просто чтобы уточнить - я не думаю, что люди должны игнорировать лучшие практики, ценные мнения и т. Д. Просто, что люди не должны просто слепо прыгать на что-то, не думая о том, ПОЧЕМУ эта "вещь" настолько велика, применимо ли это к тому, что я и какие выгоды / недостатки это приносит?
Большинство комментариев в коде на самом деле являются пагубной формой дублирования кода.
Мы тратим большую часть времени на поддержание кода, написанного другими (или нами), и плохие, неправильные, устаревшие, вводящие в заблуждение комментарии должны быть в верхней части списка самых раздражающих артефактов в коде.
Я думаю, что в конечном счете многие люди просто исключают их, особенно эти чудовища цветочных ящиков.
Намного лучше сконцентрироваться на том, чтобы сделать код читабельным, рефакторинг по мере необходимости и свести к минимуму идиомы и причуды.
С другой стороны, многие курсы учат, что комментарии очень важны, чем сам код, что приводит к следующей строке, добавляющей один к стилю комментирования invoiceTotal.
"Погуглив это" - хорошо!
Да, я знаю, что это оскорбляет некоторых людей, что их годы интенсивного запоминания и / или славных стопок книг по программированию начинают уходить на второй план к ресурсу, к которому любой может получить доступ в течение нескольких секунд, но вы не должны держать это против людей которые используют это.
Слишком часто я слышу гугл-ответы на проблемы, являющиеся результатом критики, и это действительно бессмысленно. Прежде всего, следует признать, что всем нужны материалы для ссылки. Вы не знаете всего, и вам нужно искать вещи. В дополнение к этому, действительно ли имеет значение, где вы получили информацию? Имеет ли значение, если вы искали это в книге, искали в Google или слышали от говорящей лягушки, которую вы галлюцинировали? Нет. Правильный ответ - это правильный ответ.
Важно то, что вы понимаете материал, используете его как средство для достижения успешного программного решения, и клиент / ваш работодатель доволен результатами.
(хотя, если вы получаете ответы от галлюцинаторно говорящих лягушек, вам, вероятно, все равно придется получить некоторую помощь)
XML сильно переоценен
Я думаю, что слишком многие прыгают на сторону XML, прежде чем использовать свои мозги... XML для веб-контента - это здорово, так как он предназначен для него. В противном случае, я думаю, что некоторые проблемы определения и разработки должны опередить любое решение использовать его.
Мои 5 центов
Не все программисты созданы равными
Довольно часто менеджеры думают, что DeveloperA == DeveloperB просто потому, что у них одинаковый опыт и так далее. На самом деле производительность одного разработчика может быть в 10 раз или даже в 100 раз выше, чем у другого.
Говорить об этом политически рискованно, но иногда мне хочется отметить, что, несмотря на то, что несколько членов команды могут обладать одинаковыми навыками, это не всегда так. Я даже видел случаи, когда ведущие разработчики были "вне надежды", а младшие разработчики выполняли всю реальную работу - хотя я позаботился о том, чтобы они получили кредит.:)
Я не понимаю, почему люди думают, что Java - это самый лучший "первый" язык программирования для преподавания в университетах.
Во-первых, я считаю, что первый язык программирования должен быть таким, чтобы подчеркивать необходимость изучения потока управления и переменных, а не объектов и синтаксиса.
С другой стороны, я считаю, что люди, которые не имели опыта в отладке утечек памяти в C / C++, не могут в полной мере оценить то, что Java приносит в таблицу.
Также естественное развитие должно происходить от "как я могу это сделать" к "как я могу найти библиотеку, которая делает это", а не наоборот.
Если вы знаете только один язык, независимо от того, насколько хорошо вы его знаете, вы не великий программист.
Кажется, есть отношение, которое гласит, что если вы действительно хорошо разбираетесь в C#, Java или любом другом языке, который вы начали изучать, то это все, что вам нужно. Я не верю этому - каждый язык, который я когда-либо изучал, научил меня чему-то новому в программировании, которое я смог вернуть в свою работу со всеми остальными. Я думаю, что любой, кто ограничивает себя одним языком, никогда не будет так хорош, как мог бы быть.
Это также указывает на то, что мне не хватает любознательности и желания экспериментировать, что не обязательно соответствует тем качествам, которые я ожидал бы найти у действительно хорошего программиста.
Операторы печати являются правильным способом отладки кода.
Я считаю, что отладка вашего кода вполне возможна, засоряя его System.out.println (или любой другой оператор печати работает для вашего языка). Часто это может быть быстрее, чем отладка, и вы можете сравнить распечатанные результаты с другими запусками приложения.
Просто убедитесь, что удалили операторы печати, когда вы идете в производство (или лучше, превратите их в операторы регистрации)
Ваша работа - убрать себя с работы.
Когда вы пишете программное обеспечение для своего работодателя, любое программное обеспечение, которое вы создаете, должно быть написано таким образом, чтобы его мог подобрать любой разработчик и понять с минимальными затратами усилий. Он хорошо спроектирован, четко и последовательно написан, четко отформатирован, задокументирован там, где это необходимо, собирается ежедневно, как и ожидалось, проверяется в репозитории и соответствующим образом корректируется.
Если вас сбивает автобус, увольняют, увольняют или уходят с работы, ваш работодатель должен быть в состоянии заменить вас в любой момент, и следующий парень может вступить в вашу должность, взять ваш код и быть в курсе событий. бег в течении недели топы. Если он или она не могут этого сделать, значит, вы с треском провалились.
Интересно, что я обнаружил, что достижение этой цели сделало меня более ценным для моих работодателей. Чем больше я стремлюсь быть одноразовым, тем более ценным я становлюсь для них.
1) Фарс бизнес-приложений:
Я думаю, что вся структура "Предприятия" - это дым и зеркала. 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***. Настоящий ученый-компьютерщик видит язык с точки зрения понятий и синтаксисов, которые он использует, и рассматривает методологии программирования как одну из многих, и обладает таким хорошим пониманием основополагающих принципов, как выбор новых языков, методов проектирования или языков спецификаций. быть тривиальным
Геттеры и сеттеры сильно перегружены
Я видел миллионы людей, утверждающих, что публичные поля являются злом, поэтому они делают их частными и предоставляют добытчики и сеттеры для всех из них. Я полагаю, что это почти идентично открытию полей, может быть немного по-другому, если вы используете потоки (но, как правило, это не так) или если ваши средства доступа имеют логику ведения бизнеса / представления (по крайней мере, что-то "странное").
Я не за публичные поля, но против создания геттера / установщика (или свойства) для каждого из них, а затем утверждаю, что это инкапсуляция или сокрытие информации... ха!
ОБНОВИТЬ:
Этот ответ вызвал некоторые противоречия в комментариях, поэтому я постараюсь немного его прояснить (я оставлю оригинал без изменений, поскольку за это проголосовали многие люди).
Прежде всего: любой, кто использует открытые поля, заслуживает тюрьмы
Теперь создание личных полей и последующее использование среды IDE для автоматического создания методов получения и установки для каждого из них почти так же плохо, как использование открытых полей.
Многие люди думают:
private fields + public accessors == encapsulation
Я говорю (автоматическая или нет) генерация пары геттер / сеттер для ваших полей эффективно противоречит так называемой инкапсуляции, которую вы пытаетесь достичь.
Наконец, позвольте мне процитировать дядю Боба в этой теме (взято из главы 6 "Чистый код"):
Есть причина, по которой мы держим наши переменные в секрете. Мы не хотим, чтобы кто-то еще зависел от них. Мы хотим свободы менять свой тип или реализацию по прихоти или импульсу. Почему же тогда так много программистов автоматически добавляют геттеры и сеттеры к своим объектам, выставляя свои частные поля, как если бы они были открытыми?
UML-диаграммы сильно переоценены
Конечно, существуют полезные диаграммы, например диаграмма классов для составного шаблона, но многие диаграммы UML не имеют абсолютно никакого значения.
Мнение: SQL это код. Относитесь к этому как таковой
То есть, так же, как ваш C#, Java или другой любимый язык объектов / процедур, разработайте стиль форматирования, который будет удобочитаемым и поддерживаемым.
Ненавижу, когда вижу неаккуратный свободно форматированный код SQL. Если вы кричите, когда видите на странице оба стиля фигурных скобок, почему или почему вы не кричите, когда видите свободно отформатированный SQL или SQL, который затемняет или запутывает условие JOIN?
Читаемость является наиболее важным аспектом вашего кода.
Даже больше, чем правильность. Если это читабельно, это легко исправить. Это также легко оптимизировать, легко изменить, легко понять. И, надеюсь, другие разработчики тоже могут чему-то научиться.
Если вы разработчик, вы должны быть в состоянии написать код
В прошлом году я провел немало собеседований, и со своей стороны я должен был проверить, как люди думают, и как они реализуют простые и умеренные алгоритмы на белой доске. Я изначально начал с таких вопросов, как:
Учитывая, что число Pi можно оценить с помощью функции 4 * (1 - 1/3 + 1/5 - 1/7 + ...) с большим количеством членов, дающих большую точность, напишите функцию, которая вычисляет число Pi с точностью до 5 десятичных знаков,
Это проблема, которая должна заставить вас задуматься, но не должна быть недоступна опытному разработчику (на нее можно ответить примерно в 10 строках C#). Однако многие из наших (предположительно предварительно отобранных агентством) кандидатов даже не смогли начать отвечать на них или даже объяснить, как они могли бы ответить на него. Поэтому через некоторое время я начал задавать более простые вопросы, такие как:
Учитывая, что площадь круга определяется как Pi, умноженная на квадрат радиуса, напишите функцию для вычисления площади круга.
Удивительно, что более половины кандидатов не смогли написать эту функцию на любом языке (я могу читать самые популярные языки, поэтому я позволяю им использовать любой язык по своему выбору, включая псевдокод). У нас были "разработчики на C#", которые не могли написать эту функцию на C#.
Я был удивлен этим. Я всегда думал, что разработчики должны иметь возможность писать код. Похоже, что в настоящее время это противоречивое мнение. Конечно, это среди кандидатов на собеседование!
Редактировать:
В комментариях много дискуссий о том, является ли первый вопрос хорошим или плохим, и следует ли вам задавать такие сложные вопросы, как этот в интервью. Я не собираюсь углубляться в это здесь (это совершенно новый вопрос), кроме того, чтобы сказать, что вы в значительной степени упускаете смысл поста.
Да, я сказал, что люди не могут добиться успеха с этим, но второй вопрос тривиален, и многие люди также не могут добиться успеха с этим вопросом! Любой, кто называет себя разработчиком, должен иметь возможность написать ответ на второй вопрос за несколько секунд, даже не задумываясь. И многие не могут.
Использование венгерской нотации должно быть наказано смертью.
Это должно быть достаточно спорным;)
Шаблоны дизайна вредят хорошему дизайну больше, чем помогают ему.
Дизайн программного обеспечения IMO, особенно хороший дизайн программного обеспечения, слишком разнообразен, чтобы его можно было осмысленно отражать в шаблонах, особенно в небольшом количестве шаблонов, которые люди могут на самом деле запомнить - и они слишком абстрактны, чтобы люди действительно могли запомнить больше, чем несколько. Так что они мало помогают.
И с другой стороны, слишком многие люди влюбляются в эту концепцию и пытаются применять шаблоны повсеместно - обычно в конечном коде вы не можете найти фактический дизайн между всеми (совершенно бессмысленными) синглетонами и абстрактными фабриками.
Меньше кода лучше, чем больше!
Если пользователи говорят "это все?", А ваша работа остается невидимой, все сделано правильно. Слава может быть найдена в другом месте.
Модульное тестирование не поможет вам написать хороший код
Единственная причина для проведения модульных тестов - убедиться, что уже работающий код не сломается. Написание тестов первым или написание кода для тестов смешно. Если вы напишите в тесты перед кодом, вы даже не будете знать, каковы крайние случаи. Вы могли бы иметь код, который проходит тесты, но все еще не работает в непредвиденных обстоятельствах.
И, кроме того, хорошие разработчики будут поддерживать сплоченность на низком уровне, что сделает добавление нового кода маловероятным, чтобы вызвать проблемы с существующим материалом.
На самом деле, я обобщу это еще дальше,
Большинство "Лучших практик" в разработке программного обеспечения предназначены для того, чтобы плохие программисты не наносили слишком много урона.
Они здесь, чтобы держать в руках плохих разработчиков и удерживать их от глупых ошибок. Конечно, так как большинство разработчиков плохие, это хорошо, но хорошие разработчики должны получить пропуск.
Напишите маленькие методы. Кажется, что программисты любят писать более длинные методы, где они делают несколько разных вещей.
Я думаю, что метод должен быть создан везде, где вы можете назвать его.
Можно писать код мусора время от времени
Иногда быстрый и грязный кусок мусорного кода - это все, что нужно для выполнения конкретной задачи. Шаблоны, ORM, SRP, что угодно... Подберите консоль или веб-приложение, напишите несколько встроенных sql (чувствует себя хорошо) и выпустите требование.
Код == Дизайн
Я не фанат сложных UML-диаграмм и бесконечной документации кода. На языке высокого уровня ваш код должен быть читаемым и понятным как есть. Сложная документация и диаграммы на самом деле более не удобны для пользователя.
Вот статья на тему " Код как дизайн".
Разработка программного обеспечения - это просто работа
Не поймите меня неправильно, мне очень нравится разработка программного обеспечения. Я написал блог за последние несколько лет на эту тему. Я провел здесь достаточно времени, чтобы набрать>5000 очков репутации. И я работаю в стартапе, обычно проводя 60 часов в неделю за гораздо меньшие деньги, чем я мог бы получить в качестве подрядчика, потому что команда фантастическая, а работа интересная.
Но по большому счету это просто работа.
По важности он относится ко многим вещам, таким как семья, моя подруга, друзья, счастье и т. Д., И к другим вещам, которые я бы предпочел делать, если бы у меня был неограниченный запас денег, например, езда на мотоциклах, парусных яхтах или сноуборде.
Я думаю, что иногда многие разработчики забывают, что разработка - это то, что позволяет нам иметь более важные вещи в жизни (и делать это, делая то, что нам нравится), а не быть конечной целью самой по себе.
Я также думаю, что нет ничего плохого в наличии бинарных файлов в системе контроля версий... если для этого есть веские причины. Если у меня есть сборка, для которой у меня нет исходного кода, и она может не обязательно находиться в одном и том же месте на каждом компьютере разработчика, я обычно помещаю ее в каталог "binaries" и ссылаюсь на нее в проекте, используя относительный путь,
Похоже, многие считают, что я должен быть сожжен на костре за то, что даже упомянул "контроль источника" и "двоичный код" в одном предложении. Я даже знаю места, где есть строгие правила, согласно которым вы не можете их добавить.
Каждый разработчик должен быть знаком с базовой архитектурой современных компьютеров. Это также относится к разработчикам, которые нацелены на виртуальную машину (может быть, даже больше, потому что им снова и снова говорят, что им не нужно беспокоиться об управлении памятью и т. Д.)
Архитекторы / дизайнеры программного обеспечения переоценены
Как разработчик, я ненавижу идею архитекторов программного обеспечения. В основном это люди, которые больше не пишут полный рабочий день, читают журналы и статьи, а затем рассказывают вам, как разрабатывать программное обеспечение. Это должны делать только люди, которые действительно пишут программное обеспечение на полную ставку. Мне все равно, если вы были лучшим программистом в мире 5 лет назад, прежде чем вы стали архитектором, ваше мнение для меня бесполезно.
Как это для спорных?
Изменить (уточнить): Я думаю, что большинство архитекторов программного обеспечения являются отличными бизнес-аналитиками (общаются с заказчиками, пишут требования, тестируют и т. Д.), Я просто думаю, что им не место в разработке программного обеспечения высокого уровня или чего-либо еще.
Не существует подхода "один размер подходит всем"
Я удивлен, что это противоречивое мнение, потому что оно мне кажется здравым смыслом. Тем не менее, в популярных блогах есть много статей, пропагандирующих подход "один размер подходит всем", поэтому я думаю, что на самом деле я в меньшинстве.
Вещи, которые я видел в качестве правильного подхода для любого проекта - до того, как о нем будет известна какая-либо информация, - это такие вещи, как использование управляемой тестами разработки (TDD), проектирование на основе доменов (DDD), объектно-реляционное сопоставление (ORM) Agile (заглавная A), объектная ориентация (OO) и т. Д. И т. Д., Охватывающие все - от методологий до архитектур и компонентов. Конечно, с хорошими товарными акронимами.
Кажется, что люди даже заходят так далеко, что размещают значки в своих блогах, таких как "Я тест-драйв" или тому подобное, как будто их строгое соблюдение единого подхода, независимо от деталей проекта, на самом деле хорошо.
Это не так.
Выбор правильных методологий, архитектур, компонентов и т. Д. Должен выполняться для каждого отдельного проекта и зависит не только от типа проекта, над которым вы работаете, и от его уникальных требований, но также от размера и возможностей. команды, с которой вы работаете.