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

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

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

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

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

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

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

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

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

• Как читать чужой код.
• Код не существует, если он не проверен в системе контроля версий.

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

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

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

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

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

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

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

1. Не будь умным; быть ясным.
2. Используйте перед повторным использованием.
3. Имена имеют значение.
4. Функция делает 1 вещь и делает это хорошо.
5. Маленький лучше, чем большой.

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

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

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

Каждый программист должен знать о тестировании.

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

Критическое и логическое мышление. Вы не можете сделать ничего хорошего без этого.

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

Абсолютный минимум Каждый разработчик программного обеспечения Абсолютно, положительно должен знать о Unicode и наборах символов (никаких оправданий!) .

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

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

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

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

Обозначение Big O и его значение.

Несколько полезных ссылок

• http://www.perlmonks.org/?node_id=227909
• http://www.programmerinterview.com/datastruct/big-o-notation-example.php
• http://en.wikipedia.org/wiki/Big_O_notation

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

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

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

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

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

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

Какой язык и среда лучше всего подходят для работы. И это не всегда твой любимый.

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

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

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

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

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

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

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

Структуры данных

Как пользоваться Google

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

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

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

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

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

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