모든 프로그래머는 프로그래밍에 대해 무엇을 알아야합니까?

제발, 기술적 인 문제에있어 , 행동, 문화, 직업, 정치적 문제를 방지.

1. 버그는 컴파일러 또는 런타임 라이브러리가 아닌 코드 에 있습니다 .

2. 발생할 수없는 버그가 표시되면 프로그램을 올바르게 빌드하고 배포했는지 확인하십시오. (특히 복잡한 IDE 또는 빌드 프레임 워크를 사용하여 지저분한 세부 정보를 숨기려고하는 경우 또는 빌드에 많은 수동 단계가 필요한 경우)

3. 동시 / 멀티 스레드 프로그램은 쓰기가 어렵고 제대로 테스트하기가 어렵습니다. 동시성 라이브러리 및 프레임 워크에 최대한 많이 위임하는 것이 가장 좋습니다.

4. 문서 작성은 프로그래머로서의 일의 일부입니다. "다른 사람이"할 수 있도록 두지 마십시오.

편집하다

예, 내 요점 # 1이 과장되어 있습니다. 최고의 엔지니어링 애플리케이션 플랫폼조차도 버그를 공유하며 덜 엔지니어링 된 일부 플랫폼은 버그가 있습니다. 그러나 그럼에도 불구하고 항상 코드를 먼저 의심해야하며 코드 에 결함이 없다는 명백한 증거가 있을 때만 컴파일러 / 라이브러리 버그를 비난 해야합니다.

내가 C / C ++ 개발을했던 시절에, 옵티 마이저 "버그"가 언어 스펙에 정의되지 않은 결과가 있다고 말한 일을 한 다른 프로그래머가 나에게 기인 한 것으로 기억합니다. 이것은 Java와 같은 안전한 언어에도 적용됩니다. 예를 들어, Java 메모리 모델 (JLS 17 장)을 자세히 살펴보십시오.

• 다른 사람의 코드를 읽는 방법.
• 버전 관리 시스템에서 코드를 확인하지 않으면 코드가 존재하지 않습니다.

부동 소수점 계산이 정확 하지 않습니다 .

배우는 것을 멈추지 마십시오.

코드의 품질과 유지 관리 성을 향상시키기 위해 할 수있는 첫 번째 일은 중복 제거입니다.

문제 해결 및 디버깅 기술

그들은 내가 선택한 프로그래밍 과정 에서이 주제에 대해 거의 시간을 소비하지 않으며, 내 경험상 프로그래머가 얼마나 생산적인지 결정하는 가장 큰 결정 중 하나입니다. 좋든 싫든, 새로운 개발 단계보다 앱 유지 관리 단계에서 더 많은 시간을 보냅니다.

나는 문제를 찾기위한 전략없이 물건을 무작위로 변경하여 디버깅하는 많은 프로그래머와 함께 일했습니다. 나는이 대화를 수십 번했습니다.

다른 프로그래머 : 문제가 해결되는지 확인해야한다고 생각합니다.
나 : 그래, 그것이 고쳐 진다고 가정하자. 문제의 원인이 어디인지 알려줍니다.
다른 프로그래머 : 잘 모르겠지만, 우리는 무언가 를 시도해야 합니다 .

1. 영리하지 마십시오. 명확하게.
2. 재사용하기 전에 사용하십시오.
3. 이름이 중요합니다.
4. 함수는 1 개의 일을 해 잘 행합니다.
5. 작은 것이 큰 것보다 낫습니다.

기본 사항. 현재 프로그래머들은 개념이 아닌 기술을 배웁니다. 잘못 됐어

모든 프로그래머는 항상 코드에 가정을하고 있다는 것을 알고 있어야합니다. 예를 들어 "이 숫자는 양수이고 유한 할 것입니다", "이 코드는 항상 한 번의 눈 깜박임으로 서버에 연결할 수 있습니다".

그리고 그는 그러한 가정이 깨질 때 대비해야한다는 것을 알아야합니다.

모든 프로그래머는 테스트에 대해 알아야합니다.

개념을 배우십시오 . 구문을 Google에 지정할 수 있습니다.

비판적이고 논리적 사고. 그것 없이는 아무 것도 할 수 없습니다.

단위 테스트. 이것은 코드 사용 방법에 대한 가정을 체계화하는 좋은 방법입니다.

절대 최소의 모든 소프트웨어 개발자는 반드시 유니 코드 및 문자 집합에 대해 알아야합니다 (변명 없음) .

생각보다 어렵습니다.

잘못된 입력, 모든 에지 및 코너 케이스, 가능한 실패 모드 등에 대처할 때 정상적으로 사용될 때 작동하는 것을 조립하는 것이 쉽지는 않지만 시간이 많이 걸리고 아마도 가장 어려운 부분 일 것입니다.

그런 다음 응용 프로그램을보기 좋게 만들어야합니다.

도메인 지식. 사양은 결코 100 %가 아닙니다. 개발중인 실제 도메인을 알면 항상 제품 품질이 향상됩니다.

큰 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

분명히 포인터. :)

코드 완성 2- 커버 투 커버

코드보다 데이터가 더 중요합니다.

똑똑한 데이터라면 코드가 멍청해질 수 있습니다.

바보 코드는 이해하기 쉽습니다. 스마트 데이터도 마찬가지입니다.

내가 가진 거의 모든 알고리즘 적 슬픔은 데이터가 잘못된 위치에 있거나 진정한 의미를 남용했기 때문입니다. 데이터에 의미 가있는 경우 해당 의미를 유형 시스템에 입력하십시오 .

업무에 가장 적합한 언어와 환경 그리고 항상 당신이 가장 좋아하는 것은 아닙니다.

나누고 정복하십시오. 일반적으로 예약에서 디버깅에 이르기까지 모든 유형의 실제 문제를 해결하는 가장 좋은 방법입니다.

진정한 기술은 복잡한 디자인 작업을 전혀 할 수있는 능력이 아니라 단순한 디자인을 잘 실행할 수있는 능력에 반영됩니다.

이 기술은 비전의 숙달이 아니라 기본의 숙달에서 비롯됩니다. 높은 수준의 프로그래머는 다른 사람이 할 수없는 것 (상위 수준의 기능, 고급 기능적 프로그래밍, 사용자가 사용하는 것)을 코딩하는 능력으로 정의되는 것이 아니라 완벽하게 평범한 코딩을 구체화하는 능력으로 정의됩니다. 클래스 간 기능 분해를 적절하게 선택 견고성 구축; 방어 프로그래밍 기술을 사용하는 것; 더 큰 자기 문서화로 이끄는 패턴과 이름을 사용하면 이것들은 높은 수준의 프로그래밍의 빵과 버터입니다.

귀하 또는 다른 사람이 한 달 또는 1 주일에 다시 방문 할 수있는 좋은 코드를 작성하고 해당 코드를 사용, 수정, 향상 또는 확장하는 방법을 이해하는 것이 중요합니다. 시간과 정신적 노력을 절약합니다. 이전에 걸려 넘어 졌던 장애물을 제거하여 생산성의 바퀴에 기름칠을합니다 (아마도 생각을 방해하거나 다른 작업에서 몇 시간 또는 며칠의 노력을들이는 등) 어려운 문제에 집중하기가 더 쉽습니다. 때로는 어려운 문제를 해결하기도합니다.

한마디로 : 우아함. 모든 클래스, 모든 메소드, 모든 조건, 모든 블록, 모든 변수 이름 : 우아함을 추구합니다.

더 깨끗한 사용자 경험이나 더 나은 문서로 해결 될 수있는 것을 사용자에게 비난하지 마십시오. 종종 프로그래머는 문제가 전체적인 경험이 좋지 않거나 의사 소통이 부족할 때 사용자가 올바르게 할 수없는 바보라고 생각합니다. 프로그램은 사용되어야하며 사용자를 멸시하는 것은 처음에는 프로그래밍의 요점을 놓치는 것입니다.

모든 프로그래머는 디버거를 사용하는 방법을 잘 알고 있어야합니다 .

데이터 구조

구글 사용법

단락 평가. 부울 연산자에 대해 가장 먼저 가르치는 것 중 하나입니다.

기능을 구현하는 데 걸리는 시간을 정확하게 추정하는 방법 더 중요한 것은, 견적을 제출할 때 불쾌감을주지 않는 방법입니다.

코딩 스타일 문제 :

• 일관된 들여 쓰기 문제
• 공백 (예 : 운영자 주변) 문제의 일관된 사용
• {} 문제의 일관된 배치,
• 잘 선택된 식별자가 중요합니다.
• 기타

... 좋은 디자인이 중요합니다.

이상적으로 프로그래머는 첫 번째 코드 검토 전 (또는 도중)에 이러한 사항을 학습합니다. 최악의 경우, 사장님이 급히 끔찍한 코드를 사소하게 변경하도록 지시하면 프로그래머가이를 배웁니다.