오래되고 잘못된 프로그래밍 가정

오래되고 잘못된 프로그래밍 가정

---

나는 중학교 (그리고 아마도 선임) 소프트웨어 엔지니어가 만든 일반적인 오류와 잘못된 가정에 대한 연구를하고 있습니다.

당신의 가장 오래된 가정은 결국 수정 되었습니까?

예를 들어 정수의 크기가 표준이 아니며 언어와 대상에 따라 다릅니다. 상태에 조금 당황하지만 거기에 있습니다.

솔직 해지십시오. 당신은 어떤 확고한 믿음을 가지고 있었으며 대략 얼마나 오랫동안 가정을 ​​유지 했습니까? 알고리즘, 언어, 프로그래밍 개념, 테스트 또는 프로그래밍, 프로그래밍 언어 또는 컴퓨터 과학에 관한 다른 것이 될 수 있습니다.

---

오랫동안 나는 다른 모든 사람들이 모든 프로그래밍 개념 (디자인 패턴, 최신 새로운 언어, 계산 복잡성, 람다 식, 당신이 그것을 명명)의 슈퍼 마스터리를 가지고 있다고 가정했습니다.

블로그, 스택 오버플로 및 프로그래밍 서적을 읽으면 항상 모든 프로그래머가 직관적으로 알아야 할 사항에 대해 내가 생각하는 것처럼 보였습니다.

나는 시간이 지남에 따라 내 지식을 단일 개인이 아닌 많은 사람들의 집단 지식과 효과적으로 비교하고 있다는 것을 깨달았습니다. 현실 세계의 대부분의 프로그래머는 자신의 업무를 수행하는 데 필요한 지식을 보유하고 있으며 약하거나 완전히 무지한 영역이 몇 개 이상 있습니다.

---

사람들은 그들이 원하는 것을 알고있었습니다.

내가 사람들과 이야기 할 것이라고 생각한 가장 긴 시간 동안, 그들은 문제 나 작업 흐름을 설명 할 것이고 그것을 코드에 넣고 자동화 할 것입니다. 일어날 때마다 그들이 원하는 것은 실제로 그들이 원하는 것이 아니라는 것이 밝혀졌습니다.

편집 : 나는 대부분의 의견에 동의합니다. 이것은 기술적 답변이 아니며 질문자가 찾고 있던 것이 아닐 수도 있습니다. 프로그래밍에만 적용되지는 않습니다. 나는 그것이 나의 가장 오래 전의 가정이 아니라고 확신하지만, 내가 이것을하고있는 짧은 10 년 동안 내가 배운 가장 놀라운 것입니다. 나는 그것이 순전히 순진한 것이 확실하지만 나의 두뇌가 연결되어있는 방식과 사업 세계에 들어가기 전에 내가했던 가르침과 경험은 내가 대답 한 것을하고 있다고 믿게했다. 사람들의 문제를 해결하기 위해 코드와 컴퓨터를 사용할 수 있다는 것입니다.

이 답변은 프로그래머가 아닌 사람들이 내가 말하는 것에 대해 이해하고 돌보는 것에 대한 Robin의 답변과 비슷하다고 생각합니다. 민첩하고 반복적 인 대화식 프로세스로 비즈니스를 배우는 것입니다. 프로그래밍 코드 원숭이가되는 것과 소프트웨어 개발자가되는 것의 차이점을 배우는 것입니다. 그것은 둘 사이에 차이가 있으며 현장에서 실제로 훌륭하다는 것을 깨닫는 것입니다. 단순한 구문과 타이핑 속도가 아닙니다.

편집 :이 답변은 이제이 답변에 화가 사람들을 달래주는 커뮤니티 위키입니다.

---

성능 문제가 프로파일 링없이 어디에 있는지 알고

---

함수 / 메소드에서 하나의 종료 점이 있어야합니다.

---

프로그래머가 아닌 사람들은 내가 말하는 것을 이해합니다.

---

그 버그없는 소프트웨어가 가능했습니다.

---

해당 개인 멤버 변수는 클래스가 아닌 인스턴스 전용이었습니다.

---

정적 타이핑이 여전히 키보드에 있다고 생각했습니다.

---

개발을 시작하기 전에 문제를 완전히 이해할 수 있습니다.

---

똑똑한 사람들은 항상 나보다 똑똑합니다.

실수를했을 때 스스로를 이길 수 있으며 종종 자멸을 거부한다고합니다. 나는 많은 개발자들을 경외감으로 바라 보았고 종종 X 에서 나보다 더 많은 것을 알았 기 때문에 나보다 더 많이 알고 있다고 생각했습니다 .

계속해서 경험을 쌓고 더 많은 사람들을 만나면서, 종종 그들이 특정 주제에 대해 저보다 더 많은 것을 알고 있지만, 반드시 나 / 당신보다 똑똑 하지는 않다는 것을 깨달았습니다 .

이야기의 교훈 : 식탁에 가져올 수있는 것을 과소 평가하지 마십시오.

---

가장 오랫동안 나는 나쁜 프로그래밍이 프린지에서 일어난 일이라고 생각했다. 올바르게 일을하는 것이 표준이었다. 나는 요즘 너무 순진하지 않다.

---

나는 최대한 추상화로 나아가 야한다고 생각했다. 너무 많은 기능이 서로 얽혀 있기 때문에 이것으로 헤드 메이저를 맞았습니다.

이제는 가능한 한 단순하고 분리 된 상태로 유지하려고합니다. 추상적 인 것을 만들기 위해 리팩토링하는 것은 내가 어떻게 추상해야 하는지를 예측하는 것보다 훨씬 쉽습니다.

따라서 나는 모든 것을 지배하는 프레임 워크를 개발하는 것에서 작업을 수행하는 기능의 스 니펫으로 옮겼다. 내가 순진하게 내가 다음 큰 것을 발전시키는 사람이 될 것이라고 생각했을 때를 제외하고는 뒤돌아 보지 않았습니다.

---

그 여자들은 컴퓨터 프로그래머를 섹시하게 생각합니다 ...

---

소프트웨어의 품질은 더 큰 판매로 이어질 것입니다. 때로는 그렇지는 않지만 항상 그렇지는 않습니다.

---

모든 언어가 (대부분) 동등하게 만들어졌습니다.

오랫동안 선택한 언어가 개발 과정의 어려움과 프로젝트 성공 가능성에 큰 차이를 두지 않는다는 것을 오랫동안 알고있었습니다. 이것은 사실이 아닙니다.

직무에 적합한 언어를 선택하는 것은 다른 단일 프로젝트 결정만큼 중요합니다.

---

주석 / 코드 비율이 크면 좋습니다.

코드가 자체 문서화되어야한다는 것을 깨닫는 데 시간이 걸렸습니다. 물론, 여기에 주석이 있으며 코드를 명확하게 만들 수 없거나 무언가가 수행되는 중요한 이유가있는 경우 도움이됩니다. 그러나 일반적으로 변수의 이름을 바꾸는 데 주석을 쓰는 것이 좋습니다. 더 깨끗하고 명확하며 주석은 코드와 "동기화되지 않습니다".

---

그 프로그래밍은 불가능합니다.

농담이 아니라, 나는 항상 프로그래밍이 배우는 것이 불가능하다고 생각했고 나는 항상 그것을 멀리했습니다. 코드가 가까워지면 이해할 수 없었습니다.

그러던 어느 날 나는 그냥 기초 초보자 튜토리얼을 읽고 거기서부터 일했습니다. 그리고 오늘 저는 프로그래머로 일하고 매 순간마다 사랑합니다.

덧붙여서, 나는 프로그래밍이 쉽지 않다고 생각하고, 도전적이고, 더 배우는 것을 좋아하고 프로그래밍 문제를 해결하는 것보다 더 재미있는 것은 없습니다.

---

"On Error Resume Next"는 일종의 오류 처리였습니다.

---

이 프로그래밍 소프트웨어는 더 높은 수학을위한 강력한 토대가 필요합니다.

코딩을 시작하기 몇 년 전에 저는 항상 좋은 프로그래머가 되려면 고급 대수학, 기하학, 미적분학, 삼각법 등을 잘해야한다고 들었습니다.

10 년 후 저는 8 학년생이 할 수 없었던 일을 한 번만해야했습니다.

---

어셈블리 언어에서 == 다시 쓰기를 최적화합니다.

내가 실제로 어셈블리를 이해했을 때 (BASIC에서 나온) 코드를 더 빨리 실행시키는 유일한 방법은 어셈블리에서 다시 작성하는 것 같았습니다. 컴파일러가 최적화, 특히 분기 예측 등을 가진 CPU에서 매우 잘 할 수 있다는 것을 깨닫기 위해 꽤 많은 시간을 보냈습니다. 인간이 합리적인 시간에 할 수있는 것보다 더 나은 일을 할 수 있습니다. 또한 알고리즘을 최적화하는 데 시간을 투자하면 높은 언어에서 낮은 언어로 변환하는 데 시간을 보내는 것보다 더 나은 결과를 얻을 수 있습니다. 또한 조기 최적화는 모든 악의 근원입니다 ...

---

• 회사 경영진은 코드의 품질에 관심을 갖습니다.
• 줄이 적을수록 좋습니다.

---

날짜의 연도 요소를 2 자리 숫자로 저장하는 것이 전체 세대의 개발자를 괴롭힌 가정이라고 말하고 싶습니다. Y2K 에 날려 간 돈 은 꽤 끔찍했습니다.

---

삽입 / 버블 정렬 이외의 다른 것은 매우 어두운 마법이었습니다.

---

이 XML은 실제로 상호 운용 가능하고 사람이 읽을 수있는 데이터 형식입니다.

---

그 C ++은 다른 모든 언어보다 본질적으로 우수했습니다.

이것은 대학에서 2 년 전에 친구에게서 받았습니다. 나는 창피하게 오랫동안 그것을 지켰다 (지금은 얼굴이 붉어지고있다). 2 년 정도 동안 작업 한 후에야 균열이 무엇인지 알 수 있습니다.

아무도 완벽하지 않으며 항상 개선의 여지가 있습니다.

---

나는 프로그램을 만드는 것이 수업에서 배운 것과 똑같을 것이라고 생각했다. 당신은 사람들과 함께 앉아서 문제를 해결하고 해결책을 찾는 등을 겪었다. 대신 현실 세계는 "여기 내 문제는 해결이 필요합니다. "10 분 후에 다른 솔루션을 얻을 수 있으므로 솔루션을 효율적으로 계획 할 시간이 없습니다.

---

CS 클래스에 도입되었을 때 주류 디자인 패턴 이 훌륭 하다고 생각했습니다 . 나는 그 전에 취미로 약 8 년을 프로그래밍했으며, 좋은 추상화를 만드는 방법에 대한 확실한 이해가 없었습니다.

디자인 패턴은 마술처럼 느껴졌습니다. 정말 깔끔한 일을 할 수 있습니다. 나중에 나는 기능 프로그래밍 (Mozart / Oz, OCaml, 나중에 Scala, Haskell 및 Clojure를 통해)을 발견 한 후, 언어가 충분히 표현되지 않았기 때문에 많은 패턴이 단순한 판금이거나 추가적인 복잡함을 이해했습니다.

물론 거의 항상 어떤 종류의 패턴이 있지만 표현 언어에서는 더 높은 수준에 있습니다. 이제 Java로 전문적인 코딩을 해 왔으며 패턴 일치 및 고차 함수 대신 방문자 또는 명령 패턴과 같은 규칙을 사용해야 할 때 고통을 느낍니다.

---

처음 몇 년 동안 나는 프로그래밍하지 않았지만 1KB는 기술적으로 1000이 아닌 1024 바이트라는 것을 알지 못했습니다. 데이터 파일의 크기가 내가 예상 한 것에서 약간 벗어난 것처럼 보였기 때문에 항상 조금 당황했습니다. 있다.

---

그 상태는 다음과 같이 확인됩니다.

if (condition1 && condition2 && condition3)

지정되지 않은 순서로 수행됩니다 ...

---

혼자서 수행하면 프로그래밍 속도가 빨라지고 향상됩니다.

참고 URL : https://stackoverflow.com/questions/888224/long-held-incorrect-programming-assumptions