Давние, неверные предположения программирования

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

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

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

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

195 ответов

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

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

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

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

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

Изменить: я согласен с большинством комментариев. Это не технический ответ и, возможно, не тот, который искал спрашивающий. Это не относится только к программированию. Я уверен, что это не мое давнее предположение, но это была самая поразительная вещь, которую я узнал за 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)

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

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

Другие вопросы по тегам