왜 일부 프로그래머들은 이론과 실제가 대조적이라고 생각합니까? [닫은]


63

토목 공학과 소프트웨어 공학을 비교할 때, 나는 다른 사고 방식을 관찰하는 것에 놀랐습니다. 모든 토목 기술자는 정원에 작은 오두막을 만들고 싶다면 재료를 얻고 건축하려는 경우 건축을 갈 수 있다는 것을 알고 있습니다 10 층짜리 집 (또는 예를 들어 이와 같은 )은 떨어지지 않도록 상당한 수학을해야합니다.

반대로, 일부 프로그래머들과 이야기하거나 블로그 나 포럼을 읽는 것은 종종 다음과 같이 공식화 될 수있는 광범위한 의견을 발견합니다. 이론과 공식적인 방법은 수학자 / 과학자를위한 것이며, 프로그래밍은 일을하는 것에 관한 것 입니다.

여기에서 일반적으로 암시하는 것은 프로그래밍이 매우 실용적이며 공식적인 방법, 수학, 알고리즘 이론, 깨끗하고 일관된 프로그래밍 언어 등이 흥미로운 주제 일 수 있지만 원하는 모든 것이 물건얻는 것이라면 종종 필요하지 않습니다. 완료 .

내 경험에 따르면, 복잡한 응용 프로그램 (10 층짜리 건물)을 개발하기 위해 100 줄짜리 스크립트 (헛간)를 구성하는 데는 많은 이론이 필요하지 않지만 구조화 된 디자인이 필요하다고 말합니다. -정의 된 메소드, 좋은 프로그래밍 언어, 알고리즘을 찾을 수있는 좋은 교과서 등

따라서 IMO (적절한 양의) 이론일을 완수 하기위한 도구 중 하나입니다 .

내 질문은 왜 일부 프로그래머들은 이론 (공식적인 방법들)과 실천 (일을하는 것) 사이에 대조가 있다고 생각 하는가?

토목 공학 (건물 주택)과 비교할 때 소프트웨어 공학 (건물 소프트웨어)이 많은 사람들에게 쉽게 인식 됩니까?

아니면이 두 분야가 정말 다른가? (미션 크리티컬 소프트웨어를 제외하고 소프트웨어 장애는 건물 장애보다 훨씬 더 수용 가능합니까)?


나는 지금까지 답변에서 이해 한 것을 요약하려고합니다.

  1. 소프트웨어 엔지니어링과 달리 토목 공학에서는 특정 작업에 필요한 이론 (모델링, 디자인)의 양이 훨씬 더 명확합니다.
  2. 이는 토목 공학이 인류만큼 오래되었지만 소프트웨어 공학이 수십 년 동안 만 존재했기 때문입니다.
  3. 또 다른 이유는 소프트웨어가보다 유연한 요구 사항, 더 유연한 요구 사항 (충돌이 허용 될 수 있음), 다른 마케팅 전략 (빠른 시장에 출시하기 위해 좋은 디자인이 희생 될 수 있음) 등의 사실이기 때문입니다.

결과적으로, 일반적인 규칙이없고 소프트웨어 설계에있어 적절한 양의 설계 / 이론이 적절한 지 (너무 적은-> 지저분한 코드, 너무 많음-> 결코 끝낼 수 없음)를 결정하는 것이 훨씬 어렵다 (많은) 경험이 도움이 될 수 있습니다.

따라서 당신의 대답을 올바르게 해석한다면, 얼마나 많은 이론이 필요한지에 대한이 불확실성은 일부 프로그래머들이 이론에 대해 가지고있는 혼합 된 사랑 / 증오심에 기여합니다.


9
아니요, 프로그래머의 90 %가;)
jk입니다.

24
글쎄, 소프트웨어에서 지붕을 짓는 것부터 시작하여 완성 된 부품이 공중에 떠있는 동안 기초까지 내려갈 수 있습니다. 적합하지 않은 경우 덕트 테이프를 사용하여 적합하게 만들 수 있습니다. 스카이 스크래퍼를 만들 때 이것을 시도하십시오. )
안전

65
이론적으로는 이론과 실제에 차이가 없지만 실제로는 있습니다.
Joris Timmermans 2016 년

6
알고리즘을 찾기에 좋은 책? 대부분의 소프트웨어는 알고리즘 과정이나 서적에 포함 된 내용에 가까운 간단한 CRUD입니다.
Gilles 2016 년

44
이론은 현대 언어와 알고리즘에 관한 것입니다. 실습은 첫날 직장에 도착하여 C를 모르는 사람들이 BASIC에서 K & R C로 수동 변환 한 소프트웨어를 사용하는 금전 등록기에서 실행되는 POS 소프트웨어에 사소한 기능을 추가하는 작업을 받고 있습니다. , 파산 한 공급 업체의 버그가있는 컴파일러를 사용하여 금요일에 기능이 작동 할 것으로 예상됩니다.
로봇 고트

답변:


61

가장 큰 차이점은 토목 공학의 경우 실제 물리학은 이론을 제정하고 나쁜 관행을 제한하는 지속적이고 강력한 현실 검사의 역할을하는 반면 소프트웨어 엔지니어링에서는 실용적이 아닌 상아탑 개념을 유지하는 데에도 강력한 힘이 없다는 것입니다. 수줍은 솜씨로.

많은 프로그래머들은 런 어웨이 이론이 일을 완수하는 데 방해가되는 나쁜 경험을 가지고있다 (예 : "실행 가능한 UML", 초 관료 주의적 개발 프로세스). 반대로, 더티 해킹과 패치는 결국 느리게 진행될 수 있습니다. 마지막 단락에서 살펴본 바와 같이, 실패는 일반적으로 최종적이지 않으므로 문제가되지 않습니다.


1
소프트웨어 엔지니어링에서는 적절한 형식의 형식을 갖는 것이 중요하다는 데 동의합니다. 너무 많으면 시작할 수 없으며 실수를 저지른 것을 발견하면 너무 늦었을 수 있습니다. 너무 작다는 것은 엉망이 될 수 있음을 의미합니다. 저는 토목 공학보다 소프트웨어 공학에서 생산성과 품질을 측정하기가 훨씬 어렵다는 점을 지적합니다.
조르지오

2
"... 소프트웨어 엔지니어링에는 실용적이지 않은 강력한 힘이 없습니다 ..." 더 이상 그런 힘 이 없다는 것을 의미 합니다. 과거에는 더 약한 프로세서, 적은 메모리 및 적은 양의 스토리지로 인한 제한이 그러한 힘으로 작용했습니다.
blesh

1
@blesh : 그렇게 생각하지 않습니다. 엄격한 하드웨어 제한은 좋은 엔지니어링과 나쁜 엔지니어링을 동등하게 제한합니다.
Michael Borgwardt 2016 년

귀하의 예는 프로그래밍 이론이 아닙니다. 소프트웨어에 대한 제약은 사용 된 기술과 작가의 수학적 능력과 관련이 있습니다.
Paul Nathan

5
UML에 대해서는 "이론적"이라는 것이 분명히있다.
ObscureRobot 2016 년

29

소프트웨어 공학과 토목 공학은 공통점이 거의 없습니다. 토목 공학 노력은 재료의 물리적 특성과 환경에 의해 제한됩니다. 토목 기사는 토양 특성과 재료 특성에 대해 많은 시간을 소비합니다. 소프트웨어 개발은 ​​프로세서 속도와 사용 가능한 스토리지에 의해서만 물리적으로 제한됩니다. 이 두 가지 모두 이해하기 쉽고 연구에 많은 시간을 소비하지 않습니다. 소프트웨어 개발의 주요 한계는 인간의 지적입니다. 그리고 두 개발자가 비슷하지 않습니다. 이 코드는 유지 관리 가능합니까? 누구에 의해? Haskell에서 퀵 정렬의 3 줄 구현은 분명히 일부는 정확하지만 다른 것은 이해할 수 없습니다. 2 명으로 구성된 팀은 한 달에 신청서를 작성할 수 있으며 10 명으로 구성된 다른 팀은 1 년 안에 제공하기 위해 고군분투합니다.

소프트웨어 개발은 ​​모두 디자인이며, 설계중인 아티팩트는 제조 된 제품보다 훨씬 복잡하며 각각 고유합니다.


1
나는 인적 요소가 소프트웨어에서 훨씬 강하다는 관찰에 동의하지만 여전히 문제를 분석하거나 솔루션을 구조화하는 것이 일반적인 태도 / 도구라고 생각합니다. 내 질문은 일부 프로그래머가 이것이 유용한 접근법 (또는 시간 낭비)이 아니라고 생각하는 이유입니다. Haskell에 대해 언급했습니다. C ++ 또는 Java에서도 더 나은 코드를 작성하는 데 도움이 될 것으로 생각했기 때문에 어떤 프로젝트에서도 사용하지 않았지만 일부 Haskell을 배우려고 노력했습니다. 이 수치를 측정 할 수 없더라도 생산성이 높아졌다는 느낌이 들었습니다. 더 많은 일을 처리합니다.
조르지오

2
3 줄 하스켈 퀵 정렬? 흠 ... 디자인으로 모든 것이 불변 인 언어로 Quicksort를 구현할 있습니까?
메이슨 휠러

3
@MasonWheeler Google의 첫 번째 결과 : Haskell의 Quicksort .
chrisaycock

3
@Mason : 런타임은 여전히 ​​O (n log n)입니다. 또한 재귀를 위해 O (log n) 추가 메모리 만 필요한 in-place quicksort와 달리 O (n log n) 메모리가 필요합니다.
케빈 클라인

2
@kevincline 전형적인 소프트웨어 프로젝트가 독창적 일 정도로 나는 욕실 리모델링에 독특한 프로젝트를 시작했습니다. 차이점은 코드를 망치면 테스트가 빨간색으로 바뀌고 배선을 망치면 집이 타 버린다는 것입니다. 물론 리모델링 문제를 해결 한 경험이 없기 때문에 그 프로젝트는 초과 근무와 예산 초과였습니다. 소프트웨어 프로젝트에서 내가 본 주요 문제는 비슷합니다. 올바른 사람들이 이러한 문제를 더 빨리 해결할 수 없다는 것이 아닙니다. 올바른 사람들을 이용할 수 없으며 우리는 올바른 사람들이되어야합니다. 파리.
철학자

17

다소 토착적이고 정직한 기계 엔지니어 (일부 토목 기술자)가 프로그래머, CS (AI) 박사, 교사, 프로그래머 (예 : 소프트웨어 엔지니어 )를 변명 한 나는 이 일반적인 주제.

전통 공학에서

  • 당신이하는 모든 것이 그것을 기반으로하기 때문에 당신은 당신의 수학과 과학을 알아야합니다
  • 이 분야의 "영웅"은 새로운 것을 발명하고 새로운 아이디어를 발견하며 해결할 수없는 문제를 해결하는 사람들입니다.

소프트웨어에는 정보 물리학에 적용되는 "물리학"이 있지만 소프트웨어 엔지니어는 소프트웨어에 거의 노출되지 않으며 확실히 적용되지 않습니다. 그들이 얻는 가장 이론은 계산 능력과 큰 O입니다.

또한 나는 프로그래밍을 아는 것으로 충분하다고 생각하는 사람들에게 지속적으로 놀랍니다. 그들은 그들의 프로그램에 관한 주제 를 이해할 필요가 없습니다 .

더욱이, 창의성은 장려되지 않습니다. "가독성"으로 위장한 최소 공통 분모 그룹 생각 방법을 선호합니다. (항공 또는 원자력 엔지니어가 후배들에게는 이해하기 어려운 어떤 행동도하지 말라고 격려 받았다고 상상해보십시오.)

웹앱을 프로그래밍하는 방법과 같이 그들이 배우는 것은 큰 가치가 있습니다. 배관공이나 전기 기술자의 기술도 마찬가지이지만 공학은 아닙니다.


5
물리학은 일부 구조물이 자체 하중으로 붕괴되는지 여부를 알려줍니다. CS는 주어진 프로그램이 특정 입력을 멈출 지 여부를 알 수 없다고 알려줍니다. 시스템이 덜 복잡하고 역동적이기 때문에 주로 소프트웨어보다 토목 또는 기계 공학에서 IMO 공식 방법이 훨씬 우수합니다.
Guy Sirton

6
@GuySirton "CS는 주어진 프로그램이 특정 입력에 대해 중단 될지 여부를 알 수 없음을 알려줍니다." 그것이 CS가 생각하는 전부라면, 생각하는 것만 큼 CS에 대해 많이 알지 못할 것입니다.
gregghz

2
여러분, 이전에 아무도 사용하지 않은 소프트웨어 자료를 사용해 본 적이 없을 것입니다. McCarthy는했고 Turing은했지만 실제로는 소프트웨어 엔지니어링이 그렇게 놀라운 것은 아닙니다. 당신이 바로 재부팅 수 있기 때문에 건물이 바다의 바닥에 침몰하는 것이 괜찮다고하면, 소프트웨어 공학 같은 것입니다.
철학자

3
가독성에 대한 균열을 제외하고 +1을 줄 것입니다. 유지 관리 성은 소프트웨어 비용의 80 %이므로 가독성은 작은 문제가 아닙니다. 또한, 그 항공 또는 원자력 엔지니어가 다른 사람들이 그것을 이해하도록 제조 될 무언가를 만들 때 그것이 중요하다는 것을 이해합니다. 군대, 정부 또는 대규모 기관은 발명가 이외의 다른 사람이 복제하거나 이해할 수없는 마술 발명에 만족하지 않습니다.
Thomas

2
@Thomas-실행 가능한 솔루션이 "가독성"을 대체 할 때 종종 무시된다고 주장한다고해서 반드시 솔루션을 읽기 쉬운 수준으로 유지해야하는 것은 아닙니다. 나는 그것이 일어나는 것을 보았다. 지옥, 나는 그것을 스스로 잡았다.
Erik Reppen

13

대부분의 소프트웨어에서 코너를 잘라 내고 최고의 디자인이 아닌 작업을 수행하지만 작업을 완료하면 아무도 죽지 않을 것입니다. 정원의 오두막이 10 층 건물과 동일한 표준을 필요로하지 않는 이유와 같습니다. 그러나 페이스 북과 같은 매우 큰 응용 프로그램을 만들 수 있으며 데이터가 망가져 데이터가 손실되거나 그 밖의 것이 있으면 실제로 그렇게 큰 문제는 아닙니다. 또한 10 층 건물의 기초를 대체하는 것보다 사실 이후에 큰 앱의 기초를 고정하는 것이 더 간단합니다. 그것은 모두 맥락과 위험을 계산합니다.

또한 안전하고 간단하게 앱에 계속 추가 할 수 있습니다. 10 층짜리 건물의 새로운 3 층에 쉽게 던질 수 없습니다 (11 만들기). 원하는 경우 매일 큰 앱에 새로운 기능을 추가 할 수 있습니다.

이제 좋은 디자인으로 프로그래밍이 더욱 쉬워졌습니다. 그러나 디자인이 좋지 않으면 불가능하지 않으며 위험은 소프트웨어입니다. 보통은 죽음이 아닙니다.


글쎄, 당신은 그들이 죽지 않기를 바랍니다 ... 소프트웨어에 따라 다릅니다;)
Rig

3
@Rig, 이것이 내가 '가장 많이'그리고 '보통'이라고 말한 이유입니다. 일부 소프트웨어는 훨씬 더 중요합니다.
CaffGeek

나는이 점점보기의 아주 나쁜 점되고 생각 확인 대부분의 소프트웨어는 안전 의미를 가지고 있지 않지만 이러한 잘못은 또한 법정에서 착륙 할 수지고, 많은 소프트웨어에 관련된 돈과 개인 정보 보호가
JK는.

11

이것에 나와 함께 견딜. 요점이 있습니다.

교수님은 한 번 밤에 종이 쓰기 / 크 래밍 / 프로그래밍을 한 후 대부분의 사람들이 스스로에게“난 다시는 그렇게하지 않을 것입니다. 다음에는 일찍 시작할 것입니다. 빨리 끝내라 " 유능한 미루는 사람으로서의 경험에서, 나는 이것이 사실이라는 것을 알았습니다. 그리고 여기 왜 교수의 설명이 있습니다 : 미루는 경험이 아무리 불쾌하더라도 대부분의 경우 상대적인 성공을 거두었습니다. 이것은 높은 위험 / 보상 행위입니다. 잠시 후, 당신은 모든 불쾌 함을 잊어 버리고 보상 만 기억합니다. 따라서 마지막으로 성공했기 때문에 미루는 다음 유혹은 더욱 유혹적입니다.

우리 모두가 자주 볼 수있는 "일을 끝내라"프로그래밍 기법과 유사하다고 생각합니다. 프로그래머 나 프로그래머 팀, 아마도 무지, 게으름, 또는 시간 제약으로 인해 프로그래밍에 대한 "일을 끝내라"접근 방식을 취하여 모든 이론과 수학 및 모범 사례를 창 밖으로 내 보냅니다. 그리고 당신은 무엇을 알고 있습니까? 그들은 일을 끝냅니다. 우아하거나 예쁘거나 유지 관리 할 수 ​​없지만 작업이 완료됩니다. 아마도 세마포어에서 세미콜론을 모르는 비 기술적 인 상급자는 "일을 끝내는"것에 대해 높은 평가를 줄 것입니다. 따라서 다음 번에 프로그래머가이 느슨하게 프로그래밍에 접근하고 싶은 유혹을 받으면 지난번에는 효과가 없었기 때문에 더 쉬웠습니까? 가난한 사람이 아니라면 "쉬운"방법입니다.

나는 그 가난하고 불행한 영혼이었고 많은 사람들이있을 것입니다. 나는 당신에게 모두를 간청합니다. 쉬운 길을 떠나지 마십시오! :)


3
한 번 끝내고 잊어 버려야한다면 괜찮습니다. 그러나 나중에 확장하고 유지해야하는 경우 문제를 찾고 있습니다. 이론이 얼마나 많은지에 대한 느낌이 필요합니다. 너무 많은 것은 결코 그 일을하지 않을 것이라는 것을 의미하고, 너무 적은 것은 실제로 수행되기 전에 그것을 10 번 할 것이라는 것을 의미합니다. 내 2 센트
조르지오

6
그러나 때때로 당신은 지금 당신의 소프트웨어를 문 밖으로 내 보내야 합니다. 당신은 시장에서 경쟁자를 이길 필요가 있습니다. 또는 일부 정보를 제공해야하는 법적 요건이 있습니다. 또는 현금 흐름을 가져 와서 "완료"접근 방식의 혼란이 문제 일 때에도 여전히 존재합니다. 때로는 좋은 문제입니다. 당신이 그것을 가지고 있지 않은 경우, 당신은 제 시간에 풀리지 않았고 회사는 시작하기 전에 죽었습니다.
CaffGeek

1
@Chad-동의합니다. 균형입니다. 여러분이 언급 한 모든 것은 "완벽한 시간 제약"에 해당되며, 단기간에 프로그래밍을하는 이유로서 단기적으로는 그렇게하는 것이 좋습니다.
FishBasketGordo

@FBG : 훌륭하게 말했다.
Kuba Ober 2016 년

@ 차드, 좋은 지적. Martin Fowler는 martinfowler.com/bliki/TechnicalDebt.html 에서 비슷한 점을 지적 합니다. 때로는 가치있는 트레이드 오프입니다.
John M Gant 2016 년

9

전제에 결함이 있습니다. 토목 기술자가 대형 건물, 교량, 터널 등을 설계 할 때 공학을 사용하는 주된 이유는 필요한 안전 표준을 충족하는 최소량의 재료 (콘크리트, 구조 강철 등)를 사용하도록하기 위해서입니다. 재료 비용과 노동 비용이 목표가 아니지만 일단 건축되면 대개 수정의 여지가 없다면 수학 방식 (예 : 고대 이집트와 마야 문명의 피라미드)없이 많은 고층 건물을 짓는 것이 전적으로 가능합니다 보다 효율적으로 재료를 사용할 수 있습니다.

대형 소프트웨어 시스템을 설계 할 때 약간 다른 역학이 있습니다. 무엇이든, 그것들은 일반적으로 디자인이 부족하지만, 이는 토목 공학 프로젝트로는 쉽게 수행 할 수없는 작업이 진행됨에 따라 디자인이 동적으로 변경 될 수 있기 때문입니다.

일반적인 요인은 비용입니다. 전통적인 토목 공학 프로젝트의 설계는 비용 (실제, 재료 측면 및 책임 측면 모두)을 감소시키는 반면, 소프트웨어 개발에는 설계 비용이 반환 된 가치 이상으로 증가하는 지점이 있습니다.


"설계 비용이 반환 된 가치 이상으로 증가하는 소프트웨어 개발에 대한 요점이있다." 과잉 엔지니어링이 생산성을 향상 시키지는 않는다는 것을 알고 있습니다.
Giorgio 2016 년

실제로 설계를 따르는 초기에 설계된 IMO 프로젝트는 거의 없습니다. 토목 공학은 (일반적으로?) 똑같은 것을 계속 짓고 있습니다 (도로, 망할, 터널, 건물, 다리). 기술은 잘 알려져있다. 소프트웨어에서는 그렇지 않습니다. 쉽게 바꿀 수 있고 사람들이 원하는 것을 알지 못하기 때문에 디자인을 진지하게 시도하기 전까지는 시간 낭비입니다. 우리는 빌드, 테스트 및 반복합니다. 위에서 지적한 바와 같이 토목 공학으로는 불가능한 것. 이 두 분야는 비교할 수 없습니다.
gman

5
미안, 나는 오타를 지적해야한다 : 나는 토목 기술자가 망할 것이라고 생각하지 않는다. ;-)
Giorgio

2
미래에 우리가 소프트웨어 엔지니어가 멋진 토목 공학 시뮬레이션 소프트웨어를 만들 때 토목 기술자 가이 모든 수학 물건을 제거 할 수 있다고 생각합니다. 10km 높이의 가상 초고층 빌딩을 건설하십시오. 처음 100 년 동안 자체 무게로 무너지지 않고 cat 5 가상 허리케인을 견딜 수있는 경우 특수 스카이 스크래퍼 3D 프린터를 사용하여 빌드하십시오.
emory 2016 년

1
@RexKerr : 당신은 절반 그의 문 다진 : "... 필요한 안전 기준을 만족"
거짓말 라이언

7

또한 인류가 이집트인들의 시대 이후로 쉽게 "토목 공학"과 동등한 성과를 거두었다는 몇 가지 다른 훌륭한 반응에 덧붙여서, 우리는 어떻게해야하는지에 대한 일반적인 이론을 완성하기 위해 많은 시간을 보냈습니다. 완료하십시오. 우리는 약 70 년 정도의 기간 동안 소프트웨어를 개발해 왔습니다 (첫 번째 "소프트웨어"로 간주되는 것에 따라 다름). 우리는 같은 종류의 경험을 개발하는 데 같은 시간이 없었 음을 의미합니다.


6

건축가 / 토목 엔지니어의 설계도는 "건축 된"계획과 거의 동일하지 않습니다. 항상 변화가 있습니다. 왜? 항상 "알 수없는 미지"가 존재하기 때문입니다. 당신이 알고 있고 계획 할 수있는 것, 알 수없는 것, 그리고 연구하고 추정 할 수있는 것, 그리고 당신이 모르는 것이 있습니다. "놀람". 당신은 당신이 할 수있는 모든 것을 배움으로써 대부분의 시스템에서 이것들을 제거하는 것을 목표로하지만, 필요한 것은 하나의 작은 빌딩 코드 위반 (건물이 개념화되었을 때 2 년 전에 존재하지 않은 규칙에 기초 할 수 있음)과 당신의 모든 것입니다 -완전한 마스터 플랜은 때로는 상당히 극적으로 변경되어야합니다.

소프트웨어는 이와 매우 비슷합니다. 알려지지 않은 사람은 항상 있습니다. 그러나 토목 또는 구조 공학과 달리 소프트웨어 개발은 ​​기본적으로 알려지지 않은 미지의 문제로 인해 변화에 훨씬 더 관대합니다. 10 층 건물을 건축 할 때 설계에 적용한 기초의 하중지지 용량을 과대 평가했다면 10 층 건물을 건축 할 수 없거나 상당한 양의 작업을 찢어 야합니다. 기초로 돌아가서 강화하거나 재건하십시오. 그러나 소프트웨어에서 전체 솔루션 구조의 특정 계층에 대한 요구를 과소 평가 한 경우 다른 모든 작업을 무효화하지 않는 해당 계층을 수정하기위한 많은 옵션이 있습니다. 단일 DB 서버를보다 강력한 서버 또는 복제 / 장애 조치 클러스터로 교체 할 수 있습니다. 또는로드 밸런싱 / 분산 클러스터. 웹 서버와 동일합니다. 입력 크기에 대한 잘못된 가정을 기반으로 비효율적이지만 간단한 알고리즘을 코딩 한 경우 알고리즘에 대한 지식이있는 다른 코드 (입력 및 호출을 전달)에 영향을주지 않으면 서 비교적 외과적인 방식으로 구현을 거의 항상 제거하고 다시 작성할 수 있습니다. 또는 출력을 기대합니다).

이 비교적 쉬운 변경으로 소프트웨어 엔지니어는 자신이 모르는 것에 대해 과도하게 걱정하지 않고 자신이 알고있는 것에 기초하여 코딩 할 수 있습니다. 이것은 이론과 사전 개념 설계의 laxer 적용을 가능하게한다. 당신은 다이빙을하고 그것을 끝내고, 그리고 당신이 코딩해야 할 것들을 찾는 방법을 따라 변경하고 변경해야합니다. 문제가 발견되면 원인을 식별하고 해결책을 만드는 데 도움이되는 것이기 때문에 개념과 이론을 알아야합니다. 그러나 "분석 마비"에 굴복하지 않고 신속하게 결정을 내릴 수 있습니다. "분석"에 대해 알지 못하거나 고려하지 않은 것을 바탕으로 잘못된 결정을 내린 경우, 실수는 수정하기가 더 쉽습니다.


3
소프트웨어 개발에는 더 많은 미지의 미지의 것들도 있습니다. 초고층 건물을 짓기 시작할 수도 있지만, 고객이 그것을 볼 때 "실제로 저는 10 층 높이의 Rubix 큐브를 원했습니다"라고 말합니다.
Tacroy

@Tacroy : 흥미롭게도 토목 기술자는 아마도 시간과 자원을 낭비하는 나쁜 클라이언트라고 생각할 것입니다. 소프트웨어 엔지니어는 그를 만족시키기 위해 새로운 방법론을 개발하려고 시도 할 것입니다. :-)
Giorgio

1
@Giorgio, 또는 이에 따라 청구서 ...
CaffGeek

5

차이점은 주로 알려진 요구 사항 때문입니다.

  • 이론적으로 모든 것이 사전에 정의되어 있으므로 시작하기 전에 필요한 것을 정확하게 알 수 있습니다.
  • 실제로, 그것들은 종종 모든 것이 아니거나 구현 중 중간에 무언가를 다시 디자인 해야하는 것을 발견합니다. 따라서 최소한 초보적인 디자인을 사용하는 것이 훨씬 낫기 때문에 이러한 문제를 조기에 발견 할 수 있습니다.

또한 "이론"에 관해 이야기 할 때, 이는 일반적으로 소프트웨어 공학이 아니라 컴퓨터 과학의 이론 측면을 의미합니다. 이것은 컴퓨터 과학의 한 부분으로, 더 좋고 효율적인 알고리즘을 찾고 무언가 가능하거나 불가능한지 (예 : P 및 NP) 등을 증명하는 것입니다. 이것들을 당신의 마음 속에 두는 것이 좋지만, 소프트웨어 개발에는 자주 나오지 않습니다.

우리는 가능한 한 그런 종류의 라이브러리를 사용합니다.


1
" '이론"에 대해 이야기 할 때, 일반적으로 컴퓨터 과학의 이론적 측면을 의미합니다.
Joshua Drake

5

실제로 구축중인 소프트웨어에 따라 몇 가지 수준의 소프트웨어 엔지니어링이 있습니다.

NASA는 우주에서 유인 셔틀을 제어 할 수있는 소프트웨어를 필요로하므로 자연스럽게 엔지니어링 프로세스의 수준은 로켓 사진을 보여주기 위해 웹 사이트를 구축하는 것보다 훨씬 엄격합니다.

NASA에서 일한 동료 중 한 명이 이전에 소프트웨어 엔지니어링 프로세스를 한 줄의 코드 작성을 정당화하기 위해 수백 페이지의 정당화와 수백 시간의 회의를 작성하는 것으로 설명했습니다!

내가 이것을 말할 때 무례하게 들리지 않기 때문에 나를 오해하지 마십시오. 그러나 우주 왕복선이 여전히 터져 나간 시간, 자원 및 수십억 달러가 들었습니다.

토목 기사조차도 설계에 이론이 아무리 많이 포함되어 있더라도 결국 설계가 깨질 수 있으므로 비상 계획도 개발해야한다는 것을 알고 있습니다.

소프트웨어를 구축 할 때 충돌 비용으로 인해 생명이 손실되는 경우는 거의 없으므로 물건을 신속하게 버리고 시험 운전하는 것이 훨씬 쉽습니다. 일을 빨리 끝내면 코드가 약하다는 데 동의합시다. 이것이 항상 그렇더라도, 소프트웨어의 실제 작동 상태를 보는 것이 개발자가 소프트웨어의 약점과 강점을 비교할 수있는 것보다 약한 곳과 약한 곳, 그리고 여전히 약한 곳을 확인하는 가장 좋은 방법입니다. 하중.

요약하자면, Premature optimization is the root of all evil 또는 상사가 항상Shipping is a feature!


3
"배송은 기능입니다"+1! 비슷한 문장을 들었을 때 : "완벽한 존재는 없습니다.이 소프트웨어는 존재한다는 장점이 있습니다." 물론 그것은 약간의 농담입니다. 미션 크리티컬 소프트웨어 : 포착되지 않은 예외로 인해 로켓이 충돌 할 수 있습니다.
Giorgio

this software has the advantage that it exists... 나는 아직 그 말을 듣지 못했지만 훌륭한 소프트웨어 인용 목록에 들어가고 있습니다. 나는 그것을 좋아한다
Albert Lang

@Giorgio : JSF와 MISRA C는 예외가 없도록 작성되었습니다. 예외와 로켓은 섞이지 않습니다.
Coder

5

여기에는 많은 좋은 대답이 있지만 컴퓨터 공학과 토목 공학의 비교에는 결함이 있다고 생각합니다.

엄밀히 말하면, 전문 소프트웨어 개발자가하는 일은 컴퓨터 공학보다 소프트웨어 공학과 더 비슷합니다. 더 나은 비유는 컴퓨터 공학이 소프트웨어 공학의 물리학이라는 것입니다. 마찬가지로 Civil Engieering은 실질적으로 물건을 건축하기위한 단순화 및 물리학의 모음입니다.

토목 기사들은 직무를 수행 할 때 일반적인 상대성을 고려할 필요가 거의 없다고 생각합니다. 대부분의 토목 공학은 뉴턴 역학에서 안전하게 구축 할 수 있습니다. 마찬가지로, 이론적 컴퓨터 과학에 대한 대략적인 이해로 소프트웨어 엔지니어링을 매우 성공적으로 수행 할 수 있습니다.

가장 큰 차이점은 교량, 고층 빌딩 및 기타 토목 공학 제품이 합리적으로 잘 이해되어 있다는 것입니다. 소프트웨어 엔지니어는 종종 새로운 구조를 구축하거나 잘 이해 된 것을 구축하기 위해 새로운 방법을 사용합니다. 소프트웨어 엔지니어링은 토목 공학보다 덜 성숙하며, 앞으로도 계속 될 것입니다.

TL; DR : 소프트웨어 엔지니어링의 이론과 실습은 다른 곳과 마찬가지로 다릅니다. 적절한 비유는 소프트웨어 공학 : 토목 공학 :: 컴퓨터 과학 : 물리학입니다. 그러나 실제로는 그보다 약간 더 복잡합니다. :)


"토목 기술자들은 직무를 수행 할 때 일반적인 상대성 이론을 고려할 필요가 거의 없다고 생각합니다. 많은 토목 공학은 뉴턴 역학에 안전하게 구축 될 수 있습니다.": 내가 아는 한, 많은 미적분학 (통합)을 사용해야합니다. 그런 것들). 이것은 양자 역학은 아니지만 IMO는 사소한 것이 아닙니다.
Giorgio

2
물론 브리지의 모든 구성 요소에 대한 파동 방정식을 도출 한 다음 상호 작용 방식을 설명 할 필요는 없습니다.
ObscureRobot 2016 년

네 말이 맞아 그러나 제 요점은 토목 공학에서 소프트웨어 공학에 얼마나 많은 이론이 사용되는지는 아닙니다. 오히려 토목 기사들은 공식을 사용해야하고 건물을 짓는 방법에 대한 계산을해야한다는 것을 알고 있습니다. 소프트웨어 엔지니어링에서는 더 즉흥적 인 느낌이 들며 때로는 앉아서 문제를 분석하고 싶을 때 (정확히 이해하고 박사 학위 논문을 쓰지 않기 위해) 당신은 눈살을 찌푸 릴 수 있습니다. 완벽하게 만들지 않았습니다. 그러나 IMO의 일부 이론 (너무 많지 않음)은 더 빨리 완성하는 데 도움이되는 것입니다!
Giorgio

프로젝트에 적합한 균형점을 찾아야합니다. 주니어 개발자는 일반적으로 무엇을 고집할지 모색하기 위해 쓰레기를 던지는 것에 대해 더 많이 궁호입니다. 그들이 매우 이론적 인 배경에서 온다면, 그들은 더 미쳤고 지나치게 복잡한 아이디어를 가질 수도 있습니다. 주니어 개발자를 효과적으로 관리하려면 종종 한 발 물러나서 작업을 분석하는 것이 좋습니다. 반면, 선임 개발자는 장기적인 설계 문제에 너무 집중하여 즉각적인 요구에 집중하는 데 어려움을 겪을 수 있습니다.
ObscureRobot 2016 년

와우, 죄송합니다. 주제를 벗어난 것이지만 귀하의 답변을 읽지 않으면 TL; DR을 사용하여 정확히 동일하게 종료 한 다음 문자 그대로 동일한 비유를합니다. SAT 형식. 나는 당신을 복사하는 것처럼 보이지 않기 때문에 대답에서 그것을 편집했지만 여전히 나를 놀라게합니다. 아마도 프로그래머들은 너무 많이 생각할 것입니다.
Jarsen

3

그래서 제 질문은 왜 일부 프로그래머들이 이론 (공식적인 방법들)과 실천 (일을하는 것) 사이에 대조가 있다고 생각합니까?

건물 소프트웨어는 다리를 짓는 것과 다릅니다. 소프트웨어에는 처음에 정의되거나 정의되지 않을 수있는 많은 개체가 있습니다. 임의의 수학 공식이나 다른 이상을 준수하지 않고 유지 관리 및 개발자 공동 작업의 편의성을 높이기위한 표준이 존재합니다. 예를 들어, 변수를 기반으로 동작을 선택할 때 스위치를 사용하고 다른 경우에는 공장 패턴을 사용하는 것이 좋습니다. 유지 관리의 용이성과 성능 문제와 같은 식별 된 문제점에 따라 다릅니다.

데이터 조작으로 다른 예를 만들 수 있습니다. .NET의 맥락에서 델리게이트를 사용하는 것이 합리적입니다. Java에서는 .NET의 기능적 프로그래밍 스타일에 대한 프레임 워크 지원이 없기 때문에 그렇게 쉽지 않습니다. 다시 말해, 일반적으로 상황 Y에서 X를 수행하는 것은 불가능합니다. 이는 X와 Y가 N 개의 가변 인자에 의존하기 때문입니다.

토목 공학 (건물 주택)과 비교하여 소프트웨어 공학 (건물 소프트웨어)이 많은 사람들이 쉽게 인식하고 있습니까?

"쉬운"이 올바른 용어인지 잘 모르겠습니다. 확실한 증거가 없으면 아무런 작업도 수행하지 않는다는 인식으로 이어질 수 있습니다. 또는 기존 작업이 쉽게 변경 될 수 있습니다.

아니면이 두 분야가 정말 다른가? (미션 크리티컬 소프트웨어를 제외하고 소프트웨어 장애는 건물 장애보다 훨씬 더 수용 가능합니까)?

기존 엔지니어링과 소프트웨어 엔지니어링은 이미 언급 한 이유로 매우 다릅니다.


1

여기에 당신의 인식이 잘못되었거나 충분히 복잡한 소프트웨어를 작성하지 않은 사람들의 많은 자료가 포함되어 있습니다.

귀하의 경험은 내가 아는 대부분의 사람들 (충분히 복잡한 소프트웨어를 설계하고 작성한 사람)이 말하는 것과 일치합니다.

즉, 대부분의 프로그래머 에게있어 무언가를 작성하는 작업이 그들에게 도달하면 디자인 ( "수학")은 이미 설계자 / 리드 / 등에 의해 수행되었다고합니다. 글을 쓰기 전에 그들에게 다가갑니다. 따라서 최전선 수준에서 그런 식으로 나타날 수 있습니다.


3
"수학 ... 이미 완료되었습니다": 매개 변수를 사용하여 함수를 호출하여 코드에서 사용할 수있는 모든 라이브러리 함수, 프레임 워크, DBMS, 프로토콜 및 기타 많은 무거운 것들을 고려하십시오. 프로그래머 인 저는 때때로 건물을 설계 한 엔지니어보다 비계 위를 걷는 작업자처럼 느껴집니다.
Giorgio

1

이러한 대조의 이유는 소프트웨어 프로젝트와 하드웨어 또는 아키텍처 프로젝트의 수명주기가 다르기 때문이라고 생각합니다. 대부분의 소프트웨어는 점진적으로 진화하므로 처음부터 끝까지 계획되지 않습니다. 소프트웨어 개발자는 개발에 반복적 인 접근 방식을 적용 할 수 있습니다 : 피드백 계획, 구현 및 청취. 피드백이 긍정적이면 계속 진행하지 마십시오. 물러서서 전략을 재고하십시오. 그렇기 때문에 소프트웨어 개발자는 민첩한 개발, 최소한의 실행 가능한 제품 등을 보유하게됩니다.

토목 기사에게는 그런 사치가 없습니다. 그것들을 위해, 일단 무언가가 계획되면, 그러한 변경 비용이 심할 수 있기 때문에 소프트웨어처럼 쉽게 변경할 수 없습니다. 반면 소프트웨어 개발의 경우 비용이 많이 들지 않으며,이를 활용하여 활용할 수 있습니다.

그러나 소프트웨어 개발의 모든 부서가 그러한 접근 방식을 감당할 수있는 것은 아닙니다. 예를 들어 항공 또는 의료 서비스 용 소프트웨어를 만들려면 매우 신중한 계획과 많은 사전 계산이 필요합니다.


1

나도 같은 것 같습니다. 표준 블록, 표준 강도 콘크리트, 표준 강철로 큰 건물을 만듭니다. 표준 라이브러리에서 큰 앱을 빌드합니다.

100 층짜리 건물의 파동 함수를 작성하려고 시도하지 않는 것과 같은 방식으로 큰 응용 프로그램이 수학적으로 공식적으로 입증하려고 시도하지 않습니다.


그렇다면 100 층 건물의 유한 요소 분석에 해당하는 소프트웨어는 무엇입니까? 열 / 충돌에 버그가있는 고층 빌딩은 몇 개입니까? :-)
Guy Sirton

@GuySirton-일반적인 앱을 단위 테스트하는 것보다 세부 사항이 적고 매우 거친 수준의 큰 건물 만 분석 할 수 있습니다. 많은 대형 건물에는 결함이 있고, 창문이 빠지고, 통로가 무너지고, 풍동 효과가 나타납니다. 또는 라스베가스에있는 하나의 굽은 반사율이 높은 호텔의 경우 수영장에서 죽음의 광선을 만듭니다!
Martin Beckett 2016 년

FEA에서 세분화되어 동작을 매우 정확하게 예측할 수 있습니다. 사람들은 여전히 ​​실수를합니다. IMO 복잡한 소프트웨어에 대해 비슷한 예측을하는 것은 불가능합니다. 언급 한 결함은 총 건물 수의 작은 부분입니다. 소프트웨어의 결함률은 2 배 더 높아야합니다. 즉, 공식적인 방법이 유용한 곳과 쓸모없는 곳 사이의 연속체입니다.
Guy Sirton 2016 년

@GuySirton-어려운 점은 다른 것에 의존한다는 것입니다. Nasa는 비행 항공 전자 장치를 OS 및 하드웨어를 생성하기 때문에 매우 상세한 수준으로 테스트 할 수 있습니다 (아직 정확한 것으로 입증되지는 않음). 툴킷과 라이브러리로 일반 OS에서 작성하는 것은 강철이나 콘크리트의 세부 사항을 알 수없는 다리를 만드는 것과 같습니다.
Martin Beckett 2016 년

1
@MartinBeckett, 그리고 중력 계수는 시간이 지남에 따라 무작위로 바뀝니다 ... 시스템 관리자가 "투명하게 될 것"때문에 아무에게도 말하지 않고 서버를 임의로 업그레이드하기로 결정할 때와 같습니다.
CaffGeek

1

나는 약 20 년 전에 나의 적성이 소프트웨어에 있다는 것을 발견하기 전에 기계 및 제조 엔지니어였습니다. 나는 당신이 배치 한 많은 요소들을 동정합니다.

문제의 진정한 본질은 우리가 일을 처리 하는 방법 에 관한 것입니다. 우리는 지금 우리 집단 벨트 아래에서 10 년 정도의 민첩한 발전을 얻었으며 그 메시지는 분명합니다. 레이어별로 진행하지 마십시오. 기능별 진행. 물론-계층별로 진행해야하는 프로젝트가있을 수 있지만 (예 : 웹 서버 전에 네트워크 스택을 구축) 실제 프로젝트의 대부분을 위해 작업 기능을 하나 또는 몇 가지 제공하는 교훈을 배웠습니다. 한 번, 테스트되지 않은 거대한 이론을 구축 한 다음 구현하려고 시도하는 것이 훨씬 더 효과적입니다.

헛의 예를 들어 보자 (일반적으로 스트림 대 1km 길이의 현수교를 가로 질러 통나무를 던져 다리를 만드는 것에 대해 이야기하고 소프트웨어 공학의 세계로 가져 오자). 내가 보는 주된 차이점은 소프트웨어에서 대부분의 작업이 성공하기 위해 큰 선행 모델링이 필요하지 않은 규모라는 것입니다. 초보자의 실수는 종종 실제로하는 것보다 더 많은 것이 필요하다고 가정하는 것이며, 대부분의 경우, 실수를 몇 번 반복 한 경우, 우리는 다시 너무 자주 실수를 저지 릅니다.

논쟁의 여지가 없습니다. 17 명의 소프트웨어 설계자위원회로 시작해야하는 프로젝트가 있습니다. 실제로 그들은 20 캐럿의 다이아몬드만큼 드물다.


1

나는 비유에 결함이 있다고 생각합니다. 내가 아는 한, 토목 공학은 컴퓨터 과학과 같은 종류의 이론적 근거를 가지고 있지 않습니다. 컴퓨터 과학은 튜링 기계와 같은 이론적 수학에서 태어났습니다. 토목 공학은 대자연에 저항하고 어쩌면 아름답게 보이는 구조물을 만드는 것입니다. 다시 한 번, 토목 공학에 대해 많이 알지 못하지만 P 대 NP에 해당하는 토목 기사, 여행하는 세일즈맨 및 두뇌를 박살낼 다른 재미있는 것들이 없다고 생각합니다. 또한 컴퓨터 과학 이론을위한 장소가 있습니다. 누군가가 여행하는 세일즈맨이나 멈춤 문제를 해결하면 우리는 많은 놀라운 발전을 이룰 수 있습니다. 그러나 소프트웨어를 설계하는 소프트웨어 엔지니어의 경우 이러한 문제는 실제로 재미와 게임 일뿐입니다.

또한 저는 그것이 "이론"의 의미에 달려 있다고 생각합니다. 우리는 디자인 패턴을 이야기하고 있습니까? 우수한 소프트웨어 엔지니어가 되려면 디자인 패턴을 제대로 이해하는 것이 매우 중요합니다. 그러나 대규모 소프트웨어 시스템을 설계 할 때 P / NP 문제에 대한 이론을 세우는 것은 유용하지 않습니다. 그런 의미에서 저는 소프트웨어 공학과 이론적 컴퓨터 과학 사이에 뚜렷한 대조가 있다고 생각합니다.

아니면 이론은 알고리즘을 언급합니까? 알고리즘 클래스에서 배운 알고리즘을 작성하는 데 많은 시간을 소비하지 않습니다. 왜? 일반적으로 특정 경우에만 필요하며 (찾아서 조사) 이미 작성된 라이브러리를 사용하기 때문입니다. 다른 베이지안 분류기를 작성할 필요가 없습니다. 추상화는 컴퓨터 과학에서 중요한 원칙입니다. 소프트웨어 엔지니어는 필요할 때까지 알고리즘의 작동 방식을 배우지 않는 경향이 있다고 생각합니다.

또 다른 이유는 현재 효과적인 여러 가지 "완료"소프트웨어 개발 방법이 있기 때문입니다. 예를 들어, 민첩한 개발에서는 사전에 전체 시스템을 설계하지 않습니다. 그 이유는 아직 무엇을 구축하고 있는지 정확히 알지 못하고 있기 때문에 새로운 정보와 요구 사항에 유연하게 적응하기를 원하기 때문입니다. 시작부터 모든 것을 설계 한 다음이를 구현하는 것이 항상 최상의 소프트웨어를 생산하지는 않습니다. 그러나 모든 것에 대한 해결책은 아닙니다. 예를 들어 분산 컴퓨팅 클러스터 클러스터라는 새로운 기능을 설계한다고 가정 해보십시오. 냅킨 스케치를하고 스크럼을 시작할 수 없습니다.

TL; DR. 나는 "이론"이라는 단어와 관련이 있다고 생각합니다. 전통적으로 이론은 컴퓨터 과학의 이론적 인 수학적 측면을 말합니다. 새로운 컴퓨팅 방식을 연구하지 않는 한, 이론적 인 컴퓨터 과학은 대부분 소프트웨어 엔지니어의 일상 생활에서 아무런 역할도하지 않습니다. 소프트웨어 엔지니어는 디자인 패턴 및 시스템 아키텍처를 관리합니다. 특정 알고리즘의 구체적인 구현 세부 사항은 중요하지 않습니다. 덜 복잡한 아이디어로 종종 디자인을 많이하지 않고 코딩을 시작하는 것이 적절합니다. 저는 이것이 프로그래머들이 이론을 좋아하지 않는다는 아이디어의 아이디어라고 생각합니다.


1
나는 우리의 대답 사이에 몇 가지 유사점이 있지만, 당신의 아이디어는 분명히 독창적이며 약간의 차이가 있습니다. P / NP를 이해하는 것이 유용하지 않다는 데 동의하지 않습니다. 복잡성 이론을 깊이 연구 할 필요는 없지만, 작업중인 소프트웨어 엔지니어는 특정 코드 조각의 O (n)를 추정하고 대체 솔루션 비용에 대한 지능적인 말을 할 수 있어야합니다. 당신이 거의했지만하지 않은 요점은 이론이 종종 라이브러리에 캡슐화되어 있다는 것입니다. 그것은 좋은 생각입니다.
ObscureRobot 2016 년

"누군가가 해결하면 ... 우리가 굉장히 많은 새로운 발전을 위해 멈추고있는 문제를 해결할 수 있습니다." 정지 문제를 해결하기 위해 연구 노력이 소비되고 있습니다.
Giorgio

Turing Machines는 "그러나 인간의 상상력으로 생각할 수있는 모든 기계가 교회의 영향을받는 것은 아닙니다.-논문을 다루는 중입니다 ... 장기적으로 실제 결정 론적 물리적 프로세스가있을 수 있는지에 대한 공개적인 질문입니다. 튜링 머신, 특히 이러한 가상 프로세스가 정지 문제를 해결할 수있는 계산 머신 (하이퍼 컴퓨터)의 형태로 유용하게 활용 될 수 있는지 여부 ... 또한 알려지지 않은 물리적 프로세스가 관련되어 있는지 여부는 공개적인 질문입니다. 인간 두뇌의 작용 ... "-Halting Problem, Wikipedia
Jarsen

그래서 내가 아는 한, 내가 틀렸다면 수정하십시오. 우리는 여전히 계산에 관해 많은 발견을해야한다고 생각합니다. 이 글에서 여러 번 언급했듯이 컴퓨터 과학은 여전히 ​​젊습니다. 터닝 머신과 Von Neumann 아키텍쳐를 넘어서는 것이 훨씬 많습니다.
Jarsen

@Jarsen : 컴퓨터 과학은 매우 어리다는 것이 사실이지만, 지금까지 구축 된 모든 컴퓨터는 Turing-computable 일만 할 수 있습니다. 내가 아는 한 (실제로) 양자 컴퓨터조차도 더 많은 것을 할 수 없습니다 (특정 문제를 더 빨리 해결할 수는 있지만 더 많은 문제를 해결할 수는 없습니다). 그렇습니다. 누가 발명 할 수 있는지 알고 있지만 지난 70 년 동안 상상해 온 컴퓨팅 형식은 튜링 머신 그 이상을 할 수 없습니다.
Giorgio

1

현재 이론과 실제의 격차가 너무 큽니다. 이론을 수행 할 때 세 가지 공리가 주어지고 그 결과 한 줄 정리에 수천 페이지의 증거가 있거나 전혀 증거가 없음이 표시됩니다. 소프트웨어 엔지니어링에서는 불특정 한 기능을 구현하는 무수한 (나쁜) 방식을 제공하는 수천 가지 함수의 일관되지 않은 API가 제공됩니다.

실제 소프트웨어 엔지니어링은 공식적인 분야의 사람들을 화나게 할 것이고, 실제 수학 소프트웨어 개발은 ​​엔지니어링 분야의 사람들을 화나게 할 것입니다. 두 분야 모두 서로 다른 적성을 가진 사람들이 필요하며, 적성이 자주 중복되는 것으로 생각하지 않습니다.


0

공식 이론은 제조 된 제품과 같은 모든 것을 사전에 정확하게 계획 할 수 있고 소프트웨어가 동일한 환경 내에 무기한으로 존재하며 일반적인 추상 문제를 해결하는 것이 항상 목표라고 가정합니다. 4D 제품으로서의 소프트웨어 수명주기 (디자인, 개발, 배포, 완료)를 가정합니다. 공식 이론은 분석, 추상화, 일반화 및 미래의 변화 예측을 사용하여 소프트웨어 설계의 문제를 해결하는 것입니다. 이것은 쉽게 분석 가능하고 예측 가능하며 상당히 정적 인 간단한 도메인에서 잘 정의 된 문제가있는 경우에 좋습니다.

실제 프로그래밍은 현재 올바른 방법으로 소프트웨어 문제가 아닌 올바른 문제를 해결하여 동료가 자신의 업무를 더 잘 / 빠르게 / 완전히 수행하거나 수익이 회사에 유입 될 수 있도록하는 것입니다. 많은 소프트웨어는 제품과 같지 않으며 결코 '완료'되지 않고 생물체와 비슷합니다. 하나의 생태 학적 틈새 시장에 대해 고도로 전문화되어 있으며 예상치 못한 새로운 문제를 해결해야하는 다양한 수명이있을 수 있습니다. 끊임없이 변화하는 다양한 환경. 정치와 합법성, 경쟁, 그리고 끊임없이 변화하는 조직, 구조 및 추세와 함께 비즈니스 세계에서 요구 사항은 모호하고, 모든 종류의 특수 사례와 관련이 있고, 잘 정의되지 않으며, 예기치 않은 급격한 변화가 발생할 수 있습니다. 분석, 예측 또는 정적이 아닙니다. 종종 논리적이거나 합리적이지 않습니다. 이 소프트웨어는 2 년 안에 20 년 동안 사용 중일 가능성이 적습니다. 많은 것을 알지 못하거나 많은 것을 할 수없는 세상으로오고, 끊임없이 변화하는 환경과 새로운 문제에 적응할 수 있도록 강력하고 유연하며 성장할 수 있도록 일생 동안 양육, 손질 및 훈련을 받아야합니다. 태어 났을 때 무시하면 오래 살아남아 사소한 고통을 겪고 무딘 힘으로 문제를 해결할 수 있습니다.

공식 이론은 많은 실제 비즈니스 소프트웨어의 요구를 해결하지 못합니다. 소프트웨어를 설계하고 수행 할 수 있다고 믿도록 속입니다. 이 제품은 간헐적으로 고정, 연마 또는 고정이 가능한 제품이지만 일생 동안 지속적으로주의를 기울여 올바로 키워야하는 생물은 아닙니다. 그래서 우리는 정말 못생긴 야생의 레거시 코드로 끝났지 만 공식적인 이론은 아마 도움이되지 않았을 것입니다.

그것은 모두 부정적으로 들리지만 실제로는 공식적인 이론을 사용하는 것을 좋아합니다. 아름다운 디자인은 항상 내 얼굴에 미소를 가져옵니다. 그러나 그것은 주로 비즈니스의 변덕에 종속되지 않는 내 취미 프로그램에 있습니다. 직장에서 나는 대부분 유기 코드를 다루며, 그것이 올바르게 자라게하고, 자랑스러워하고, 그것을 처리해야하는 다른 사람들에게 무례하고 무례하지 않도록 충분히주의를 기울일 수 있기를 바랍니다.


0

스테이크가 적고 작업이 쉬우 며 경영진이 좋은 디자인의 가치를 거의 보지 못합니다. 시스템 불안정성, 유지 관리 성 및 무결성은 "비즈니스"문제가 아니라 "IT"문제입니다. 모든 임원은 공통점이 있습니다. 그들은 돈에 95 % 집중하거나 누군가에게보고합니다.

나머지 전투는 동료 프로그래머와의 싸움입니다. 많은 사람들이 코딩이 시작되기 전에 문제에 대해 생각할 수 없거나 약속하지 않을 것입니다. 위의 이유로 인해 많은 사람들이 선임 개발자이므로 좋은 디자인을 생산하기가 훨씬 어렵습니다.

나는 처음부터 어려운 프로젝트에 임시 기능과 수정 사항을 추가하는 프로젝트 리드 낭비 시간을 본 다음 "너무 복잡하다"또는 "시간 낭비"와 같은 문구로 혼란에 질서를 잡으려는 모든 시도를 중단했습니다. 경영진이 매일 자신의 교도소를 짓는 것을 인정하지 않기 때문에 피할 수없는 운명으로 주요 프로젝트 나선을 보는 것은 즐겁지 않습니다. 그러나 나는 많은 개발자들이 더 좋고 나쁘게 경험하고 배우는 것이 불행한 현실이라고 생각합니다.

나는 일에서 매체를 찾으려고 노력한다. 나는 "오염 된"프로젝트에서 절대적으로 필요한 것보다 더 많은 코드를 작성하지 않으며, 기능을 프로젝트 밖으로 옮길 수있는 모든 기회를 갖 습니다. "프로젝트간에"실제로 제어 할 수있는 프로젝트에서 디자인 및 정리에 시간을 보냅니다.

결국, 세계 프로그래머의 75 %가 위장을 갖지 못한다는 것은 정치와 개인적 충절의 큰 혼란입니다. 간신히 참을 수 있습니다.


0

우선, 나는이 질문을 좋아합니다. 나는 3 개의 1000 개의 단어로 된 답변을 썼고, 내가 그 끝에 도달했을 때 그들은 끔찍하게 틀렸다.

필자가 생각하기에이 두 가지를 비교하려고 할 때의 문제는 프로그래밍이 원하는대로 추상적이고 엄격하게 구체화 될 수있는 모델링 프로세스라는 것이다.

반면에 구조 공학 이론은 여러분이 따라야 할 매우 구체적인 현실 기반 법칙과 밀접한 관련이 있습니다. 문맥이나 법률을 변경할 수는 없습니다. 문제 자체는 그 법에 뿌리를두고 있습니다. 그러나 프로그래밍에서 때로는 솔루션이 실제로 질문의 성격을 바꾸거나 단순히 다른 상황에 놓는 것입니다.

예를 들어 MVC 패턴이 완벽하게 맞는지 여부는 해당 컨텍스트와 관련이 있습니다. 데스크탑 응용 프로그램은 일반적으로 구성 파일을 계산하지 않고 한 언어로만 처리합니다.

반면에 웹 앱의 프런트 엔드는 주로 두 가지 선언적 (비 프로그래밍) 언어와 JavaScript로 구성됩니다. 완전히 추상화 할 수없는 한 가지 물리적 인 점은 서버와 브라우저 사이에 항상 http http 벽이 있다는 사실입니다. 코드에 코드를 저장하는 방법에 관계없이 시간과 비동기 디자인이 필요합니다.

분명히 데스크톱 앱 컨텍스트에서 처리하는 방식을 변경하지 않고 MVC와 같이 널리 사용되는 잘 알려진 패턴을 사용하여 웹의 프런트 엔드 문제를 독점적으로 처리 할 수는 없습니다. 사실, 나는 MVC가 유용한 이유를 알고 있지만 특히 정확하게 또는 도매 방식으로 MVC를 구현하려고 시도하지 않아야한다고 주장해야합니다. 웹 앱 패러다임은 모든 look-at-me 항목이 사용자의 브라우저에 의해 처리되고 모든 데이터 / 모델 관련 항목이 일반적으로 서버 어딘가에 있다는 점에서 독특합니다. 그러나 컨트롤러에서 어디로 떠나나요? 서버 또는 프런트 엔드 모두? 누군가 그것을 소유해야합니다. 또는 MVC가 시나리오에 가장 적합하지 않을 수도 있습니다. .NET 백엔드에 적합하지 않습니다. 특정 UI 위젯의 컨텍스트에서는 끔찍하지 않습니다.

집을 짓는 것은 문제를 해결합니다. 그러나 일반적인 프로그래밍 문제는 종종 문제 내에서 문제를 해결하는 것과 관련이 있으며 때로는 해결책이 외부 문제를 재정의하는 것입니다. 현실은 불행히도 그 아이디어에 특히 열중하지 않습니다.


0

Glenn Vanderburg는 소프트웨어 엔지니어링과 전통적인 엔지니어링 분야의 차이점에 대한 훌륭한 견해를 제시합니다. http://www.youtube.com/watch?v=NP9AIUT9nos

토목 기사가 최종 작업을하기 전에 비용없이 자신의 설계를 테스트 할 수 있다면 이론을 훨씬 덜 활용할 것입니다. 몇 초 안에 그는 파손될 때 테스트 할 수 있도록 수천 번 무료로 다리를 지을 수 있다면 이론적으로 제동 될 때 계산하는 데 몇 개월을 소비하는 대신 그렇게 할 것입니다 ...

소프트웨어 개발에서 그것은 바로 당신이하는 일입니다. 이론적으로 알고리즘의 속도를 계산하는 대신 몇 초 안에 알고리즘을 테스트하고 답을 알 수 있습니다.

실제로 오늘날 대부분의 소프트웨어는 더 이상 컴퓨팅 성능이나 메모리와 같은 물리적 제약으로 인해 제한되지 않습니다. 소프트웨어의 한계는 더 크고 더 큰 시스템의 복잡성입니다. 오늘날 프로그래밍에서 큰 어려움을 겪는 것은 인간이 시스템을 이해할 수 있도록 유지함으로써 이러한 복잡성을 관리합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.