모든 프로그래머가 알아야 할 것은 무엇입니까?

프로그래밍 언어 또는 사용 된 운영 체제 또는 개발 환경에 관계없이 모든 프로그래머가 알아야 할 사항은 무엇입니까?

일부 배경 :

저는 최고의 프로그래머가되고 싶습니다. 이 과정의 일부로, 나는 내가 모르는 것을 이해하려고 노력하고 있으며, 내가한다면 많은 혜택을 얻을 것입니다. "모든 [삽입 프로그래밍 언어] 개발자가 알아야 할 사항"라인을 따라 많은 목록이 있지만, 아직 특정 언어로 제한되지 않는 유사한 것을 찾지 못했습니다.

또한이 정보가 다른 사람들에게 흥미롭고 유익 할 것으로 기대합니다.

자존심을 삼키고 개인적으로 실수하지 않고 실수를 인정하는 방법.

techie 괴짜 프로그래머가 아닌 사용자처럼 생각하는 방법.

도움을 요청할 때와 도움을 요청하지 않을 때.

다른 사람의 코드를 읽는 방법.

버전 관리 시스템에 익숙합니다. 모든 것이 될 필요는 없지만 모든 것에 적용 할 수있는 기본 개념을 알아야합니다.

여기 내 10 비트가 있습니다 :

• 겸손 해지는 법. 우리는 모두 배우기 위해 여기 있습니다. 당신은 다른 사람들보다 똑똑 할 수도 있지만, 많은 사람들이 당신보다 똑똑합니다.
• 정보를 연구 / 소비하는 방법. 나는 당신에 대해 모른다. 그러나 나는 영원히 공부하고있다! 책, 인터넷 등 무엇이든!
• 사전이란 무엇이며 사전을 사용하는 방법과 약어를 빨리 찾는 방법.
• 거래의 기본 도구는 무엇이며 그 기능은 무엇입니까 (IDE, CVS et al).
• 일반적인 용어와 그 의미를 이해하십시오 : 디자인 패턴, 유용성, 테스트 (ha!), 스택 등
• OOP에 대해 이해하십시오.
• 하나 이상의 언어로 "가능"하고 놀라운 것은 없으며 변수와 메소드를 식별하는 방법 등 만 알고 있습니다. 여기에서 FAST를 배울 수 있습니다.
• 사람들이 궁극적으로 소프트웨어를 사용하고 사람들을 행복하게 만들고 싶어 한다는 것을 이해하십시오 .

어쩌면 너무 미묘하지만 " 어떤 문제 를 해결 해야하는지 아는 것"이라고 생각합니다 . 많은 프로그래머들 (그리고 보통 사람들)은 그다지 중요하지 않은 것들을 해결하기 위해 엄청난 노력을 낭비합니다. 또는 추가 작업이 많이 필요한 솔루션을 만드는 데 필요한 것은 아닙니다.

긴장을 푸는 방법. 생산성의 비결입니다.

결국 의지력과 카페인으로는 충분하지 않습니다. 우리가하는이 지속적인 수축은 매우 해 롭습니다.

이것은 큰 문제입니다.

기본 데이터 유형 및 알고리즘 이론. Big O 표기법, 배열, 대기열 등

올바른 작업에 적합한 도구를 선택하고 자신이 좋아하는 프로그래밍 도구에 대한 바보 같은 전쟁에 참여하지 않는 방법.

글쎄, 여기 내 .02 $가 있습니다 :

• 학습은 멈추지 않습니다. 아무리 자신이 좋다고 생각하더라도 항상 당신보다 나은 사람이 있으며, 자신에 대해 개선 할 수있는 것이 항상 있습니다. 학습을 중단하면 프로그래머로서 필연적으로 저하됩니다. 책을 읽으십시오. 블로그를 읽으십시오. 다른 프로그래머와 대화하십시오.
• 여러 언어를 배우십시오. 그들 중 적어도 하나는 객체 지향적입니다. 또한, 배우는 언어와 관련된 다양한 기술에 대해 알고 있어야합니다 (예 : Java를 배우면 Spring에 대해 알고 있다면 좋을 것입니다.).
• 리팩토링. 조만간 그 지식이 필요합니다.
• 레거시 코드를 처리하는 방법에 대해 알아보십시오.
• 단위 테스트를 작성하십시오. TDD에 대해 알아보십시오.
• 팀에서 일하는 법을 배웁니다.
• 우아하고 읽기 쉬운 코드를 작성하십시오. 이전의 말처럼 : "코드를 유지할 사람이 당신이 사는 곳을 알고있는 정신병 연쇄 살인범처럼 코드를 작성하십시오."
• 게으르고 징계하는 법을 배우십시오. 훌륭한 프로그래머는이 두 가지 특성을 모두 갖추고 있습니다. 이상하게 보이면 서로 모순되지 않고 보완 적입니다.

제품의 품질을 테스트 할 수 없습니다.

모든 프로그래머는 디자인 패턴을 이해해야 합니다 .

나는 이것에 조금 늦었지만 Edsger Dijkstra가 제시 한 지식과 함께 갈 것입니다.

수학적 성향 외에도, 모국어를 능숙하게 익히는 능력은 유능한 프로그래머의 가장 중요한 자산입니다.

좋은 단락을 쓸 수 없다면 좋은 코드도 쓸 수 없을 가능성이 높습니다.

주어진 기술, 운영 체제 또는 언어에 너무 감정적으로 투자하거나 첨부하거나 종교에 의존하지 마십시오. 아무것도 완벽하지 않습니다. 장기적으로 자신이 만든 일품에서 자신 만의 일품 요리를 만들 수 있기를 바랍니다. 서로에 대해 좋아합니다.

자동차라고 생각하십시오-이전에 특정 자동차를 운전하지 않았을 수도 있지만 키, 스티어링 휠, 액셀러레이터 및 브레이크가 모두 포함되어 있습니다. 어디에 무엇이 있는지 분류하면 하나를 타고 빨리 빠져 나올 수 있어야합니다. OS와 언어를 비슷하게 취급하고 특정 인스턴스의 특정 내용에 진취가 있어도 기본 개념을 배우는 데 중점을 둡니다.

그리고 시간이 지남에 따라 다양한 기술의 조상, 유산 및 공통점을 이해하고 이해하여 관점을 유지하는 데 도움이됩니다. 예를 들어, 진화 트리가 활발하게 분기되고 막 다른 골목으로 가득 차 있지만 시간이 지남에 따라 기술은 '모범 사례'와 '규모의 경제'에 대해 반복적으로 수렴하는 경향이 있습니다 ( 예 : Mac이 요즘 후드 아래 PC ...).

마지막으로, 기술이 아무리 즐거워도 기술은 본질적으로 상상할 수있는 것과 실제로 생산하는 것 사이의 불완전한 렌즈를 나타냅니다. 최선을 다하고 배우는 법을 배우십시오.

C로 프로그래밍하는 방법

학습을 중단 한 날은 더 이상 프로그래머가 아닌 날이어야합니다.

단위 테스트 및 디버깅.

• 정규식
  • 그들이 좋은 것
  • 하면 되지 하는 사용 을
  • 읽을 수있는 정규식 을 작성하는 방법
  • 그것들 을 디버깅하는 방법

이전에 언급되었지만 자체 답변이 필요하다고 생각합니다.

아무도 소프트웨어를 사용하고 싶어하지 않습니다. 그들은 문제가 해결되기를 원합니다.

커피와 IntelliSense 는 가장 친한 친구입니다.

큰 복잡한 물체를 관찰하고 다시 조립할 때 여전히 동일한 작업을 수행하는 작은 간단한 물체로 분해하는 방법.

사용자를 신뢰하지 마십시오 ( 특히 앱이 공개 된 경우). 종종 앱을 무너 뜨리기 위해 모든 작업을 수행합니다.

미래의 증거 및 확장 성 제공 – 몇 년 내에 확장해야 할시기를 알 수 없으며 잘못 작성된 코드를 다시 코딩하는 데 얼마나 많은 노력이 필요한지 알 수 없습니다.

프로그래머가 모든 것을 알지 못하고 항상 새로운 언어 / 기술 등을 배우려고 노력해야합니다.

좋은 UI 디자인과 커뮤니케이션 (일명 그래픽) 디자인의 기초 .

디자인이 나쁘거나 사용성이 좋지 않아서 많은 앱과 프로젝트가 보입니다. 기본을 배우는 것만으로도 세상을 변화시킬 수 있습니다. 또한 시각적 문제 해결 기술 (즉, 개념을 시각적으로 전달하는 방법)은 새로운 보는 방식에 눈을 뜨고 결과적으로 코드에 영향을 미치는 자극적 인 도전입니다.

권장되는 책은 Robin Williams 의 비 디자이너의 디자인 북입니다.

Joel Spolsky가 말한 내용은 다음과 같습니다 .

와! 모두가 그래픽 디자인을해야하며, 모든 소프트웨어 팀이 전문 디자이너의 사치를 가진 것은 아닙니다. 이 훌륭하고 얇은 책은 페이지 레이아웃, 글꼴 등의 기본 원리를 파악할 수 있습니다. 좋은 소식은, 물이 차가워지기 전에 목욕에서 읽을 수 있고 다음날 대화 상자와 파워 포인트와 웹 페이지가 더 좋아 보이기 시작합니다.

모든 프로그래머는 빨리 배우는 방법을 알아야합니다. 많은 시간을 당신이 직장에 와서 결코 사용하지 않은 기술로 개발하도록 요청받을 것입니다. 프로덕션 품질 코드를 작성하라는 요청을 받기 전에 일주일 정도 걸릴 수 있습니다 (운이 좋으면).

버전 관리. 그리고 내 여자 친구를 인용하기 위해 : "나는 당신이 요리를하고 싶지 않아요, 당신이 그것을 좋아하기를 바랍니다 !"

요구 사항이 변경되면 코드를 수정해야하며 코드를 조정해야하는 사람 일 수도 있고 아닐 수도 있습니다.

가 있었다 몇 가지 질문이 여기에 이에 의해 영향을받는 주제와 관련된.

내 머리 꼭대기에서 :

1. 덧셈, 뺄셈, 곱셈 및 나눗셈을 넘어서는 수학이 필요한 프로그래밍 문제는 거의 없습니다. 미적분학을 사용하여 문제를 해결하려는 경우 대안을 철저히 조사하여 문제를 해결하십시오.

2. 무언가가 어떻게 작동하는지 추측 할 때마다 잘못하고 있습니다. 텔레파시하는 것은 당신의 일이 아닙니다.

3. 사양을 제공하는 사람은 해시 할 때까지 원하는 모든 것을 거의 알지 못합니다.

4. 훌륭한 프로그래머가되는 것의 절반 이상이 인간을 대하는 데서 온다. 팀과 상호 작용하고, 관리자를 관리하고, 최종 사용자를 벌금을내는 것은 작업의 절반입니다.

5. 좋은 코드는 컴파일러가 읽을 수있는만큼 사람들이 읽을 수 있도록 작성되었습니다.

6. 모범 사례와 실제 현실은 프로그래머가 생각하는 것보다 갈등이 많지만 관리자가하는 것보다 적습니다. 그들이 갈등을 겪고있는 것처럼 보일 때, 갈등을 묘사하고 이해 한 다음 실용성을 부여하는 것은 당신에게 달려 있습니다. 미묘하고 영리한 솔루션은 추악하고 잔인한 솔루션보다 장기적으로 비용면에서 더 효과적입니다.

7. 훌륭한 도구는 훌륭한 프로그래머를 만들 수는 없지만 나쁜 도구는 우리를 똑같이 끔찍하게 만듭니다.

8. 기술을 내려다 보지 말고 항상 최상의 대안을 찾으십시오.

9. 더 많은 언어를 알수록 사용하는 언어가 더 좋아집니다.

10. 일상 생활에 프로그래밍 지향적 사고가 느리게 방해되어 방해받지 마십시오. 컴퓨터를 사용하지 않더라도 대역폭 제한으로 인해 작업 전환으로 인한 성능 저하가 발생하며 백업 스토리지에서로드해야합니다. 컴퓨터는 인간의 사고를 모방해야하며 아날로그는 어디에나 있습니다.

다른 사람들의 코드를 읽는 것이 두뇌를 망칠 것이 아니라 오히려 그렇게하지 않은 이유를 알아내는 것입니다.

이것은 당신에게 gedankenexperiment 프로그래밍을 제공 하고 때로는 무언가 더 나은 것을 구현하는 누군가를 발견합니다! 더 나은 방법으로.

이 답변은 자연스럽게 자신의 코드를 읽는 것으로 확장되므로 버전 제어 및 DIFF를 사용하도록 확장되어 42로 확장됩니다.