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


245

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

Немного предыстории:

Я заинтересован в том, чтобы стать лучшим программистом, которого я могу. В рамках этого процесса я пытаюсь понять, чего я не знаю, и принесу мне большую пользу, если я это сделаю. Несмотря на то, что существует множество списков по типу «n вещей, которые должен знать каждый [вставить язык программирования] разработчик», мне еще предстоит найти что-то подобное, не ограниченное конкретным языком.

Я также ожидаю, что эта информация будет интересна и полезна для других.

Ответы:


636

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


60
Это то, что должен делать каждый человек независимо от его работы (... пола, религии, культуры, социального статуса ...), не так ли? ;)

3
О да. Но мы, программисты (по крайней мере, я), склонны испытывать больше явной гордости, чем большинство :-)

17
Я хотел бы проголосовать за тебя дважды.

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

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

309

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


2
Я всегда нахожу ироничным, что то, чего, как кажется, большинству из нас не хватает, может быть одним из самых важных навыков: коммуникативных навыков.

Не могу согласиться с этим больше. Это должно быть № 1.

23
Я на самом деле не согласен. Вот для чего вы нанимаете людей. Вы никогда не сможете думать, как пользователь, но вы, безусловно, можете попросить людей сказать вам, что думают пользователи, и действовать в соответствии с этим советом. Только не спрашивайте пользователей, как они думают! Это худший вариант из всех.

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

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

244

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


2
Это точно. В последнее время ответ возник в моей голове, когда я спрашивал кого-то. :(
kevindaub

Итак, каков ответ?)

28
Сначала спросите своего резинового утенка. Если он не может вам помочь, тогда попросите кого-нибудь еще ...
Дин Ратер

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

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

184

Как читать чужой код.


102
Приложение: Как писать код, который могут читать другие люди

42
Приложение № 2: Как читать собственный код 6 месяцев спустя

10
@ Натан Куп: Должно быть лучше "Как написать код, чтобы вы могли прочитать его самостоятельно через 6 месяцев".
Док Браун

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

7
Приложение № 3: Как читать код через 6 минут.
mpen

152

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


и что контроль версий не является программным обеспечением
jrhicks

4
Я хотел бы добавить, что между централизованными SCM (например, subversion, CVS) и распределенными SCM (например, git, mercurial, bazaar) существует достаточно существенная разница, поэтому важно изучить один из них.
интуитивно

128

Вот мои 10 битов:

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

38
Это должен быть восьмеричный пост.
Даже Mien

10
Что касается первого бита ... «Не будь таким скромным, ты не так уж велик».
Магнус

@TheOtherScott, хороший улов, лол, но я на самом деле говорил 2 бита: D;)

3
Относительно пункта 3: www.acronymfinder.com
Джаспер Беккерс

1
@ jasper / intuited: просто введите аббревиатуру в Google, и она подтянет один или другой ... Ответ, как правило, в любом из первых 10 результатов. больше информации можно получить, нажав!
mpen

104

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


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

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

4
Мне нравится, что вы сказали "много программистов (и нормальных людей)" :-)

95

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

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

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


1
Что вы имеете в виду под сокращением?

4
@ Яйцо: Иногда, когда я работаю, я могу быть полностью расслабленным и очень продуктивным. В плохие дни я использую адреналин и кофеин и чувствую огромное напряжение в теле. Если я обращаю пристальное внимание, я на самом деле сокращаю некоторые мышцы. Я постоянно замечаю это напряжение в других. К сожалению, это может привести к всевозможным проблемам, таким как выгорание и болезни сердца, и, вероятно, также приведет к чистой потере производительности, поскольку спринт можно проводить только в течение ограниченного периода времени. Это сокращение, о котором я говорю.
Брайан Маккей

@ Яйцо, он означает сокращение неиспользованных мышц.

2
Говоря о кофе и сокращении, вы знали, что кофе сжимает артерию, доставляя кровь к мозгу. Это заставляет мозг просыпаться. Кофе не очень хорошая вещь в конце концов. д-р пить воду
Рено

83

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


Совсем не поможет, если все, что вы делаете, - это создание шаблонов для систем управления веб-контентом.

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

7
Тот факт, что они уже реализованы, не означает, что вам не нужно понимать, что и когда использовать, гарантии сложности и т. Д. Это важная составляющая алгоритмов.

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

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

60

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


+1, чтобы этот не остался в 42 :)
CharlesB

54

Ну, вот мой .02 $:

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

Это ваши 0,02 доллара или 0,02 цента? ЛОЛ! :-D

«Напишите свой код так, как будто человек, который собирается поддерживать его, является психотическим серийным убийцей, который знает, где вы живете». +1
Бен

50

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


2
Таким образом, у специалистов по обеспечению качества неправильное имя.

1
Технически говоря, QA и Test - это не одно и то же, хотя, на ваш взгляд, я не уверен, что большинство организаций на самом деле применяют разницу.
Высокий Джефф

5
Недавно столкнулся - и застрял: «Результатом тестирования является не качество, а знания».
peterchen

richdiet: эксперт по SQA Джеймс Бах считает, что «A» в SQA / QA должно обозначать «Assistance». Я полностью согласен с его мнением и вашим утверждением.

44

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


13
Я бы добавил, что им также необходимо понимание того, что не все может быть подковано в данный шаблон дизайна.
tloach

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

2
шаблоны проектирования предназначены для разработчиков, а не для «программистов» - программист должен знать, что когда он / она станет «дизайнером»

10
Есть два типа людей .. люди, которые любят кодирование и люди, которые предпочитают говорить о кодировании. Дизайн моделей является обязательным для второй группы ..
Бьорн Реппен

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

44

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

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

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


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

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

@Inshallah: если вы не делаете что-то вроде if (BlowUpTheSystem = 1). Конечно, при условии правильного модульного тестирования вы, скорее всего, сэкономите только время. Но тогда время очень важно.
интуитивно

2
Согласитесь ... хм ... минус часть "родного языка", некоторые из нас [к сожалению?] Общаются лучше / яснее на наших не родных языках.

39

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

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

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

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



35

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


Если бы у меня было одно желание, Санта был бы моим отцом.

Потому что Санта ...?

1
День, когда ты перестанешь учиться, должен стать днем ​​твоей смерти. :) +1 в любом случае
ShdNx

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

34

Модульное тестирование и отладка.


Первое устраняет необходимость во втором. ;-)

4
Нет, когда модульный тест не пройден, это требует отладки. Два идут вместе.
Zan Lynx

Не могу не подчеркнуть это достаточно.
fastcodejava

33

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


Я использую его все больше и больше и собираю кусочки тут и там, но я все еще не любитель.

Я полностью согласен. Это выглядит странно и сложно, когда вы этого не понимаете, но когда вы это понимаете, это гораздо проще, чем тонна вызовов функции substring / indexof, которые в противном случае были бы необходимы для того же. Я просто хотел бы убедиться, что ваши шаблоны хорошо прокомментированы.
Кибби

9
Некоторые люди, сталкиваясь с проблемой, думают: «Я знаю, я буду использовать регулярные выражения». Теперь у них две проблемы. - "Джейми Завински": jwz.livejournal.com , в comp.lang.emacs
Бьорн Реппен

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

1
Некоторые люди, сталкиваясь с регулярным выражением, думают: «Я знаю, я процитирую Джейми Завински». Теперь у них есть две проблемы (одна из которых заключается в том, что они, вероятно, вообще не знают, что они делают). ,
Донал Феллоуз

29

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


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

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

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

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

27

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


Я хотел бы дать это больше, чем 1 голос!
Дина

Я надеюсь выпить больше кофе !!!! ñ_ñ

Я думаю, что я согласен с этим больше, чем любая другая вещь на SO.
Unkwntech

Я практически никогда не пью кофе, если мне абсолютно не нужно закончить проект за X часов, когда: Количество использованных часов + X> 8 за день.
Blub

Кофе не дает вам никакой энергии. Это просто выжать из ваших внутренних резервов. Это плохо / нездорово.
Андрей Ринея

18

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


18

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

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


1
Это слишком обобщенно. Некоторый прагматизм также хорош.
Мафу

18

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


16

Основы хорошего UI-дизайна и коммуникационного (он же графического) дизайна .

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

Рекомендованная книга Робина Уильямса «Дизайнерская книга не дизайнера»

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

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


1
Я добавлю это с дополнительным кивком на «дизайн повседневных вещей». amazon.com/Design-Everyday-Things-Donald-Norman/dp/0385267746
Stimul8d

14

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


Я начал свою первую работу по программированию и в течение недели писал код, который в конечном итоге заработал. К счастью, я быстро учусь и имею опыт программирования. В течение 6 месяцев я реструктурировал соединение клиент-сервер, чтобы повысить производительность в три раза. Это было на языке, который я никогда не использовал раньше.

14

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



10

С верхней части моей головы:

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

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

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

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

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

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

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

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

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

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


Номер 10 заставил меня смеяться. Так много раз я буду работать над проблемой на работе, но только в постели в 10 вечера я в конце концов придумаю ответ!

9

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

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

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

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