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

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

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

(Примечание: я не говорю, что хорошие программисты не делают ничего, кроме программирования, но они делают больше, чем программы с 9 до 5)

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

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

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

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

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

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

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

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

«Googling it» в порядке!

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

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

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

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

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

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

Мои 5 центов

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

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

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

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

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

Для другого, я считаю, что люди, которые не имели опыта в отладке утечек памяти в C / C ++, не могут полностью оценить, что Java приносит в таблицу.

Также естественная прогрессия должна быть от «как я могу это сделать» до «как я могу найти библиотеку, которая делает это», а не наоборот.

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

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

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

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

Операторы печати являются допустимым способом отладки кода

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

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

Ваша задача – вывести себя из работы.

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

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

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

1) Деловые приложения :

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

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

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

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

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

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

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

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

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

Геттеры и сеттеры сильно злоупотребляют

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

Я не сторонник публичных полей, но против создания геттера / сеттера (или свойства) для каждого из них, а затем утверждая, что это инкапсуляция или скрытие информации … ха!

ОБНОВИТЬ:

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

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

Теперь создание частных полей, а затем использование IDE для автоматической генерации геттеров и сеттеров для каждого из них почти так же плохо, как использование открытых полей.

Многие думают:

private fields + public accessors == encapsulation

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

Наконец, позвольте мне процитировать дядю Боба в этой теме (взятой из главы 6 «Чистого кода»):

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

UML-диаграммы сильно переоценены

Конечно, есть полезные диаграммы, например диаграмма classов для композитного шаблона , но многие диаграммы 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, особенно хороший дизайн программного обеспечения, слишком разнообразен, чтобы осмысленно фиксироваться в шаблонах, особенно в небольшом количестве шаблонов, которые люди действительно могут запомнить – и они слишком абстрактны, чтобы люди действительно помнили больше, чем горстка. Поэтому они не очень помогают.

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

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

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

PHP отстой 😉

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

Unit Testing не поможет вам написать хороший код

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

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

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

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

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

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

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

Хорошо писать код мусора раз в то время

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

Код == Дизайн

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

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

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

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

Но в великой схеме вещей это просто работа.

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

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

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

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

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

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

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

Как это противоречиво?

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

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

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

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

Люди даже, кажется, доходят до того, что помещают значки в свои блоги, такие как «I’m Test Driven» или аналогичные, как если бы их строгое соблюдение единого подхода, какими бы ни были детали проекта проекта, на самом деле это хорошо .

Это не так.

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