토목 공학과 소프트웨어 공학을 비교할 때, 나는 다른 사고 방식을 관찰하는 것에 놀랐습니다. 모든 토목 기술자는 정원에 작은 오두막을 만들고 싶다면 재료를 얻고 건축하려는 경우 건축을 갈 수 있다는 것을 알고 있습니다 10 층짜리 집 (또는 예를 들어 이와 같은 것 )은 떨어지지 않도록 상당한 수학을해야합니다.
반대로, 일부 프로그래머들과 이야기하거나 블로그 나 포럼을 읽는 것은 종종 다음과 같이 공식화 될 수있는 광범위한 의견을 발견합니다. 이론과 공식적인 방법은 수학자 / 과학자를위한 것이며, 프로그래밍은 일을하는 것에 관한 것 입니다.
여기에서 일반적으로 암시하는 것은 프로그래밍이 매우 실용적이며 공식적인 방법, 수학, 알고리즘 이론, 깨끗하고 일관된 프로그래밍 언어 등이 흥미로운 주제 일 수 있지만 원하는 모든 것이 물건 을 얻는 것이라면 종종 필요하지 않습니다. 완료 .
내 경험에 따르면, 복잡한 응용 프로그램 (10 층짜리 건물)을 개발하기 위해 100 줄짜리 스크립트 (헛간)를 구성하는 데는 많은 이론이 필요하지 않지만 구조화 된 디자인이 필요하다고 말합니다. -정의 된 메소드, 좋은 프로그래밍 언어, 알고리즘을 찾을 수있는 좋은 교과서 등
따라서 IMO (적절한 양의) 이론 은 일을 완수 하기위한 도구 중 하나입니다 .
내 질문은 왜 일부 프로그래머들은 이론 (공식적인 방법들)과 실천 (일을하는 것) 사이에 대조가 있다고 생각 하는가?
토목 공학 (건물 주택)과 비교할 때 소프트웨어 공학 (건물 소프트웨어)이 많은 사람들에게 쉽게 인식 됩니까?
아니면이 두 분야가 정말 다른가? (미션 크리티컬 소프트웨어를 제외하고 소프트웨어 장애는 건물 장애보다 훨씬 더 수용 가능합니까)?
나는 지금까지 답변에서 이해 한 것을 요약하려고합니다.
- 소프트웨어 엔지니어링과 달리 토목 공학에서는 특정 작업에 필요한 이론 (모델링, 디자인)의 양이 훨씬 더 명확합니다.
- 이는 토목 공학이 인류만큼 오래되었지만 소프트웨어 공학이 수십 년 동안 만 존재했기 때문입니다.
- 또 다른 이유는 소프트웨어가보다 유연한 요구 사항, 더 유연한 요구 사항 (충돌이 허용 될 수 있음), 다른 마케팅 전략 (빠른 시장에 출시하기 위해 좋은 디자인이 희생 될 수 있음) 등의 사실이기 때문입니다.
결과적으로, 일반적인 규칙이없고 소프트웨어 설계에있어 적절한 양의 설계 / 이론이 적절한 지 (너무 적은-> 지저분한 코드, 너무 많음-> 결코 끝낼 수 없음)를 결정하는 것이 훨씬 어렵다 (많은) 경험이 도움이 될 수 있습니다.
따라서 당신의 대답을 올바르게 해석한다면, 얼마나 많은 이론이 필요한지에 대한이 불확실성은 일부 프로그래머들이 이론에 대해 가지고있는 혼합 된 사랑 / 증오심에 기여합니다.