Давние, неверные предположения программирования
Я провожу некоторые исследования распространенных ошибок и ошибочных предположений, сделанных младшими (и, возможно, старшими) разработчиками программного обеспечения.
Каково было ваше предположение, которое в конечном итоге было исправлено?
Например, я неправильно понял, что размер целого числа не является стандартом и вместо этого зависит от языка и цели. Немного стыдно заявить, но это так.
Будь откровенен; какое твёрдое убеждение у тебя было, и сколько примерно ты придерживался этого предположения? Это может быть алгоритм, язык, концепция программирования, тестирование или что-то еще о программировании, языках программирования или информатике.
195 ответов
В течение долгого времени я предполагал, что у всех остальных есть это супер-мастерство всех концепций программирования (шаблоны проектирования, новейший новый язык, сложность вычислений, лямбда-выражения, вы называете это).
Чтение блогов, переполнение стека и книги по программированию всегда, казалось, заставляли меня чувствовать, что я не в курсе того, что все программисты должны знать интуитивно.
Со временем я осознал, что эффективно сравниваю свои знания с общими знаниями многих людей, а не одного человека, и это довольно высокая планка для всех. Большинство программистов в реальном мире имеют тайник знаний, необходимый для выполнения своей работы, и имеют более чем несколько областей, в которых они либо слабы, либо совершенно неосведомлены.
Чтобы люди знали, чего они хотят.
Долгое время я думал, что буду разговаривать с людьми, они будут описывать проблему или рабочий процесс, а я буду вставлять их в код и автоматизировать. Оказывается, каждый раз, когда это происходит, то, что они думали, что они хотели, на самом деле не то, что они хотели.
Изменить: я согласен с большинством комментариев. Это не технический ответ и, возможно, не тот, который искал спрашивающий. Это не относится только к программированию. Я уверен, что это не мое давнее предположение, но это была самая поразительная вещь, которую я узнал за 10 коротких лет, которые я делал. Я уверен, что это была чистая наивность с моей стороны, но то, как мой мозг был подключен, и учение и опыт, которые я получил до прихода в деловой мир, заставили меня поверить, что я буду делать то, что отвечал; что я смогу использовать код и компьютеры для решения проблем людей.
Я предполагаю, что этот ответ похож на ответ Робина о непрограммистах, понимающих / заботящихся о том, о чем я говорю. Речь идет об изучении бизнеса как гибкого, итеративного, интерактивного процесса. Речь идет об изучении разницы между тем, чтобы быть обезьяной кода программирования и разработчиком программного обеспечения. Речь идет о том, чтобы понять, что между этими двумя понятиями есть различие, и чтобы быть действительно хорошим в этой области, дело не только в синтаксисе и скорости печати.
Изменить: Этот ответ теперь вики-сообщества, чтобы успокоить людей, расстроенных этим ответом, давая мне репутацию.
Что я знаю, где проблема производительности без профилирования
Что у меня должна быть только одна точка выхода из функции / метода.
Эти закрытые переменные-члены были частными для экземпляра, а не класса.
Я думал, что статическая типизация очень тихо сидит на клавиатуре.
Что вы можете полностью понять проблему, прежде чем начать разработку.
Умные люди всегда умнее меня.
Я действительно могу измотать себя, когда совершаю ошибки, и меня часто отчитывают за самоуничижение. Раньше я с благоговением смотрел на многих разработчиков и часто полагал, что, поскольку они знали о X больше, чем я, они знали больше, чем я.
Поскольку я продолжал набираться опыта и знакомиться с большим количеством людей, я начал понимать, что часто, хотя они знают больше, чем я, в определенной теме, они не обязательно умнее меня / вас.
Мораль истории: никогда не стоит недооценивать то, что вы можете принести на стол.
Долгое время я думал, что плохое программирование было чем-то, что происходило на опушке... что правильное поступление было нормой. Я не такой наивный в эти дни.
Я думал, что должен двигаться в направлении абстрагирования как можно больше. Я получил удар по главному из-за этого, потому что слишком много переплелось маленьких кусочков функциональности.
Теперь я стараюсь держать вещи как можно более простыми и отделенными. Рефакторинг для создания чего-то абстрактного гораздо проще, чем предсказывать, как мне нужно абстрагировать что-то.
Таким образом, я перешел от разработки инфраструктуры, которая управляет ими всеми, к фрагментам функциональности, которые выполняют свою работу. Никогда не оглядывался назад, кроме случаев, когда я думал о времени, когда я наивно думал, что я буду тем, кто разрабатывает следующую большую вещь.
Что качество программного обеспечения приведет к увеличению продаж. Иногда это происходит, но не всегда.
Что все языки (в основном) созданы равными.
В течение долгого времени я полагал, что выбранный язык на самом деле не имеет большого значения для сложности процесса разработки и потенциала для успеха проекта. Это определенно не правда.
Выбор правильного языка для работы так же важен / критичен, как и любое другое решение, которое принимается в проекте.
То, что большое соотношение комментарий / код - это хорошо.
Мне потребовалось некоторое время, чтобы понять, что код должен самодокументироваться. Конечно, комментарии здесь и там полезны, если код не может быть прояснен, или если есть важная причина, почему что-то делается. Но, в общем, лучше потратить время на комментарии, переименовывая переменные. Это чище, яснее, и комментарии не синхронизируются с кодом.
Это программирование невозможно.
Не шучу, я всегда думал, что программирование было чем-то невозможным, и я всегда держался в стороне от этого. И когда я приблизился к коду, я никогда не мог его понять.
Затем однажды я просто сел и прочитал некоторые базовые учебные пособия для начинающих, и прошел путь оттуда. И сегодня я работаю программистом и люблю каждую минуту этого.
Кроме того, я не думаю, что программирование - это легко, это задача, и я люблю больше учиться, и нет ничего более увлекательного, чем решить какую-то проблему программирования.
Это программное обеспечение для программирования требует прочной основы в высшей математике.
За годы до того, как я начал программировать, мне всегда говорили, что, чтобы быть хорошим программистом, вы должны хорошо разбираться в продвинутой алгебре, геометрии, исчислении, триге и т. Д.
Десять лет спустя, и я только однажды должен был сделать что-то, что не мог сделать восьмиклассник.
Это оптимизация == переписывание на ассемблере.
Когда я впервые действительно понял ассемблер (исходящий из BASIC), казалось, что единственный способ ускорить выполнение кода - это переписать его в ассемблере. Потребовалось несколько лет, чтобы понять, что компиляторы могут быть очень хороши в оптимизации, особенно с процессорами с прогнозированием ветвлений и т. Д., Они, вероятно, могут выполнять свою работу лучше, чем человек за разумное время. Кроме того, тратить время на оптимизацию алгоритма, скорее всего, лучше, чем тратить время на перевод с языка высокого уровня на низкий. Также эта преждевременная оптимизация является корнем всего зла...
- Именно руководители компании заботятся о качестве кода.
- Чем меньше строк, тем лучше.
Я бы сказал, что сохранение элемента года в виде двух цифр было предположением, которое затронуло целое поколение разработчиков. Деньги, которые были потрачены на Y2K, были довольно ужасными.
Что-нибудь кроме вставки / пузырчатой сортировки было просто темной магией.
Этот XML будет действительно совместимым и удобочитаемым форматом данных.
Этот C++ был как-то лучше, чем все остальные языки.
Это я получил от друга на пару лет впереди меня в колледже. Я держал его в покое смущающе долго (я сейчас краснею). Это было только после работы с ним в течение 2 лет или около того, прежде чем я смог увидеть трещины, какие они были.
Никто - и ничто - не является идеальным, всегда есть возможности для улучшения.
Я верил, что создание программ будет точно таким же, как то, чему учили в классе... вы сидите с группой людей, обсуждаете проблему, находите решение и т. Д. И т. Д. Вместо этого реальный мир - это "Вот моя проблема, мне нужно ее решить, иди ", и через десять минут ты получишь другую, и у тебя не останется реального времени, чтобы эффективно спланировать свое решение.
Я думал, что основные шаблоны проектирования были великолепны, когда они были представлены в классе CS. До этого я программировал около 8 лет как хобби, и у меня действительно не было четкого понимания того, как создавать хорошие абстракции.
Дизайнерские узоры напоминали магию Вы могли бы сделать действительно аккуратные вещи. Позже я обнаружил функциональное программирование (через Mozart/Oz, OCaml, позже Scala, Haskell и Clojure), и затем я понял, что многие шаблоны были просто шаблонными или дополнительной сложностью, потому что язык не был достаточно выразительным.
Конечно, есть почти всегда какие-то шаблоны, но они находятся на более высоком уровне в выразительных языках. Сейчас я занимаюсь профессиональным программированием на Java и действительно чувствую боль, когда мне приходится использовать соглашение, такое как шаблон посетителя или команды, вместо сопоставления с образцом и функций более высокого порядка.
Первые несколько лет, когда я программировал, я не уловил, что 1 Кбайт - это технически 1024 байта, а не 1000. Я всегда был немного озадачен тем фактом, что размеры моих файлов данных казались немного не такими, как я ожидал. быть.
Это условие проверяет как:
if (condition1 && condition2 && condition3)
выполняются в неуказанном порядке...
Что мое программирование было бы быстрее и лучше, если бы я выполнял его один.