Долго сохраненный, неправильные [закрытые] предположения программирования

Этого 640 КБ должно хватить для всех (DOS). Многие люди в течение ряда лет в это верили.

Когда у меня впервые была система с 8 МБ ОЗУ, я подумал, что это намного больше, чем мне нужно. На нем работала ОС (Mac) и все приложения, которые я использовал (Word, Email, Firefox и т. Д.).

Что все, что я написал, потерпит неудачу в какой-то момент в обозримом будущем.

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

Это имеет значение во время выполнения. Часто имеет значение общее время решения.

С тех пор, как я изучил Python, я отучился от моей привязанности к статической типизации.

Я не знал, что что-то деленное на 0 в Javascript - это бесконечность (арифметика IEEE 754). Недавно усвоил это на собственном горьком опыте.

Выучить новый язык было бы очень сложно.

Эти потоки в Windows дешевы.

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

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

Профилирование и анализ производительности - одно и то же.

Затем я обнаружил, что профилировщики, хотя и лучше, чем ничего, содержат ошибочные предположения, такие как:

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

You can't diagnose 'intermittent errors' in production. Rebooting the server is the only way to fix it.

Maybe is was MORE true in my early days of ASP coding. But there are a lot of good profiling tools to find memory leaks and other weird issues. Perfmon also provides lots of good diagnostic data. Plus you should be coding diagnostic logging into your application.

Я думал, что написать достаточно хорошее программное обеспечение - простая задача

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

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

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

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

Эти люди действительно заботились об используемых технологиях (открытый / закрытый исходный код).

В начале восьмидесятых, когда я начал играть Работая с компьютерами (ZX81 с 1 КБ памяти), я тратил часы на набор машинного кода (байты, не читаемый человеком язык ассемблера) для игр из журналов, в основном используя инструкции BASIC Poke.

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

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

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

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

• Я думал, что буду кодить 8 часов подряд. На самом деле, я трачу 4 часа на программирование, 1 час на обед, 1 на перерывы на кофе и 2 на то, чтобы дурачиться / болтать болтать / складывать все подряд.

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

• Я думал, что кабинки - это плохо. Прямо сейчас я люблю их: D Я действительно переехал из двери - от офиса до кабинки. Мне нравится открытость.

• Все программисты не спортсмены. Я думал, что я единственный, кто ходит в спортзал. Там, где я работаю, по крайней мере 10 из нас ходят в спортзал каждый день в 5 утра.

• Я думала, что женщин-программистов не будет. Пара наших клиентов - дамы.

Эта Java передает копии объектов в функции, а не ссылки.

Другими словами, я думал, что если вы передадите объект в метод, а затем измените объект каким-то образом, он не изменяет объект в вызывающей области. Я всегда передавал объекты в методы, манипулировал ими, а затем возвращал их!

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

Что я мог бы убедить традиционных процедурных программистов почему ООП часто дает лучшее решение.

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

Аргументы обычно включали чушь об абстрактных классах, на что я ответил: «Не все ООП-программисты только что вышли из Uni и все еще помешаны на абстракциях».Или классический: «В ООП нет ничего такого, что я не смог бы сделать с помощью строго процедурного программирования», на что я обычно отвечал: «Дело не в том, что вы могли , а в том, можете ли вы было бы , если бы у вас был более обширный набор инструментов ".

Я научился просто соглашаться с тем, что они не смотрят на мир через ту же линзу, что и я.

That.... кому нужно тестирование JUnit, когда точки останова эффективны? (при тестировании приложений в режиме отладки). Позже я понял, почему....

Эта простота почти всегда превосходит сложность. KISS - Keep It Simple Глупые правила.

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

временные решения не являются постоянными
или другими словами: обходные пути не вечны :)).

That an identity column cannot contain duplicate values: identity column in Sql server

Конечно, вы можете посмотреть FindBugs и PMD , но это мои любимые ловушки и уловки (все на Java):

Поля не переопределены, они затенены.

Нет явного доступа super.super.

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

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

Классы «друзья сами по себе» "в терминах C ++ на частные методы и поля любого экземпляра этого класса можно ссылаться из любого метода того же класса, даже из статических методов. Это значительно упростило бы некоторые из моих ранних конструкторов clone () и копирования.

Защищенные методы и поля доступны в статическом контексте расширяемых классов, но только если этот класс находится в одном пакете. Я рад, что flex.messaging.io.amf не является запечатанным пакетом.

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

Чтобы продавцы реалистично управляли ожиданиями клиентов. (Обучены делать малообещающие и избыточные поставки)

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

That dimension n is an instance of dimension (n+1) when they're equivalent.