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

Если вы хотите написать хорошее программное обеспечение, то отойдите от компьютера

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

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

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

Пройдите милю на их месте, а затем напишите свой код.

Программирование находится в зачаточном состоянии.

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

2. Документация по языкам распространяется небрежно через Интернет (здесь помогает стекопоток).

3. Языки не могут развиваться синтаксически без нарушения предыдущих версий.

4. Отладка все еще часто выполняется с помощью printf.

5. Языковые библиотеки или другие формы крупномасштабного повторного использования кода все еще довольно редки.

Очевидно, что все это улучшается, но было бы неплохо, если бы мы все согласились, что это начало, а не конец =).

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

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

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

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

Я полностью согласен с этим, если это изменить переменную в объекте в вашем объекте, так что вы не получите такие вещи, как: a.b.c.d.e = что-то; но я бы лучше использовал: a.x = что-то; затем a.setX (что-то); Я думаю, что a.x = что-то; на самом деле и то, и другое легче читать, и красивее, чем установить / получить в одном и том же примере.

Я не вижу причины, сделав:

void setX (T x) {this-> x = x; }

T getX () {return x; }

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

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

Классы должны помещаться на экране.

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

Разбор кода и миниатюрные шрифты обманывают.

Разработчики все разные, и должны рассматриваться как таковые.

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

Держись подальше от Celko !!!!

http://www.dbdebunk.com/page/page/857309.htm

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

@ocdecio: Фабиан Паскаль дает (в главе 3 своей книги Практические вопросы управления базами данных , процитированные в пункте 3 на странице, на которую вы ссылаетесь) как единое целое) критериев выбора ключа стабильности (он всегда существует и не меняется). Если естественный ключ не обладает таким свойством, то следует использовать суррогатный ключ по очевидным причинам, на которые вы намекаете в комментариях.

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

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

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

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

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

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

На самом деле, для моего второго пункта:

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

Пишите абстракцию только в том случае, если она собирается сохранить в 3 раза больше времени.

Я вижу, как люди иногда пишут все эти сумасшедшие абстракции, и я думаю про себя: «Почему?»

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

Вот тот, который казался мне очевидным на протяжении многих лет, но для всех остальных это анафема: почти всегда ошибочно отключать утверждения C (или C ++) с помощью NDEBUG в сборках 'release'. (Исключение составляют случаи, когда штраф за время или пространство недопустим).

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

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

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

Новые веб-проекты должны рассмотреть возможность не использовать Java.

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

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

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

«Потому что мы наряд Microsoft / партнер / специалист» никогда не является действительным аргументом.

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

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

Это всего лишь краеугольный камень моей глубокой ненависти к политике в софтверном бизнесе.

MOSS (Microsoft Office Sharepoint Server) - кусок дерьма.

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

Тем не менее, время от времени, клиент обращается к нам и просит решение MOSS.

Разработчик никогда не должен тестировать свое собственное программное обеспечение

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

Слово «зло» - это злоупотребление и злоупотребление словом на Stackoverflow и симуляционных форумах.

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

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

Никого не волнует, проверяет ли ваш веб-сайт строгость XHTML, стандарты или соответствует значку W3C.

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

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

Позвольте мне установить этот замечательный фрагмент OSS, который я нашел. Похоже, он должен делать именно то, что я хочу! Ой, подождите, сначала я должен установить этот другой оконный менеджер. ХОРОШО. Затем мне нужно получить этот инструмент командной строки и добавить его в мой путь. Теперь мне нужны последние версии для X, Y и Z. Теперь мне нужно убедиться, что у меня запущены эти процессы. ок, отлично ... все настроено. Теперь позвольте мне изучить новый набор команд для его использования. О, круто, кто-то создал графический интерфейс для этого. Я думаю, мне не нужно изучать эти команды. Подождите, мне нужна эта библиотека, чтобы заставить работать графический интерфейс. Должен скачать это сейчас. хорошо, теперь это работает ... дерьмо, я не могу понять этот ужасный интерфейс.

звучит знакомо? OSS полон осложнений ради сложности, сложные установки, которые вам нужны, чтобы быть экспертом, и инструменты, которые большинство людей не знают, что делать в любом случае. Так много проектов отходит на второй план, другие настолько ниши, что их используют лишь немногие, а некоторые из приличных (FlowPlayer, OSCommerce и т. Д.) Имеют настолько нелепо чрезмерно сложный и раздутый исходный код, что он лишает возможности быть способным отредактируйте источник. Вы можете редактировать исходный код ... если вы можете выяснить, какой из 400 файлов содержит код, который необходимо изменить. Вы действительно попали в беду, когда узнаете, что их всего 400.

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

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

Существуют немного (очень немного) законное использование для goto (особенно в C как заместитель для обработки исключений).

Tcl/Tk является лучшей комбинацией языка/инструментария GUI когда-либо

, Это может испытать недостаток в определенных виджетах и быть менее красивым, чем новенькие, но ее модель изящна и так проста в использовании, что можно создать рабочие графический интерфейсы пользователя быстрее путем ввода команд в интерактивном режиме , чем при помощи визуального интерфейсного разработчика. Его выразительное питание непобедимо: другие решения (Gtk, Java.NET, MFC...) обычно требуют, чтобы десять - сто LOC получили тот же результат как острота Tcl/Tk. Все, даже не жертвуя удобочитаемостью или устойчивостью.

pack [label .l -text "Hello world!"] [button .b -text "Quit" -command exit]

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

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

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

решенная проблема, правильно?

Неправильно.

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

Мое непопулярное мнение - это:

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

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

необходимо ли смочь легко ответить на вопрос, "какие части моего приложения на самом деле зависят от библиотеки XYZ?"

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

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

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

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

2 отступа пространства.

Никакое обсуждение. Это просто должен быть тот путь ;-)

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

Женщины делают лучших программистов, чем мужчины.

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

Быть Хорошим Программистом действительно требует работы в нескольких аспектах поля: Разработка приложений, Системы (Ядро) работа, Дизайн Пользовательского интерфейса, База данных, и так далее. Существуют определенные подходы, характерные для всех и определенных подходов, которые характерны для одного аспекта задания. Необходимо изучить, как программировать Java как кодер Java, не как кодер C++ и наоборот. Дизайн Пользовательского интерфейса действительно труден, и использует другую часть Вашего мозга, чем кодирование, но реализация, что UI в коде является еще одним навыком также. Это не просто, что нет "одного" подхода к кодированию, но нет всего одного типа кодирования.

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

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

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

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

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

, Если Ваш отладчик может ступить через все различные используемые языки и показать Вам http транзакции, происходящие затем тем лучше.

Вы не можете разработать веб-приложения без Firebug

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

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

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

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

существуют времена и места, когда это полезно.

Код как Дизайн: Три Эссе Jack W. Reeves

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

Гарантируемый для увольнения Вас в значительной степени везде.

Генерация кода плоха

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

AutoProperties C# являются шагом в правильном направлении, но для хорошего DTOs с Полями, Свойствами и параметрами Конструктора Вам все еще нужно большое дублирование.