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

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

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

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

Хорошая производительность против элегантного дизайна

Они не являются взаимоисключающими, но я не выношу чрезмерно разработанных структур / структур классов, которые совершенно не имеют представления о производительности. Мне не нужно иметь строку нового This (new That (new Whither ())); создать объект, который скажет мне, что сейчас 5 утра, о, кстати, до дня рождения Обамы 217 дней, а до выходных 2 дня. Я только хотел знать, открыт ли тренажерный зал.

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

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

Переменные-члены никогда не должны объявляться закрытыми (в java)

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

Классы никогда не должны объявляться как финальные (в java)

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

Java Beans - ужасная идея.

Соглашение о bean-компоненте java - объявляя все члены частными, а затем записывая методы get () и set () для каждого члена - заставляет программистов писать шаблонный, подверженный ошибкам, утомительный и длинный код, где нет кода необходимо. Просто сделайте публичные переменные-члены публичными! Доверьтесь своей способности изменить его позже, если вам нужно изменить реализацию (подсказка: 99% времени вы никогда не будете).

Программисты воспринимают свой (собственный немного ограниченный глупый) язык программирования как священную религию.

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

Также забавно и еще одно подтверждение: по определению вопроса «дайте мне противоречивое мнение», любое противоречивое мнение НЕ МОЖЕТ претендовать на отрицательное голосование - фактически наоборот: чем больше противоречий, тем лучше. Но как наши программисты реагируют: как собаки Павлова, голосуя за неприязненные мнения, отрицательно.

PS: я проголосовал за некоторых других за справедливость.

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

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

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

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

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

Первоначальный дизайн - не просто начните писать код, потому что вы взволнованы, чтобы писать код

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

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

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

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

Этот не совсем касается программирования, потому что html / css не являются языками программирования.

Таблицы пригодны для разметки

css и div не могут делать все, избавьте себя от хлопот и используйте простую таблицу, а затем используйте css поверх нее.

Используйте вывод типов везде и всюду, где это возможно.

Редактировать:

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

http://blogs.msdn.com/jaredpar/archive/2008/09/09/when-to-use-type-inference.aspx

MVC для Интернета должен быть намного проще, чем традиционный MVC.

Традиционный MVC включает в себя код, который «прослушивает» «события», так что представление может постоянно обновляться, чтобы отражать текущее состояние модели. Однако в веб-парадигме веб-сервер уже выполняет прослушивание, и запрос является событием. Поэтому MVC для сети должен быть только конкретным экземпляром шаблона-посредника: контроллеры, обеспечивающие связь между представлениями и моделью. Если веб-фреймворк создан правильно, ядро ​​многократного использования, вероятно, не должно превышать 100 строк. В этом ядре должна быть реализована только парадигма «контроллера страницы», но она должна быть расширяемой, чтобы поддерживать парадигму «фронт-контроллера».

Ниже приведен метод, который является сутью моей собственной инфраструктуры, успешно используемой во встроенном потребительском устройстве, производимом производителем сетевого оборудования Fortune 100, для медиа-компании Fortune 50. Мой подход был уподоблен Smalltalk бывшим программистом Smalltalk и автором книги Орейли о самой выдающейся веб-инфраструктуре на Java; Более того, я перенес ту же платформу в mod_python / psp.

static function sendResponse(IBareBonesController $controller) {
  $controller->setMto($controller->applyInputToModel());
  $controller->mto->applyModelToView();
}

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

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

И угадайте что? У каждого есть свой собственный способ делать вещи ! Каждый изо всех сил изучает ASP.NET AJAX и Telerik или комплекты Infragistic, Enterprise Library или другие платформы для повышения производительности и уровня данных и персистентности, Aspect-ориентированные среды, блоки приложений для ведения журналов и кэширования, возможности DB2 или Oracle. И угадай что? Каждый берет чертовски много времени , чтобы научиться делать все правильно! Это значит, много ошибок в то же время и множество возникающих дефектов и узких мест в производительности! И, черт возьми, больше времени, чтобы исправить их! Через каждый слой! Каждый принимает участие в каждом проекте Visual Studio. Никто не специализируется для решения и решения одной проблемной / технологической области. Слишком много поваров портят суп. Все повара в результате чего-то радиоактивного липучки.

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

Методы расширения - это работа дьявола.

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

Основными причинами их совершенства являются увеличенная читаемость, улучшенная OO-сущность и способность лучше связывать вызовы методов.

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

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

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

Разработка программного обеспечения - ОЧЕНЬ небольшое подмножество компьютерных наук.

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

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

Что, эм, люди должны комментировать свой код ? Это кажется довольно спорным здесь ...

Код только говорит мне , что на самом деле он делает ; не то, что предполагалось сделать

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

XHTML - это зло. Пишите HTML

Вам все равно придется установить тип MIME на text / html, так зачем же обманывать себя, полагая, что вы действительно пишете XML? Кто бы ни скачивал вашу страницу, он поверит, что это HTML, поэтому сделайте это HTML.

И с этим, не стесняйтесь и рады, что не закрываете свою < li>, в этом нет необходимости. Не закрывайте HTML-тег, файл все равно закончился. Это действительный HTML, и он может быть проанализирован отлично.

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

И когда вы закончите, перейдите к HTML5. Это лучше.

Hibernate бесполезен и наносит урон разработчикам.

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

Школьные руины творчества *

* «Руины» означает «потенциально руины»

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

По мере того, как вы изучаете новые вещи и приобретаете новые навыки, вы также формируете свое мышление в отношении этих новых вещей и навыков, поскольку они, очевидно, являются «способом сделать это». Будучи людьми, мы склонны прислушиваться к авторитетам - будь то учитель, консультант, сотрудник или даже сайт / форум, который вам нравится. Мы должны ВСЕГДА знать об этом "недостатке" в том, как работает наш разум. Слушайте, что говорят другие люди, но не принимайте то, что они говорят как должное. Всегда придерживайтесь критической точки зрения в отношении каждой новой информации, которую вы получаете.

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

Проблемы с юзабилити никогда не являются ошибкой пользователя.

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

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

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

Я всегда прав.

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

Конечно, это работает, только если я разумный. К счастью для вас, я. :)

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

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

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

Избыточный HTML в файлах PHP: иногда необходимо

Избыточный Javascript в файлах PHP: вызвать атаку раптора

Пока у меня время выяснения всего вашего переключения между echo ing и?> < ? php 'html (в конце концов, php - это просто процессор для html), строки и строки javascript, добавленные в него, превращают его в совершенно не поддерживаемый беспорядок.

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

Причина, по которой вы все время переходите между PHP, Javascript и HTML, заключается в том, что вы плохие во всех трех из них.

Хорошо, может быть, его не совсем спорный. У меня сложилось впечатление, что это была общая тема разочарования:)

Очистка и рефакторинг очень важны для развития (команды)

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

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

Иногда можно использовать регулярные выражения для извлечения чего-либо из HTML. Серьезно, поссориться с тупым парсером или использовать быстрое регулярное выражение, например /<a href="([^"]+)">/? Это не идеально, но ваше программное обеспечение будет работать намного быстрее, и вы, вероятно, сможете использовать еще одно регулярное выражение, чтобы убедиться, что найденное совпадение действительно похоже на URL. Конечно, он взломан и, возможно, не работает в нескольких крайних случаях, но этого достаточно для большинства случаев использования.

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

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

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

1. Хорошая архитектура выращена, а не разработана.

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

маленький код всегда лучше, но потом сложнее?: Вместо if-else я понял, что когда-то большой код более читабелен.