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

Как проглотить гордость и признать ошибки, не принимая их лично.

Как думать как пользователь, а не как программист-программист.

Когда обращаться за помощью и НЕ обращаться за помощью.

Как читать код других людей.

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

Вот мои 10 бит:

• Как быть смиренным. Мы все здесь, чтобы учиться. Вы можете быть умнее других, но есть много умнее вас.
• Как изучать /потреблять информацию. Я не знаю о вас, но я навсегда изучаю! Книги, Интернет, что угодно!
• Что такое словарь и как его использовать, и как быстро найти аббревиатуры.
• Каковы основные инструменты торговли и что они делают (IDE, CVS и др.).
• Знайте общую терминологию и то, что они означают: шаблоны проектирования, удобство использования, тестирование (ха!), стек и т. д.
• Имейте понимание ООП.
• Быть «способным» по крайней мере на одном языке, ничего удивительного, просто знать, как идентифицировать переменные и методы и т. д. Отсюда вы можете узнать FAST.
• Поймите, что люди в конечном счете используют программное обеспечение и хотят, чтобы эти люди были счастливы.

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

Как расслабиться. Это секрет производительности.

В конце концов, силы воли и кофеина недостаточно. Это постоянное сокращение, которое мы делаем, очень повреждает.

Это большое дело.

Основные типы данных & теория алгоритмов. Такие вещи, как нотация Big O, массивы, очереди и т. Д.

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

Хорошо, вот мой .02 $:

• Обучение никогда не прекращается. Независимо от того, насколько вы хороши, как вы думаете, всегда есть кто-то лучше вас, и всегда есть что-то, что вы можете улучшить о себе. Если вы перестанете учиться, вы неизбежно деградируете как программист. Читать книги. Читайте блоги. Поговорите с другими программистами.
• Попробуйте изучить несколько языков. По крайней мере один из них объектно-ориентированный. Кроме того, вы должны знать что-то о различных технологиях, связанных с языком, который вы изучаете (например, если вы изучаете Java, было бы хорошо, если бы вы знали что-то о Spring и т. Д.).
• Рефакторинг. Рано или поздно вам понадобятся эти знания.
• Узнайте, как работать с устаревшим кодом.
• Напишите модульные тесты. Узнайте о TDD.
• Научитесь работать в команде.
• Напишите элегантный и читаемый код. Как говорится в старой поговорке: «Напиши свой код, как будто человек, который будет его поддерживать, - это психотический серийный убийца, который знает, где ты живешь».
• Узнайте, как быть ленивым и дисциплинированным одновременно. Хорошим программистам принадлежит оба этих качества. Как ни странно, они не противоречат друг другу, но дополняют друг друга.

Вы не можете проверить качество продукта.

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

Я немного опаздываю к этому, но я пойду со знаниями, изложенными Эдсгером Дейкстре:

  

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

Если вы не можете написать хороший параграф, скорее всего, вы тоже не можете написать хороший код.

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

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

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

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

Как программировать на C.

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

Тестирование и отладка модулей.

• Регулярные выражения
  • Что они хороши для
  • Когда не to использовать их
  • Как написать читаемые регулярные выражения
  • Как отладить их

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

Никто не хочет использовать программное обеспечение. Они хотят решить проблемы.

Кофе и IntelliSense - ваши лучшие друзья.

Как наблюдать большой сложный объект и разлагать его на небольшие простые объекты, которые все еще выполняют одну и ту же задачу при объединении снова.

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

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

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

Основы хорошего дизайна пользовательского интерфейса и коммуникации (ака графического) дизайна .

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

Рекомендуемая книга Дизайнерская книга Non-Designer от Робин Уильямс

Вот что Джоэл Спольский говорит об этом :

  

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

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

Контроль версий. И процитировать мою подружку: «Я не просто хочу, чтобы вы делали блюда, я хочу, чтобы вы понравились !»

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

Было несколько вопросы здесь , связанных с темами, на которые это влияет.

Сверху моей головы:

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

2. Каждый раз, когда вы угадываете, как что-то должно работать, вы делаете это неправильно. Это не ваша работа, чтобы быть телепатичной.

3. Человек, дающий вам спецификацию, редко знает все, что хочет, пока вы его не испортили.

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

5. Хороший код написан для чтения людьми настолько, насколько он должен быть прочитан вашим компилятором.

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

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

8. Никогда не смотрите на технологию, но всегда ищите лучшую альтернативу.

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

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

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

Это дает вам программирование gedankenexperiment , и иногда вы обнаружите, что кто-то внедряет что-то лучше! Как в порядке лучше.

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