Що повинен знати кожен програміст?


245

Незалежно від використовуваних мов (програм) чи операційної системи чи середовища, для якого вони розробляються, що повинен знати кожен програміст?

Деякі відомості:

Мені цікаво стати найкращим програмістом, який я можу. У рамках цього процесу я намагаюся зрозуміти те, чого не знаю, і коли б мені це принесло користь. Хоча навколо ряду списків "n речей, які повинен знати кожен розробник [мова програмування]", я ще не міг знайти нічого подібного, що не обмежується певною мовою.

Я також очікую, що ця інформація буде цікавою та корисною для інших.

Відповіді:


636

Як ковтати гордість і визнавати помилки, не приймаючи їх особисто.


60
Це те, що повинна робити кожна людина незалежно від своєї роботи (... стать, релігія, культура, соціальний статус ...), ви не думаєте? ;)

3
О, так. Але ми, програмісти (принаймні, я), мають тенденцію мати більше явної гордості, ніж більшість :-)

17
Я хотів би, щоб я міг проголосувати за вас двічі.

4
Я думаю, що це одне, що я навчився в університеті. У старших класах я завжди був одним із розумних дітей. Якби я не ходив до університету, я б вважав, що я досить розумний і маю велике его. Збираючись в університеті та спілкуючись з людьми, які були справді більш кваліфікованими, тоді мені допомогли зрозуміти, наскільки я німий
Kibbee

4
Хоча це дуже вірно, проблема не завжди є запереченням чи великим его, але потенційними наслідками відкритого визнання помилок, принаймні, не без спочатку самооборони / контролю за пошкодженнями. Іноді це культурна річ. :)

309

Як мислити як користувач, а не як програвач-технік.


2
Мені завжди іронічно, що те, що, здається, більшості з нас у галузі не вистачає, може бути однією з найважливіших навичок: навички спілкування.

Не могла більше погодитися з цим. Це має бути №1.

23
Я фактично не згоден. Це те, для чого ти наймаєш людей. Ви ніколи не зможете думати, як користувач, але, безумовно, люди можуть сказати вам, що думають користувачі, і діяти за цією порадою. Просто не запитуйте користувачів, як вони думають! Це найгірший варіант з усіх.

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

3
Користувач може бути програмістом-техніком, але менш імовірно, програмістом-техніком, який також реалізував код . Якщо у додатку дуже тонка і складна семантика / поведінка, людина, яка написала код, може бути єдиною людиною, яка може зрозуміти, як користуватися програмою ...
Reuben

244

Коли просити допомоги, а коли НЕ просити допомоги.


2
Такий справжній. Останнім часом відповідь сплинула мені в голову, коли я когось запитував. :(
kevindaub

так, що відповідь?)

28
Попросіть спочатку гумового качка. Якщо він не може вам допомогти, то попросіть когось іншого ...
Дін, швидше,

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

1
Я завжди задаю собі запитання у відповідь "Що б сказав мій колега, якби я їх задав". Зазвичай це допомагає мені трохи пізніше зменшити проблему, перш ніж мені доведеться насправді запитати.

184

Як читати код інших людей.


102
Додаток: Як написати код, який можуть читати інші люди

42
Додаток №2: Як прочитати власний код через 6 місяців

10
@Nathan Koop: Краще "Як написати код, щоб ви могли його прочитати самостійно через 6 місяців".
Док Браун

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

7
Додаток №3: Як прочитати код через 6 хвилин.
mpen

152

Ознайомлення з системами управління версіями. Це не повинно бути кожним, але слід знати основні поняття, які можна застосувати до всіх.


і що контроль за редакцією не є програмним забезпеченням
jrhicks

4
Я хочу додати, що між централізованими SCM (наприклад, підрив, CVS) та розподіленими SCM (наприклад, git, mercurial, базар) існує достатньо значна різниця, що важливо вивчити один з кожного.
інтуїтоване

128

Ось мої 10 біт:

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

38
Це має бути вісімковий пост.
Навіть Мієн,

10
Щодо першого шматочка .... "Не будь так покірним, ти не такий чудовий".
Магнус,

@TheOtherScott, приємно ловити лол, але я насправді говорив 2 біти: D;)

3
Щодо пункту 3: www.acronymfinder.com
Джаспер Беккерс

1
@ jasper / інтуїтивно: просто введіть абревіатуру в google, і вона підніме ту чи іншу ... відповідь, як правило, є в одному з перших 10 результатів. більше інформації можна отримати, натиснувши!
mpen

104

Можливо, це занадто тонко, але я вважаю це "знанням, яку проблему вирішити". Багато програмістів (і нормальних людей) витрачають величезні зусилля на вирішення речей, які просто не дуже важливі; або вони створюють рішення з великою кількістю додаткової роботи, це не зовсім те, що потрібно.


4
Погоджено, що занепокоєння щодо сценаріїв використання бахроми, з якими зустрінеться лише небагатьох користувачів замість більшої функціональності, є надто поширеною пасткою! Я все ще довідаюся цього важкого шляху ...
Іван Робінсон,

Я повинен покласти посилання на вашу відповідь як домашню сторінку мого колишнього керівника команди. ти так прав.

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

95

Як відпочити. Це секрет продуктивності.

Зрештою, сили волі та кофеїну недостатньо. Це постійне скорочення, яке ми робимо, дуже згубне.

Це велика справа.


1
Що ви маєте на увазі під скороченням?

4
@Egg: Іноді, працюючи, я можу бути повністю розслабленою і дуже продуктивною. У свої погані дні я біжу на адреналін і кофеїн, і відчуваю величезне напруження в своєму тілі. Якщо я приділяю пильну увагу, я фактично стискаю деякі м’язи. Я постійно помічаю цю напругу в інших. На жаль, це може призвести до різного роду проблем, таких як вигорання та серцеві захворювання, і це, ймовірно, також призводить до чистої втрати продуктивності, оскільки спринтуватися можна лише протягом обмеженого часу. Про це скорочення я говорю.
Брайан Маккей

@Egg, він означає скорочення невикористаних м'язів.

2
говорячи про каву та скорочення, чи знаєте ви, що кава скорочує артерію, яка витягує кров до мозку. Це змушує мозок прокидатися. Зрештою, кава - це не така гарна річ. tl; dr пити воду
Рено

83

Основні типи даних та теорія алгоритму. Такі речі, як позначення Big O, масиви, черги тощо.


Це зовсім не допоможе вам, якщо все, що ви робите, - це майстерність шаблонів для систем управління веб-контентом.

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

7
Тільки тому, що вони вже реалізовані, не означає, що вам не доведеться розуміти, що потрібно використовувати, гарантії складності тощо. Це важливий елемент алгоритмів.

3
Домовились з Грегом Роджерсом. Можливо, вам доведеться реалізувати алгоритми, але ви краще зрозумієте їх складності та компроміси. Напр. Деякі алгоритми займають більше пам’яті, але вони швидші.

6
Ви не знатимете, який використовувати, якщо не розумієте їх. Алгоритми дуже важливі.

60

Як правильно вибрати інструмент для правильного завдання, а не брати участі в дурних полум’яних війнах про його улюблені засоби програмування.


+1, щоб цей не залишився о 42 :)
CharlesB

54

Ну ось мій .02 $:

  • Навчання ніколи не припиняється. Яким би добрим ви не вважали, що завжди є хтось кращий за вас, і завжди є щось, що ви можете вдосконалити про себе. Якщо ви перестанете вчитися, ви неминуче деградуєте як програміст. Читати книги. Читайте блоги. Поговоріть з іншими програмістами.
  • Спробуйте вивчити кілька мов. Принаймні один з них об'єктно-орієнтований. Крім того, ви повинні знати щось про різні технології, пов'язані з мовою, яку ви вивчаєте (наприклад, якщо ви вивчаєте Java, було б непогано, якби ви знали щось про весну тощо).
  • Рефакторинг. Рано чи пізно вам знадобляться ці знання.
  • Дізнайтеся, як поводитися зі застарілим кодом.
  • Напишіть одиничні тести. Дізнайтеся про TDD.
  • Навчіться працювати в команді.
  • Напишіть елегантний і читабельний код. Як говорить стара приказка: "Пишіть свій код так, ніби людина, яка збирається його підтримувати, - це психотичний серійний вбивця, який знає, де ви живете".
  • Навчіться бути ледачим і дисциплінованим одночасно. Хороші програмісти володіють обома цими якостями. Як не дивно, як здається, вони не суперечать один одному, а доповнюють один одного.

Це ваші .02 долари чи .02 центи? ЛОЛ! :-D

"Пишіть свій код так, ніби людина, яка збирається його підтримувати, - це психотичний серійний вбивця, який знає, де ви живете". +1
Бен

50

Ви не можете перевірити якість продукту.


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

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

5
Нещодавно стикалися - і застрягли: "Результатом тестування є не якість, а знання".
peterchen

richdiet: Експерт SQA Джеймс Бах вважає, що "A" у SQA / QA має означати "Assistance". Я повністю згоден з його думкою та вашою заявою.

44

Кожен програміст повинен розуміти шаблони дизайну .


13
Я додам, що вони також потребують розуміння того, що не все може бути взуттю в певний дизайн.
tloach

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

2
шаблони дизайну для дезінгів не є "програмістами" - програмісту потрібно знати, що коли він / вона стане "дизайнером"

10
Є два типи людей .. люди, яким подобається кодування, і люди, які вважають за краще говорити про кодування. Дизайн моделей є обов'язковим для другої групи ..
Bjorn Reppen

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

44

Я трохи запізнююсь на цей, але я пітиму зі знаннями, закладеними Едсгером Дайкстра:

Окрім математичного нахилу, надзвичайно добре оволодіння рідною мовою є найважливішим надбанням компетентного програміста.

Якщо ви не можете написати хороший абзац, швидше за все, ви також не можете написати хороший код.


8
І все ж я вражений жахливим написанням, граматикою та пунктуацією, які використовуються в написанні на природній мові деякими програмістами. Ви б могли подумати, що щодня працювати із системами, які мають нульову толерантність до орфографічних помилок та недійсного синтаксису, сприятливо вплине ...

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

@Inshallah: якщо ти не робиш щось подібне if (BlowUpTheSystem = 1). Зрозуміло, якщо правильно перевірити блок, ви, ймовірно, заощадите лише час. Але тоді досить важливий час.
інтуїтоване

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

39

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

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

І з часом спробуйте зрозуміти та оцінити рід, спадщину та спільність різних технологій, які допоможуть вам зберегти перспективу. Зрозумійте, наприклад, що, хоча еволюційне дерево активно розгалужується і повне тупиків, з часом технології, як правило, неодноразово сходяться навколо "найкращих практик" та "економії масштабу" ( наприклад, зауважте, що Mac не все інше, ніж ПК під кришкою в ці дні ...).

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



35

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


Якби у мене було одне бажання, було б, щоб Санта був моїм батьком.

Тому що Санта ...?

1
День, коли ти перестанеш вчитися, має бути днем, коли ти помреш. :) +1 у будь-якому разі
ShdNx

Отже, щоб жити вічно, ви завжди повинні продовжувати вчитися? Тепер є ідея, яку я можу підтримати!
канадський секретар

34

Тестування та налагодження.


Перший знімає потребу в другому. ;-)

4
Ні, коли тест модуля не працює, це потребує налагодження. Двоє йдуть разом.
Зан Лінкс

Неможливо цього підкреслити.
fastcodejava

33

Про це йшлося раніше, але я думаю, що він заслуговує на власну відповідь.


Я все більше і більше наживаюсь на це, і тут і там я збираю твори, але я все ще не любитель.

Я повністю згоден. Це виглядає дивно і складно, коли ти його не розумієш, але коли ти розумієш це, це набагато простіше, ніж тонна дзвінків підрядків / indexof функцій, що потрібно було б зробити те ж саме інакше. Я б просто переконався, що ваші зразки добре коментуються.
Кіббі

9
Деякі люди, стикаючись з проблемою, думають, "я знаю, я буду використовувати регулярні вирази". Зараз у них дві проблеми. - "Джеймі Завінський": jwz.livejournal.com , в comp.lang.emacs
Bjorn Reppen

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

1
Деякі люди, стикаючись із регулярним виразом, думають: "Я знаю, я цитую Джеймі Завіньського". Зараз у них є дві проблеми (одна з яких полягає в тому, що вони, мабуть, не знають, що вони роблять в першу чергу) .
Дональні стипендіати

29

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


7
Саме так. Коли я чую, як розробники намагаються пояснити базу даних кінцевому користувачеві як відповідь на їхнє питання, чому чогось не можна зробити, я збиваюся з місця. Їм не потрібно знати, як ми робимо речі. Вони просто хочуть, щоб це спрацювало. І саме так і має бути.
Кевін Ферчільд,

Мені подобається вірити, що можна писати програмне забезпечення, яким люди користуються із задоволенням.

Не можу погодитися більше. Однак це стосується і API. Ніхто не хоче вивчати нові API, тому що це так чортово смішно. Ми хочемо функціональність API, а не код, який він представляє.
Blub

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

27

Кава та IntelliSense - ваші найкращі друзі коли-небудь.


Я б хотів, щоб я міг дати це більше, ніж 1 підсумок!
Діна

Я сподіваюся на каву більше !!!! ñ_ñ

Я думаю, що я згоден з цим більше, ніж будь-яка інша річ на SO.
Unkwntech

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

Кава не дає вам ніякої енергії. Це просто вичавити частину із внутрішніх резервів. Це погано / нездорово.
Андрій Рінея

18

Як спостерігати за великим складним предметом і розкладати його на невеликі прості об’єкти, які все ще виконують те саме завдання, коли їх знову зібрати.


18

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

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


1
Це занадто узагальнено. Деякий прагматизм також хороший.
mafu

18

Про те, що програміст не знає всього і завжди повинен намагатися вивчати нові мови / технології тощо.


16

Основи гарного дизайну інтерфейсу та комунікаційного (він же графічного) дизайну .

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

Рекомендована книга - Книга дизайну недизайнера Робіна Вільямса

Ось що про це говорить Джоел Спольський :

Оце Так! Усі повинні робити якийсь графічний дизайн, і не кожна команда програмного забезпечення має розкіш професійних дизайнерів. Ця відмінна, тонка книга дасть вам зрозуміти принципи розташування сторінки, шрифти тощо. Хороша новина полягає в тому, що ви можете прочитати її у ванні до того, як вода застудиться, а наступного дня ваші діалогові вікна та пункти живлення та веб-сторінки почнуть виглядати краще.


1
По-друге, з додатковим кивком до «дизайну повсякденних речей». amazon.com/Design-Everyday-Things-Donald-Norman/dp/0385267746
Stimul8d

14

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


Я розпочав свою першу в історії роботу з програмування і протягом тижня писав код, який врешті-решт вийшов наживо. На щастя, я швидко навчаюся і маю досвід програмування. Протягом 6 місяців я реструктурував з'єднання клієнт-сервер, щоб покращити продуктивність втричі. Це було мовою, якою я ніколи раніше не користувався.

14

Контроль версій. І щоб процитувати мою подругу дівчину: "Я не просто хочу, щоб ти мив посуд, я хочу, щоб тобі сподобалось !"


10

Вимоги змінюються, ваш код доведеться адаптувати, і вам може бути, а може і не бути вам тим, хто повинен його адаптувати.

Там було кілька питань тут , пов'язаних з тим, що страждають від цього.


10

Вгорі голови:

  1. Дуже мало проблем із програмуванням вимагає математики поза складанням, відніманням, множенням та діленням. Якщо ви думаєте використовувати обчислення для вирішення проблеми, вивчіть альтернативи, перш ніж зробити це.

  2. Кожного разу, коли ви здогадаєтесь про те, як щось має працювати, ви робите це неправильно. Це не ваша робота бути телепатичним.

  3. Людина, яка надає вам специфіка, рідко знає все, що хоче, доки ви не перемолоте її.

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

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

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

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

  8. Ніколи не дивіться на технологію, а завжди шукайте найкращу альтернативу.

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

  10. Не турбуйте повільне повзання програмно-орієнтованих думок у повсякденному житті. Навіть коли ми не знаходимось за комп’ютером, ми всі страждаємо від обмеження пропускної спроможності, несемо штрафні показники за рахунок переключення завдань і нам потрібно завантажувати речі з резервного сховища. Комп'ютери повинні імітувати людську думку, а аналоги є скрізь.


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

9

Читання коду інших народів не зіпсує ваш мозок, а скоріше з’ясуйте, чому б ви цього не зробили (якщо краще чи ні - інше питання).

Це дає вам програмувати gedankenexperiment , а іноді ви можете знайти когось, що реалізує щось краще! Як у спосіб краще.

Ця відповідь природно розширюється на читання власного коду, таким чином, він розширює використання контролю версій та DIFF, а отже, до 42.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.