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

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

Каково было ваше предположение, которое в конечном итоге было исправлено?

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

Будь откровенен; какое твёрдое убеждение у тебя было, и сколько примерно ты придерживался этого предположения? Это может быть алгоритм, язык, концепция программирования, тестирование или что-то еще о программировании, языках программирования или информатике.

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

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

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

Чтобы люди знали, чего они хотят.

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

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

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

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

Что я знаю, где проблема производительности без профилирования

Что у меня должна быть только одна точка выхода из функции / метода.

Это непрограммисты понимают, о чем я говорю.

Это безошибочное программное обеспечение было возможно.

Частные переменные-члены были частными для экземпляра, а не для класса.

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

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

Умные люди всегда умнее меня.

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

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

Мораль истории: никогда не стоит недооценивать то, что вы можете принести на стол.

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

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

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

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

Это женщины считают программистов сексуальными ...

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

Что все языки (в основном) созданы равными.

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

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

То, что большое соотношение комментарий / код - это хорошо.

Мне потребовалось некоторое время, чтобы понять, что код должен самодокументироваться. Конечно, комментарии здесь и там полезны, если код не может быть прояснен или если есть важная причина, почему что-то делается. Но, в общем, лучше потратить время на комментарии, переименовывая переменные. Это чище, яснее, и комментарии не «не синхронизированы» с кодом.

Это программирование невозможно.

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

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

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

«On Error Resume Next» была какая-то обработка ошибок

Это программное обеспечение программирования требует прочной основы в высшей математике.

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

Десять лет спустя, и я только однажды должен был сделать то, что не мог восьмиклассник

Это оптимизация == переписывание на ассемблере.

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

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

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

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

Этот XML будет действительно совместимым и удобочитаемым форматом данных.

Этот C ++ был как-то лучше, чем все остальные языки.

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

Никто - и ничто - не является идеальным, всегда есть возможности для улучшения.

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

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

Дизайнерские узоры ощущались как волшебство; Вы могли бы сделать действительно аккуратные вещи. Позже я обнаружил функциональное программирование (через Mozart / Oz, OCaml, позже Scala, Haskell и Clojure), и затем я понял, что многие шаблоны были просто шаблонными или дополнительной сложностью, потому что язык не был достаточно выразительным.

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

Первые несколько лет, когда я программировал, я не уловил, что 1 Кбайт - это технически 1024 байта, а не 1000. Я всегда был немного озадачен тем фактом, что размеры моих файлов данных казались немного не такими, как я ожидал. быть.

Это условие проверяет как:

if (condition1 && condition2 && condition3)

выполняются в неуказанном порядке ...

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