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

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

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

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

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

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

Возможно защитить приложение.

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

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

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

BAD IDE делают язык программирования слабым

Хорошие IDE действительно облегчают работу с определенными языками и позволяют лучше ее контролировать. Я был немного испорчен своей профессиональной карьерой, в компаниях, в которых я работал, всегда была готова последняя версия Visual Studio.

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

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

Люди, переходящие на ИТ, которые просто не должны

Это копия / вставка из моего поста в блоге, сделанного в прошлом году.

---

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

Мы (поскольку я объединяю всех разработчиков программного обеспечения вместе) в настоящее время находимся на рынке, который может выглядеть очень хорошо для нас. Компании отчаянно пытаются найти инженеров-программистов (теперь SE), независимо от цены. Если вы смените работу сейчас, вы можете требовать практически все, что захотите. В Нидерландах сейчас наблюдается тенденция даже сдавать 2 арендованных автомобиля с работой, просто чтобы вы работали на них. Насколько это странно? Как я буду водить 2 машины одновременно?

Конечно, это звучит очень хорошо для нас, но это также создает очень нездоровую ситуацию.

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

1110] Страсть, да, я думаю, что это правильное слово. Если у вас есть страсть к своей работе, ваша работа не остановится в 17:00. Вы будете обновлять все свои RSS-каналы разработки всю ночь. Вы будете искать в Интернете новейшие технологии, которые могут быть интересны для использования на работе. И вы будете запускать около десятка новых «многообещающих» проектов в месяц, просто чтобы узнать, сможете ли вы освоить ту новейшую технологию, о которой вы только что прочитали пару недель назад (и найти полезный способ реального использования этой технологии).

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

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

Где те люди, которых я ищу !!

Я могу жить без замыканий.

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

Я верю в дзен Python

«Программисты рождаются, а не рождаются».

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

«Все должно быть сделано как можно проще, но не проще». - Эйнштейн.

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

Не комментируемый код - проклятие человечества.

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

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

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

Кроме того, ROR - это еще не все, чем занимается Blogsphere.

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

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

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

Иногда целесообразно проглотить исключение.

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

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

При создании модульных тестов для уровня доступа к данным данные должны извлекаться непосредственно из БД, а не из фиктивных объектов.

Примите во внимание следующее:

void IList<Customer> GetCustomers()
{
  List<Customer> res = new List<Customer>();

  DbCommand cmd = // initialize command
  IDataReader r = cmd.ExecuteQuery();

  while(r.read())
  {
     Customer c = ReadFiledsIntoCustomer(r);
     res.Add(c);
  }

  return res;
}

В модульном тесте для GetCustomers должен ли вызов cmd.ExecuteQuery () получить доступ к БД или его поведение должно быть имитировано?

Я считаю, что вы не должны издеваться над фактическим вызовом БД, если выполняется следующее:

1. Тестовый сервер и схема существуют.
2. Схема стабильна (имеется в виду, что вы не ожидаете существенных изменений в ней)
3. У DAL нет умной логики: запросы строятся тривиально (конфигурируемые / хранимые процессы), а логика десериализации проста.

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

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

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

System.Data.DataSet Rocks!

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

Аргументация: мы склоняемся назад, чтобы выяснить единицы работы над пользовательскими объектами, LINQ to SQL, Entity Framework и его сложность. Используйте хороший генератор кода откуда-то для генерации слоя данных, и единица работы располагается в коллекциях объектов (DataTable и DataSet) - не загадка.

Программисты должны избегать методов, скрывающих наследование любой ценой.

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

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

Такие языки, как C #, немного улучшили ситуацию, потребовав ключевое слово new для методов, которые скрывают метод базового класса - по крайней мере, помогая избежать принудительного использования скрытия методов. Но я нахожу, что многие люди все еще путают значение new со значением override - особенно потому, что в простых сценариях их поведение может выглядеть идентично. Было бы хорошо, если бы такие инструменты, как FxCop, действительно имели встроенные правила для выявления потенциально неправильного использования сокрытия методов.

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

Однажды я увидел следующее от коллеги:

equal = a.CompareTo (b) == 0;

Я заявил, что он не может предположить, что в общем случае, но он просто смеялся.

Рекомендации библиотеки классов по реализации IDisposable неверны.

Я не часто делюсь этим, но считаю, что руководство по реализации по умолчанию для IDisposable совершенно неверно.

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

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

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

Редактировать: я написал сообщение в блоге на эту тему, если кому-то интересно:

http://www.caspershouse.com/post/A-Better-Implementation-Pattern-for -IDisposable.aspx

Простота против оптимальности

Я считаю, что очень сложно написать простой и оптимальный код.

Я думаю, что мы должны отойти от «С». Это слишком старое! Но старая собака все еще лает громче!

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

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

Но я придерживаюсь мнения, что я не должен скомпилируйте миллионы строк кода только для того, чтобы понять, что Windows пытается заблокировать файл, который я пытаюсь создать, потому что у другого программиста есть странная проблема с многопоточностью, которая требует от него отложить выгрузку DLL на 3 минуты после того, как они не должны использоваться ,

Вам нужно всего лишь от 3 до 5 языков, чтобы сделать все. С является определенным. Может быть, сборка, но вы должны это знать и уметь ее использовать. Может быть, JavaScript и / или Java, если вы пишете код для Интернета. Язык оболочки, такой как bash, и один HLL, такой как Lisp, который может быть полезен. Все остальное отвлекает.

Мы разработчики программного обеспечения, а не разработчики C / C # / C ++ / PHP / Perl / Python / Java / ....

После того, как вы познакомились с несколькими языками, подобрать новый и продуктивно работать с ним - небольшая задача. То есть вы не должны бояться новых языков. Конечно, существует большая разница между продуктивностью и владением языком. Но это не повод уклоняться от языка, который вы никогда не видели. Меня беспокоит, когда люди говорят: «Я разработчик PHP». или когда в предложении о работе говорится «Java-разработчик». После нескольких лет опыта работы в качестве разработчика новые языки и API действительно не должны пугать, и переход от того, чтобы никогда не видеть язык к продуктивности с ним, не займет совсем много времени. Я знаю, что это противоречиво, но это мое мнение.

• Вскоре мы собираемся запрограммировать в мир без баз данных .

• АОП и внедрение зависимостей являются GOTO 21-го века .

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

• У Джоэла есть блог.

Ни Visual Basic, ни C # не превосходят других. Они практически одинаковы, за исключением некоторого синтаксиса и форматирования.

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

Многие места, кажется, имеют «подход», как «мы делаем это». Это, похоже, неявно исключает другие подходы.

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

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

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

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

Вот гипотетический разговор, который суммирует его:

Я: Вы тестировали этот скрипт запуска в течение 10 лет, и вам НИЧЕГО не удалось узнать о скриптах оболочки и о том, как они работают?!

Тестер: Да.

Me: Permissions?

Tester: Инсталлятор делает это

Me: Платформа, зависимости от выпуска?

Tester: Мы регистрируем ошибки для этого

Я: Обработка ошибок?

Тестер: когда происходят ошибки, служба поддержки отправляет нам некоторую информацию.

Я: Хорошо ... (начинает думать о написании поста в stackoverflow ...)

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

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

Спустя миллион лет SWT пришел и решил основную проблему написания переносимого пользовательского интерфейса с нативными виджетами, но к тому времени Microsoft была вынуждена разложить Java на C #, и было написано много C ++, что в противном случае могло бы быть сделано в цивилизованная ява. Теперь мир работает на смеси C #, VB, Java, C ++, Ruby, Python и Perl. Все Java-программы по-прежнему выглядят и ведут себя странно, кроме SWT.

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

Я полагаю, что Sun думала, что независимые разработчики ПО пострадают от ограничений Java, и тогда все новые приложения для ПК будут волшебным образом работать на Suns. Хорошая попытка. В итоге они не получили приложения и не взяли язык, пока мы не сможем использовать его для серверного кода только для логики.

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