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

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

я ненавидел VB сильно в прошлом и все еще ложный VB.NET (вероятно, в шутку) как язык Fisher Price из-за моей неприязни к классическому VB, но в его день, ничто не могло разбить его для получения сделанного задания.

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

Простой и простой :-)

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

Сорящий код с блоками попытки/выгоды не является решением.

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

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

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

-

Мое заключительное возражение является использованием собравших "мусор" языков. Не понимайте меня превратно.. Я люблю их при некоторых обстоятельствах, но в целом для систем сервера/MC у них нет места, по моему мнению.

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

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

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

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

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

Производительность превосходит стандарты разработки, это - мое спорное представление.

Код дизайн

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

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

Блок является лучшим первым языком программирования.

А хороший разработчик должен знать больше, чем, как кодировать

Реляционные базы данных ужасны для веб-приложений.

, Например:

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

Для хорошего языка программиста не проблема.

Это может быть не очень controvertial, но я слышу, что много o жалуется от других программистов как, "почему они все не используют Дельфи?", "C# сосет", "я изменил бы компанию, если бы они вынудили меня использовать Java" и так далее.
то, Что я думаю, - то, что хороший программист гибок и может записать хорошие программы в любом языке программирования, который ему, возможно, придется выучить в его жизни

Лучшие программисты прослеживают весь свой код в отладчике и тестируют все пути.

Хорошо... OP, сказанный спорный!

Иногда примыкание к победившей стороне в порядке

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

Иногда вещи, которые популярны, популярны по причине.

Исправьте каждый дефект, когда он будет обнаружен. Не только "серьезность 1" дефект; весь дефекты.

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

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

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

Тест Постоянно

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

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

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

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

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

Социальные навыки имеют значение больше, чем технические навыки

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

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

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

анализ Требований, спецификация, дизайн и документация почти никогда не будут вписываться в "шаблон". Вы - 100% времени, более обеспеченного путем запуска с пустого документа, и начиная вводить в целях "Я объясню это таким способом, которым, если бы я был мертв и кто-то еще прочитал этот документ, они знали бы все, что я знаю и вижу и понимаю теперь" и затем организующий оттуда, позволяя заголовкам раздела и такому разрабатывать естественно и соответствую задаче, которую Вы указываете, вместо того, чтобы быть ограниченными к некоторому бизнесу или идее школы того, на что должен быть похожим Ваш документ. Если необходимо сделать схему, вместо того, чтобы использовать чью-то формальную и непостижимую систему, Вы часто более обеспечены просто рисунок схема, которая имеет смысл с ясной легендой, которая на самом деле указывает систему, которую Вы пытаетесь указать, и передает информацию, которую должен получить разработчик на другом конце (часто Вы, после нескольких лет).

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

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

нет такой вещи как Объектно-ориентированное программирование.

веб-приложения сосут

, Мое Интернет-соединение является медленным veeery. Мой опыт почти с каждым веб-сайтом, который не является Google, по крайней мере, печален. Почему кто-либо больше не пишет настольные приложения? О, я вижу. Никто не хочет быть побеспокоенным изучением, как работают операционные системы. По крайней мере, не Windows. В прошлый раз необходимо было обработать WM_PAINT, взорванная голова. Создание рабочего потока для выполнения долгой задачи (я имею в виду, делая его Windows путь) было полностью вне Вас. Что, черт возьми, было обратным вызовом?Боже мой!

Сборка "мусора" сосет

нет, она на самом деле не делает. Но это заставляет программистов не высосать как ничто иное. В колледже первый язык они учили нас, был Visual Basic (исходный). После этого был другой курс, где учителя притворились , они преподавали нам C++. Но ущерб был нанесен. Никто на самом деле не знал, как использовать это тайное ключевое слово delete, сделал. После тестирования наших программ мы или получили недопустимые исключения адреса или утечки памяти. Иногда, мы получили обоих. Среди 1% моей способности, которая может на самом деле программировать, только один, кто может управлять его памятью один (по крайней мере, он притворяется) и он пишет эту напыщенную речь. Остальные пишут их программы в VB.NET, который, по определению, является сквернословием.

Динамический контроль типов сосет

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

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

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

один пример:

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

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

Никогда реализация что-либо как одиночный элемент.

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

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

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

Преждевременная оптимизация НЕ корень всего зла! Отсутствие надлежащего планирования является корнем всего зла.

Помнят, что старое военно-морское видело

, Надлежащее Планирование Предотвращает Низкую производительность P*ss!

Вывод Автоматических обновлений к Poorer Quality Software, которая является Менее безопасна

Идея

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

Действительность

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

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

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

Skizz

Доступ мс* является Реальным Средством разработки, и он может использоваться без позора профессиональными программистами

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

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

* Вставляют примерно любой порочивший инструмент (VB, PHP, и т.д.) здесь.

Худшей вещью о рекурсии является рекурсия.

Этот - главным образом связанная сеть, но...

Используйте Таблицы для своих разметок веб-страницы

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

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

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

90 процентов программистов являются довольно чертовски плохими программистами, и фактически у всех нас нет абсолютно никаких инструментов для оценки нашего текущего уровня способности (хотя мы можем обычно оглядываться назад и понимать, как плохо мы РАНЬШЕ сосали),

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

A) не то, что точка вопроса, и

B) Большинство "Ответов" в этом потоке подтверждает эту точку зрения

Я слышал большую аналогию на днях: способности к Программированию варьируются, ПО КРАЙНЕЙ МЕРЕ, так же как спортивные способности. Сколько из нас могло вскочить в профессиональную команду и на самом деле улучшить их возможности?