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

Еще не проверял его на предмет противоречий, но он может быть потенциальным:

Лучшая строка кода - та, которую вы никогда не писали.

Менеджеры знают все.

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

И еще одно, что следует из первого:

Никогда не время делать все правильно, но всегда есть время сделать это снова

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

И тот, который пришел в голову сегодня при попытке настроить маршрутизатор только с веб-интерфейсом:

Веб-интерфейсы предназначены для присосок

CLI на предыдущем версия прошивки была ой как приятно. Эта версия имеет веб-интерфейс, который пытается скрыть всю сложность сети от невежественных ИТ-дроидов и даже не может правильно настроить VLAN.

Инженеры-программисты не должны работать с ребятами из информатики

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

Мнение: Продолжительность в области развития не всегда означает то же самое, что и опыт.

Многие профессии обращаются к «многолетнему опыту» на языке. Да, 5 лет C # могут иметь смысл, так как вы можете изучать новые трюки, а что нет. Тем не менее, если вы работаете в компании и поддерживаете одну и ту же кодовую базу в течение нескольких лет, я чувствую, что вы не получаете степени воздействия на различные ситуации как на человека, который работает в разных ситуациях и с потребностями клиента.

Однажды я взял интервью у человека, который гордился тем, что имеет 10-летний опыт программирования и работал с VB5, 6 и VB.Net ... все в одной компании в течение этого времени. После дополнительных исследований я обнаружил, что, хотя он работал со всеми этими версиями VB, он только обновлял и постоянно поддерживал свое оригинальное приложение VB5. Никогда не изменял архитектуру и не позволял мастерам обновления делать свое дело. Я брал интервью у людей, у которых всего 2 года, но они работали над несколькими проектами, у которых больше «опыта», чем у него.

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

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

Это, кажется, прямо противоречит хорошей корпоративной практике с тупыми объектными объектами и более толстым уровнем обслуживания (что требует много вопросов). Хммм, мысли?

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

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

Microsoft Windows - лучшая платформа для разработки программного обеспечения.

Обоснование: Microsoft портит своих разработчиков отличными и дешевыми инструментами разработки, платформа и ее API хорошо документированы, платформа развивается быстрыми темпами, что создает множество возможностей для разработчиков, ОС имеет большую базу пользователей, что важно по очевидным коммерческим причинам, есть большое сообщество разработчиков Windows, меня еще не уволили за выбор Microsoft.

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

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

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

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

(Это должно было быть спорным, помните?)

Я ненавижу университеты и институты, предлагающие короткие курсы для обучения программированию для новичков. Это откровенное позор и презрение к искусству ^{1 и науке программирования.}

Они начинают преподавать C, Java, VB (отвратительно) людям без хорошего понимания аппаратных средств и фундаментальных принципов компьютеров. Сначала следует научить MACHINE книгам, подобным Архитектура компьютерной системы Морриса Мано , а затем научить концепции инструктирования машины для решения проблем вместо травления семантики и синтаксис одного языка программирования.

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

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

Подумайте об этом, если вас учили только, что 2x2 - это 4, а не концепция умножения?

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

Плохие программисты не зависят от языка

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

«Java Sucks» - да, я знаю, что мнение определенно не поддерживается всеми:)

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

G-Man

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

Мнение: классы должны быть запечатаны по умолчанию в C #

Обоснование:

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

C # сделал шаг в правильном направлении (относительно Java), сделав методы запечатанными по умолчанию. Тем не менее, я считаю, что еще один шаг - сделать классы запечатанными по умолчанию - был бы еще лучше. В частности, легко переопределить методы (или не явным образом запечатать существующие виртуальные методы, которые вы не переопределяете), так что в результате вы получите непредвиденное поведение. Это на самом деле не помешает вам делать все, что вы можете сделать в настоящее время - это просто изменение по умолчанию , а не изменение доступных параметров. Это было бы "более безопасным" по умолчанию, хотя, как и доступ по умолчанию в C #, всегда "самая частная видимость, доступная на тот момент".

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

Встречный аргумент :

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

Если бы я был спорным, я бы предположил, что Джон Скит не всемогущ ..

Мнение: модульные тесты не нужно записывать заранее, а иногда и вовсе.

Обоснование: разработчики сосут при тестировании своего собственного кода. Мы делаем. Вот почему у нас обычно есть тестовые команды или группы QA.

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

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

Все переменные / свойства должны быть по умолчанию readonly / final.

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

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

2. Аккумуляторы. Например, представьте случай суммирования значений в массиве или даже в списке / строке, которые накапливают некоторую информацию о чем-то еще.

   1111 Сегодня есть лучшие средства для достижения той же цели. Функциональные языки имеют функции высшего порядка, Python имеет понимание списка, а .NET имеет LINQ. Во всех этих случаях нет необходимости в изменяемом аккумуляторе / держателе результата.

   Рассмотрим частный случай конкатенации строк. Во многих средах (.NET, Java) строки на самом деле являются неизменяемыми. Зачем тогда вообще разрешать присваивание строковой переменной? Намного лучше использовать класс строителя (то есть a StringBuilder) все время.

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

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

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

Умный программист опасен

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

Объекты никогда не должны находиться в недопустимом состоянии.

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

MyClass c = new MyClass(); // Object in invalid state. Doesn't have an ID.
c.setId(12345); // Now object is valid.

По моему мнению, должно быть невозможно , чтобы объект когда-либо оказывался в недопустимом состоянии, и API класса должен активно применять свои инварианты класса после каждого вызова метода.

Конструкторы и методы-мутаторы должны атомарно переводить объект из одного допустимого состояния в другое. Это намного лучше:

MyClass c = new MyClass(12345); // Object starts out valid. Stays valid.

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

Архитекторы, которые не пишут код, бесполезны.

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

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

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

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

[РЕДАКТИРОВАТЬ: уточнение, основанное на комментариях]

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

Я бы предпочел один из этих вариантов:

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

2. Позвольте мне увидеть все ответы, чтобы я мог использовать опцию «найти» в моем браузере (дать мне все результаты).

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

-
Bmb

Уважение единой ответственности Принцип

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

Мнение: разработчики должны тестировать свой собственный код

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

Мнение: никогда не было разного кода между сборками "debug" и "release"

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

Мнение: явное объявление переменной - отличная вещь.

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

Никто никогда не давал мне объяснений лучше, чем «ну, это экономит время, так как мне не нужно писать« int i; »». Уххххххххххххххххххххх ... да, конечно, но сколько времени нужно, чтобы отследить ошибку во время выполнения?

Разметка кода имеет значение

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

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

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

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

Конечным результатом является то, что, как только вы привыкните к нему (что обычно занимает 1-3 дня), он становится приятным для глаз, его легче и быстрее понять, и он менее затратен для глаз и мозга, поскольку выложен таким образом, чтобы легче было принять.

Почти все без исключения все, кого я просил попробовать этот стиль (включая меня), сначала говорили: «Тьфу, я ненавижу это!», Но через день или два сказали: «Я люблю это - мне трудно это не чтобы вернуться и переписать все мои старые вещи таким образом! ".

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

[Редактировать]

Я наконец-то дошел до блога об этом (после многих лет, проведенных в " значение «фаза»: Часть первая , Часть вторая , Часть третья .

Контроль источника: все, кроме SourceSafe

Также: Исключительная блокировка - зло .

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

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

До 1 января 1970 года истина и ложь были наоборот ...

Если у вас есть какие-либо идеи, как программировать вы не подходите для размещения кнопки на форме

Это спорный достаточно? ;)

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

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

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