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

«Проект будет выполнен в течение 2 недель»

и

«Это займет 2 часа на реализацию»

Я думал, мне это понадобится.

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

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

Это одна из самых фундаментальных концепций C #, которую я должен был знать.

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

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

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

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

Это работа с 9 до 5

Программировать легко.

Невозможно иметь Отсутствие дефектов до запуска.

Это определенно неправда, даже дефекты P2 иногда остаются открытыми.

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

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

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

• Я полагал, что освобождение чего-либо вернет память обратно в ОС.

• Я полагал, что вызовы malloc сводятся к проверке, достаточно ли свободного места в ОС, поэтому malloc будет недорогим.

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

• I сильно переоценил количество случаев, когда LinkedLists превосходит ArrayLists.

• Я думал, что NP-жесткость была доказательством того, что никакой INSTANCE не может быть решен эффективно, что на какое-то время было тривиальной ошибкой.

• Я думал, что поиск лучшего варианта -планирование веб-сайтов туристических агентств заняло бы так много времени из-за «проблемы коммивояжера», поскольку я гордо посмеивался перед своими родственниками (когда я был маленьким, хорошо?!)

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

PS:
это возьмет лучшие свойства других языков и отвергнет ошибки.

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

PS:
это возьмет лучшие свойства других языков и отвергнет ошибки.

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

PS:
что на какое-то время является банально ложным.

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

PS:
что на какое-то время является банально ложным.

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

PS:
Ах, хорошо, этот проясняется не так медленно, но я вижу, что новички делают это время от времени, поэтому я подумал, что вам может быть интересно: я также подумал, что для хранения неопределенного количества вещей вам нужно объявить новая переменная для каждого. Поэтому я бы создал переменные a1, a2, a3, ... вместо использования одной переменной a, которую я бы объявил вектором.

Проверка кода - пустая трата времени.

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

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

B ) могут научить вас вещам, о которых вы изначально не знали (я '

Что, если бы условия оценивались в каждой строке и если бы вы написали такой код:

Dim a as Boolean = True
If a Then
    Console.WriteLine("1")
    a = False
    Console.WriteLine("2")
Else
    Console.WriteLine("3")
End If

, то результат был бы:

1
3

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

That .NET структуры (C # и VB.NET) были ссылочными типами, как и классы.

Я «получил» эту мудрость в какой-то момент незадолго до или после появления .NET 1.0 (понятия не имею, откуда, возможно, он возник в моей голове, как Афина из чела Зевса), и хранил его до тех пор, пока Джон Скит не избавился от этой идеи около 4 месяцев назад.

Спасибо, Джон.

PS Не связано с программированием, но я также считал (примерно 5 минут назад), что «Аполлон целиком возник из чела Зевса».

Эти байты и символы были практически одним и тем же - «ASCII» был просто способом сопоставить байтовое значение с глифом на экране.

Чтение о Unicode ] действительно открыл мне глаза (хотя до сих пор не совсем понимаю)

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

Раньше я предполагал, что этого достаточно для программирования приложений Win32.

Кроме того, каждая программа должна иметь графический интерфейс, поскольку командная строка "устарела".

Когда я программировал на TI-83, я думал, что нельзя присвоить себе переменную. Поэтому (игнорируя, что это код C, а не TI-BASIC), вместо того, чтобы писать

c = c + 1;

, я бы написал

d = c + 1;
c = d;

Когда я узнал о + = и ++ , это взорвало меня разум.

, что this:

SomeClass object(initialValue);

и this:

SomeClass object = initialValue;

гарантированно эквивалентны в C ++. Я думал, что вторая форма гарантированно будет интерпретирована так, как если бы она была написана как первая форма. Не так: см. Синтаксис инициализации C ++ .

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

• Все заинтересованные стороны будут принимать решения о разработке программного обеспечения объективно . Те, кто не участвует в написании кода, принимают всевозможные решения, полностью основанные на эмоциях, которые не всегда имеют смысл для нас, разработчиков.
• Бюджеты проектов всегда имеют смысл - Я видел компании, которые вполне счастливы бросать [просто например] 50 000 долларов в месяц в течение многих лет, вместо того, чтобы платить 250 000 долларов за завершение проекта за 6 месяцев. Правительство, например, теряет свой годовой бюджет, если они его не тратят - так что потратят они его, будь то ад или паводок. Меня поражает, сколько проектных долларов тратится на подобные вещи.
• Вы всегда должны использовать правильные инструменты для правильной работы - иногда это решение не в ваших руках. Иногда с высоты доносится, что «ты должен использовать технологию X » для этого проекта, заставляя вас думать: «Черт возьми! Кто придумал эту нелепую идею?» ... парень платит вам зарплату, вот кто, теперь сделайте это.
• Идеология программирования превыше всего, все остальное вторично. На самом деле, чтобы получить свою зарплату, необходимо соблюдать сроки и бизнес-цели. Иногда вы принимаете худшие решения, потому что у вас просто нет времени , чтобы сделать это правильно ... так же, как иногда это слово вертится у вас на языке, но минута, которая требуется, чтобы вспомнить, заставляет вы выбираете другое, менее идеальное слово. Нет У всегда есть время сделать это правильно, иногда есть только время, чтобы сделать это - как бы то ни было. Следовательно, часто встречаются антипаттерны, используемые так называемыми опытными разработчиками, которые должны найти решение проблемы за 10 минут до крайнего срока презентации программного обеспечения, которое завтра будет доставлено вашему лучшему клиенту.

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

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

Что я был хорошим программистом!

This is really embarrassing but when I was starting to learn how to program nothing could satisfy me. I wanted to write video games. Not the trivial little programs all these books wanted me to write. So I decided I could easily skip 10 chapters and ignore the basics.

So I basically ignored variables!

The problem was that I did not recognize keywords from conventions:

Car car = new Car(); //good
Car test = new Car(); //wrong must be lowercase car!

for (int i = 0; i < 10; i++) //good
for (int test = 0; test < 10; test++)//wrong must be i

I did this for over a year and even made a tic-tac-to game in 3000 lines! I was thrilled by my awesomeness at that point, until I found a tic-tac-to in 150 lines on the Internet. Then realized I was an idiot and started over again.

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

Чтобы IDE стали быстрее.

Что ОС Unix и Linux хорошо спроектированы ... Я, вероятно, должен квалифицировать это (!)

Во-первых, эта точка зрения подкрепляется такими антитрюизмами, как:

• каждый последующий Разработанная ОС в конечном итоге плохо переделывает Unix (это сказано и о Lisp, где это более верно).
• список правил, составляющих «философию Unix». Дело не в том, что они ошибаются, это подразумевает, что сама Unix следует за ними внимательно.

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

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

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

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

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

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

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

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

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

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

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

Что я могу понять свой собственный код без комментариев !!!

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

Я могу читать ТАК и делать любую работу.