Что должен знать каждый программист о программировании?

52

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

experience  self-improvement  programming-practices 
— bigown
источник
7
— pramodc84
Этот вопрос действительно раздражает меня. Это может исходить только из сознания того, кто видит мир с точки зрения черного и белого. Не у каждого программиста одинаковая работа, и если это наименьший общий знаменатель, который вы ищете, приведенные ниже ответы показывают, что вы просто получите список любимых мозолей.
— Капитан Разумный

Ответы:

92

  1. Ошибка в вашем коде, а не в компиляторе или библиотеках времени выполнения.

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

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

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

РЕДАКТИРОВАТЬ

Да, моя точка № 1 завышена. Даже у самых лучших программных платформ есть свои ошибки, а некоторые из менее хорошо спроектированных изобилуют ими. Но даже в этом случае вы всегда должны сначала подозревать свой код и начинать обвинять в ошибках компилятора / библиотеки только тогда, когда у вас есть четкие доказательства того, что ваш код не виноват.

В те времена, когда я занимался разработкой на C / C ++, я помню случаи, когда предполагаемые «ошибки» оптимизатора оказывались следствием того, что я / какой-то другой программист сделал то, что, как говорит языковая спецификация, дало неопределенные результаты. Это относится даже к предположительно безопасным языкам, таким как Java; Например, внимательно посмотрите на модель памяти Java (глава 17 JLS).

— Стивен С
источник
17
Я предпочитаю говорить «Это ошибка , вероятно , в вашем коде», так как я столкнулся с ошибками в библиотеки времени выполнения в несколько раз. Я все еще сталкиваюсь с ошибкой компилятора все же. +1 в любом случае.
— Чинмай Канчи
29
Если вы никогда не находили истинную ошибку в компиляторе, вам не хватает приключений с вашим кодированием. ;)
— Мейсон Уилер
8
@Chinmay, @ spudd86, @Mason - да ... и я также нашел свою долю ошибок компилятора и библиотек в моих 30+ годах программирования. Но по моему опыту, 99 +% ошибок (по крайней мере частично) являются ошибкой моего кода. Мой ответ намеренно преувеличивает это, чтобы понять, что вы всегда должны сначала подозревать свой код.
— Стивен С
5
Я не понимаю иррационального страха, который испытывают люди с многопоточным программированием. Я подозреваю, что люди, которые поддерживают эту точку зрения, не программируют многопоточный код. Это просто не так сложно. +1 за все остальное, хотя.
— Стивен Эверс
4
Если вы работаете над компилятором, то ошибка, вероятно, и в вашем коде, и в компиляторе;)
— Legooolas
84
  • Как читать чужой код.
  • Код не существует, если он не проверен в системе контроля версий.
— pramodc84
источник
8
+10000, если бы я мог за комментарий контроля версий. История и регистрация изменений абсолютно необходимы и являются причиной, по которой вы должны с самого начала поставить все под контроль версий.
— Legooolas
2
... и хранилище было синхронизировано как минимум с одним другим местоположением. Важно с DVCS, но также с централизованным VCS.
В этом отношении код не существует, если не существует рабочего элемента, который уполномочивает разработчика его писать.
— Джесси С. Слайсер
2
Я добавлю один для изучения, как читать код других людей. Это сложнее, что большинство из нас понимают, но это неотъемлемая часть успешного программирования.
— Богеймин
плюс один для изучения, как читать код других людей.
— код
76

Вычисления с плавающей точкой не точны.

— Чинмай Канчи
источник
22
— Адам Пейнтер,
Если кто-то не знает, о чем я говорю, прочитайте ссылку @ Адама. Это превосходное резюме ловушек вычислений с плавающей запятой.
— Чинмай Канчи
1
И если они не знают, они могут быть среди множества людей, которые ежедневно спрашивают о переполнении стека.
— Брайан Р. Бонди
1
@ Брайан: Так верно. Хотелось бы, чтобы был способ определить вопросы, объясняемые арифметикой с плавающей запятой. Вы можете создать приложение Stack, которое каждый день отображает разные вопросы с плавающей запятой!
— Адам Пейнтер
63

Не прекращай учиться.

— systempuntoout
источник
1
Связанный: не прекращайте верить.
— Fishtoaster
3
Связанный: не прекращайте думать о завтрашнем дне.
— ocodo 13.12.10
7
Связанный: не останавливайте музыку.
— Адамк
1
Связанный: не прекращайте двигаться! Это твоя жизнь, продолжай двигаться, пойми это правильно, ты должен сделать это правильно!
— ocodo
44

То, что вы # 1 можете сделать, чтобы повысить качество и удобство сопровождения своего кода, это УМЕНЬШИТЬ ДУБЛИКАЦИЮ.

— Крис Холмс
источник
4
СУХОЙ, да! Как я могу забыть? ;-)
— Maniero
Это так важно, что я ответил снова .
Я бы скорее сказал: УМЕНЬШИТЕ УСЛОВИЯ. Каждое время / если / для является потенциальной ошибкой.
— zvrba
1
Знаешь, забавно, что в DRY это повторяется везде. :) +1
— Билли ONEAL
39

Устранение неполадок и навыки отладки

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

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

Другой программист: Я думаю, что мы должны попытаться увидеть, если это исправит это.
Я: Хорошо, предполагая, что это все исправит. Что это говорит вам о том, где источник проблемы?
Другой программист: я не знаю, но мы должны что-то попробовать .

— JohnFx
источник
2
Я собирался опубликовать это. Большая часть работы программиста заключается в исправлении ошибок, и многие люди, как правило, неспособны это сделать (особенно в коде других).
— Д
+1 Я перешел с javascript / php на C # и влюбился в пошаговое выполнение кода. Я хотел бы, чтобы динамически типизированные языки могли справляться с этим намного лучше.
— Эван Плейс
Другое странное поведение - программист, настаивающий на том, что каждая часть его программы является правильной, а результат - ошибочным. «Вам не нужно печатать массив на консоли, чтобы проверить, отсортирован ли он, потому что строка выше - array.sort ().» "-Ну ... вы знаете, это не работает. Должно быть, где-то что-то не так. Вы не можете просто защитить свой код на этом этапе!"
— Гави
2
Я думаю, что смысл отладки для проверки ваших предположений по всей вашей программе. Иногда вам нужно порыбачить, чтобы найти подсказки. Это должно быть сделано систематически. Совершенно верно попробовать что-то, что может рассказать вам что-то новое. Я делаю это часто.
— Гави
37
  1. Не будь умным; быть ясным.
  2. Используйте перед повторным использованием.
  3. Имена имеют значение.
  4. Функция делает 1 вещь и делает это хорошо.
  5. Маленький лучше, чем большой.
— KevBurnsJr
источник
2
Можете ли вы уточнить «Использовать перед повторным использованием». Я не слышал этого раньше.
— Тьяарт
34

Основы. В настоящее время программисты изучают технологии, а не концепции. Это не правильно.

— оборота
источник
И да и нет. Вы говорите как каждый проф, который я когда-либо имел в университете ... все из которых никогда не делали программных выликов за всю свою жизнь. Знания без навыков бесполезны в нашей профессии.
— Стивен Эверс
4
+1, это правда. Да, это то, что любят говорить про башни из слоновой кости, но это не делает его менее правдивым для остальных из нас в окопах.
— МАК
2
Основы как орфография? Its wrongдолжно быть it's wrong, например.
— Конерак
2
Нет, основы вроде не заботятся о опечатке, но заботятся о проблемах программирования.
— 2010 года
5
Легко выучить шаги, чтобы сделать что-то, и часто трудно понять, когда вы должны это использовать, и, что более важно, когда вы можете это использовать, но не должны. Учебники особенно плохо показывают, как, но не почему (и почему нет).
— HLGEM
27

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

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

— LennyProgrammers
источник
6
конкретно заявить тех, с кем assert()- везде. assert()поможет вам документировать свои предположения и спасти вас, когда вы ошибаетесь.
— Дастин
@ Dustin +1 Вы просто не можете вспомнить все свои предположения - запишите их программно, и вам точно скажут, когда они окажутся неверными.
— Скиллдрик
1
... если не скомпилировано с NDEBUG.
17

Изучай концепции . Вы можете Google синтаксис.

— pramodc84
источник
Хороший в теории, за исключением того, что Google ужасен для нахождения определенного синтаксиса: поиск таких терминов, как «ссылка на объект» или «это», дал результаты в несколько миллиардов и поиск идиом, таких как «$?» не дают результатов вообще.
— l0b0
14

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

— btlog
источник
13

Это сложнее, чем вы думаете.

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

Тогда вы должны сделать приложение хорошо выглядеть.

— ChrisF
источник
3
Я думаю, что это источник старой поговорки: 90% работы занимает 90% времени. последние 10% занимают остальные 90% времени »
— GSto
Я думаю, что многие люди постоянно недооценивают сложность. "Насколько тяжелым может быть Х?" - знаменитые последние слова: /
— Роман Старков
@ Так что я не хочу работать 180% времени, 100% - это нормально!
— Адамк
13

Базовые знания. Спецификация никогда не бывает 100%; знание фактического домена, для которого вы разрабатываете, ВСЕГДА будет повышать качество продукта.

— Стивен Эверс
источник
11

Указатели, очевидно. :)

— Лауринас Бивейнис
источник
3
Указатели действительно необходимы только в подмножестве языков для небольшого подмножества задач. Для большинства задач вы можете (и должны уметь) программировать так, как если бы концепция указателя не существовала.
— Чинмай Канчи
14
@Chinay Kanchi Нет. Указатели должны понимать все.
— альтернатива
5
Это действительно зависит от того, что вы подразумеваете под указателем. Если вы имеете в виду указатели в стиле C, которыми вы можете манипулировать (как я и предполагал), я бы сказал, что программисту на Java / C # / Python ничего не нужно знать о них. Если вы имеете в виду указатель, как в «ссылках» Java, т. Е. Указатель, с которым невозможно поиграться, то да, некоторые знания о них необходимы, хотя бы для того, чтобы предотвратить проскальзывание.
— Чинмай Канчи
@mathepic Вы будете потрясены до глубины души, если узнаете, сколько студентов CS выпускаются каждый год, которые не понимают в первую очередь указателей. Если бы я не старался изо всех сил устраивать каждое лето размещение, меня бы даже не учили об указателях на C или ссылках на Java ...
— Майк Б.
5
@Chinmay: программист Python / Java / C #, который не понимает концепцию указателей, потерян. L = [[]] * 2; L[0].append(42) Разные языки используют разные имена, но косвенность необходима везде.
11

Code Complete 2 - обложка для обложки

— Кайл Баллард
источник
Вы действительно должны знать это, прежде чем принимать деньги на программу. Если вы обнаружите в нем то, чего не знали, подумайте о смене профессии или интенсивном периоде самостоятельной учебы, чтобы пройти через все это. А потом извиняюсь перед вашими коллегами. И это только охватывает основы программирования.
— Тим Уиллискрофт
11

Данные важнее кода.

Если ваши данные умные, код может быть глупым.

Тупой код легко понять. Так же умные данные.

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

— Gonzales
источник
2
Вы были со мной до тех пор, пока не сказали «система типов».
10

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

— Рик Минерих
источник
8

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

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

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

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

— Клин
источник
8

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

— оборота user8
источник
6

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

— Brian R. Bondy
источник
4

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

— Wheaties
источник
2
или научитесь хорошо угадывать и сообщать, что вы не угадываете ...;)
— Билли Кувер
4

Стиль кодирования имеет значение:

  • последовательные отступы,
  • постоянное использование пустого пространства (например, вокруг операторов) имеет значение,
  • последовательное размещение вопросов {},
  • правильно выбранные идентификаторы имеют значение,
  • и т.п.

... и хороший дизайн имеет значение.

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

— Стивен С
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.