지속적으로 수정하지 않아도되는 소프트웨어를 작성할 수 있습니까?


23

여러 언어로 많은 소프트웨어를 작성했으며 Verilog 및 VHDL을 사용하여 FPGA와 함께 사용할 하드웨어를 "작성"했습니다.

저는 소프트웨어보다 하드웨어를 작성하는 것을 좋아하는 경향이 있으며, 주된 이유 중 하나는 "완료"된 하드웨어를 작성할 수 있고 수정할 필요가 없다는 것입니다. 인터페이스와 기능을 정의하고 테스트 벤치를 작성합니다. 하드웨어 모듈을 구현 한 다음 시뮬레이터를 사용하여 하드웨어 모듈을 테스트하십시오. 그런 다음 해당 하드웨어 모듈을 빌딩 블록으로 사용하여 더 크고 더 나은 것을 만들 수 있습니다. 해당 모듈에 기능을 추가해야하는 경우 두 번째 모듈을 작성하고 기능을 추가하십시오. 원래 모듈은 제대로 작동하고 여전히 유용 할 수 있으므로 절대 버리지 마십시오.

소프트웨어에 대한 나의 주요 좌절 중 하나는 결코 "완료"되지 않았다는 것입니다. 추가해야 할 다른 기능이 항상 있습니다. 기능을 추가 할 때 종종 이전에는 제대로 작동하던 버그가 발생합니다. 인터페이스를 위반하지 않는 한 하드웨어에서는 발생하지 않습니다.

분명히하기 위해, 기능 목록이있는 버전의 무언가를 만드는 것을 옹호하지는 않으며 영원히 있습니다. 시간이 지남에 따라 반복 및 여러 릴리스를 선호하여 새로운 기능을 추가하고 있습니다. 왼쪽 코드를 찌르고 오른쪽 버그를 발견하고 싶지 않으며 새로운 기능을 추가 한 후 발생하는 것으로 보입니다.

하드웨어가 "쓰기"되는 것과 유사한 방식으로 소프트웨어를 작성할 수 있습니까? 항상 진보를 이룰 수 있고 기존 코드를 다시 작성하지 않고 새로운 버그를 도입하지 않고도 새로운 기능을 추가 할 수있는 좋은 소프트웨어 개발 방법이 있습니까?



이 공개 원칙은 훌륭해 보입니다! 누구든지 이것을 성공적으로 사용 했습니까?
Nathan Farrington

2
@NathanFarrington : 대부분의 디자인 패턴 ( GOF에 설명 )은 OCP를 따릅니다 . 한 가지 예는 Template Method Pattern 입니다.
Spoike

2
@NathanFarrington 개방형 원칙은 소프트웨어 개발자가 소프트웨어를 설계 할 때 사용하는 일반적인 원칙입니다.
Jesper

1
오늘날 우리가 사용하는 많은 프로그램이 20 년 전에 작성된 코드의 카본 카피 인 비트와 조각을 사용하여 만들어 졌다고 생각합니다.
Mallow

답변:


16

하드웨어와 같이 잘 정의 된 인터페이스 및 테스트와 관련이 있습니까?

정확히 내 생각이야!

명확한 인터페이스를 갖춘 잘 설계된 모듈은 본질적으로 완벽한 경향이 있습니다. StringJava 클래스 와 같은 것을 생각하십시오 . 그것은 컴퓨터 프로그램이지만 명백한 인터페이스를 가지고 있습니다. 알려진 버그가 없습니다. 그것은해야 할 일을 완벽하게 수행합니다. 물론, 그것은 지난 15 년 동안 광범위하게 테스트되었으며, 거의 모든 프로그램이 String기본 빌딩 블록으로 s를 사용하기 때문에 버그가 발견 될 것입니다. 모든 "질투"(버그)는 아니지만 여기에 설명 된 것과 같이 알아야 할 디자인 세부 사항 은 http://www.jwz.org/doc/java.html에 설명 되어 있습니다. 계정.

버기 소프트웨어는 부분적으로 문화적인 문제입니다. 사람들은 소프트웨어를 버기하는 데 익숙하며 하드웨어와 달리 소프트웨어는 일반적으로 나중에 쉽게 고칠 수 있으므로 처음에는 완벽하게 할 필요가 없습니다. 다음 버전에서). 그러나 지난 50 년 동안 소프트웨어의 복잡성이 꾸준히 증가하고 있지만 인간의 두뇌는 동일합니다. 완벽을 달성하기가 점점 더 어려워지고 나중에 물건을 고치는 것이 쉬워지는 것 (빠른 자동 빌드, 인터넷 배포)이 일정 압박과 징계 부족과 결합 할 때 결과는 그 결과입니다.

항상 진보를 이룰 수 있고 기존 코드를 다시 작성하지 않고 새로운 버그를 도입하지 않고도 새로운 기능을 추가 할 수있는 좋은 소프트웨어 개발 방법이 있습니까?

은 총알은 없지만 다음과 같은 모범 사례의 좋은 조합 :

  • 단순하고 자율적 인 모듈. 즉, 낮은 결합 및 높은 응집력.
  • 불변성. 동시성이 증가함에 따라 특히 중요합니다.

두 지점이 복잡성을 줄이는 것을 목표로한다는 점은 주목할 가치가 있습니다. 이것이 핵심입니다. 엔트로피는 항상 증가하는 경향이 있으며, 우리가 싸우지 않으면 곧 복잡해질 것입니다. 또한 지난 몇 년 동안 프로그래밍 언어가 위에서 언급 한 관행을 장려하거나 심지어 시행하도록 발전해 왔다는 점도 흥미 롭습니다. 특히 함수형 언어의 부상은 다음과 같습니다. 순수한 함수는 항상 동일한 입력에 대해 동일한 값을 반환하며 상태 는 없습니다 . 그런 다음 불변 값 을 가져 와서 반환 하는 순수한 함수를 작성 하고 피할 수없는 가변성을 작고 잘 정의 된 작은 곳으로 제한하지 않고 제한합니다. 이것을 확인하십시오 : http://clojure.org/state


1
- jwz 꽤 String 클래스는 bugfree 점에 동의하지 않습니다 jwz.org/doc/java.html

1
디자인 된대로 작동 할 수 있으므로 기본 디자인이 손상된 경우 문제가됩니다. 그러나 String은 매우 안정적인 클래스라는 데 동의합니다.

1
훌륭한 답변입니다. 이제 거의 독점적으로 Python으로 코딩하고 함수형 프로그래밍 구조를 활용하려고합니다. 네, 불변성이 핵심이라고 생각합니다. 소프트웨어 모듈을 처음 만들 때 테스트하더라도 인터페이스를 엉망으로 만들었거나 책임이 잘못되었거나 너무 많을 수 있습니다. 그래서 두 번째 모듈을 만들고 첫 번째 모듈을 그대로 둡니다! 원하는 경우 나중에 첫 번째 모듈을 계속 사용할 수는 있지만 절대로 변경하지 마십시오. 완벽하지는 않지만 작동합니다. 따라서 불변성을 가진 기능적 언어는 제안하는 데 도움이 될 수 있습니다.
Nathan Farrington

1
@JoonasPulakka : 네, 한 줄의 소프트웨어 요약이 있다면, "항상 다른 버그가있을 수 있습니다". :-) 그리고 나는 그것이 Nathan의 요점 중 하나라고 생각합니다.
로스 패터슨

1
Joonas, 이겼어 클로저를 배우기 시작했습니다. 프로그래밍을 다시 재미있게 만드는 가장 좋은 방법처럼 보입니다.
Nathan Farrington

9

차이점은 하드웨어에 비해 소프트웨어를 수정하는 것이 얼마나 쉽고 저렴하다는 것입니다. 하드웨어를 쉽고 저렴하게 수정하여 고객에게 배송 할 수 있다면 하드웨어는 그럴 것입니다.

제대로 표현되지 않은 질문을 요약하면 "작업 코드에 버그를 도입하지 않고 항상 발전시켜 나가는 방법으로 소프트웨어를 더 재미있게 작성할 수 있을까요?"라고 생각합니다. 하드웨어와 같이 잘 정의 된 인터페이스 및 테스트와 관련이 있습니까?

테스트 중심 개발을 반드시 확인해야합니다 .


내 질문에 대한 많은 답변에는 민속이 포함되어있는 것 같습니다. 처음부터 버그를 설계하는 것보다 소프트웨어 버그를 찾아 수정하는 것이 더 쉬운가요? 소프트웨어를 수정하는 데 실제로 비용이 얼마나 듭니까? 아마 아무도 모른다. 테스트 중심 개발과 관련하여 재사용 할 수있는 소프트웨어를 테스트하는 것이 좋습니다. 그런 다음 소프트웨어는 진흙 공이 아니라 실제 빌딩 블록이됩니다. 그러나 내일 변경 될 소프트웨어를 테스트하는 것은 이치에 맞지 않습니다. 실제로 진흙보다는 빌딩 블록에서 소프트웨어를 만들 수 있는지 궁금합니다.
Nathan Farrington

1
@NathanFarrington : 하드웨어 / 소프트웨어 사양과 디자인을 만드는 방법에 큰 차이가 있다고 생각합니다. 대부분의 하드웨어 제조업체는 클라이언트가 "이 작업을 수행하는 프로그램을 원합니다!"라고 말할 수있는 소프트웨어 개발자보다 자신이 만든 것에 대해 더 나은 사양을 가지고있을 것입니다. 새로운 기능과 그렇지 않은 기능은 거의 보장됩니다.
RCE

변경 사항이 많은 경우 물론 일부 테스트도 변경해야 할 수도 있지만 소프트웨어가 워드 프로세서에서 웹 서버로 변경되는 것은 아닙니다. "새 문서"기능은 여전히 ​​새 기능을 작성하며 테스트는 여전히 유효합니다.
RCE

또 다른 주요 원칙을 지적했습니다. 사양이 좋을수록 변경이 덜 필요합니다. 그러나 이것은 소프트웨어와 마찬가지로 하드웨어에 기능을 추가하기 전에 하드웨어에 기능을 추가 할 수 있기 때문에 내 질문에서 정확히 얻은 것이 아닙니다. 나는 OCP가 진정한 대답이라고 생각합니다. 슬프게도 그것은 주석이므로 답변으로 표시 할 수 없습니다. 또 다른 요점은 항상 진전을 이루는 것이 었으며 TDD가 회귀 테스트를 제공하여이를 도울 수 있다고 생각합니다.
Nathan Farrington

소프트웨어 변경은 하드웨어보다 쉽고 저렴 해 보이지만 실제로는 그렇게됩니까? 그렇습니다, 나는 갈 수 있고 손가락으로 밀어서 즉시 새로운 빌드를 만들 수 있습니다. 그러나 빌드는 여전히 유효성 검사 / QA를 거쳐야합니다. 기회 비용은 얼마입니까? 이 버그를 수정하는 대신 무엇을했을까요? QA가 소프트웨어를 다시 검증 할 필요가 없었던 것은 QA가하고 있었던 것입니다. 이 수정 프로그램을 출시하기 위해 다른 프로젝트를 추진 했습니까? 사람들이 생각하지 않는 "숨겨진"비용이 많이 있습니다. 더 쉬울 수도 있지만 반드시 덜 비쌀 필요는 없습니다.
Pemdas 2019 년

6

나는 당신이이 의견들로부터 답을 얻기를 희망하면서 여러분의 의견에 대해 언급 할 것입니다.

소프트웨어에 대한 나의 주요 좌절 중 하나는 결코 "완료"되지 않았다는 것입니다.

솔루션 사양이 불완전하거나 향상된 기능을 제공 할 계획이 정확하지 않기 때문입니다. 이것은 모든 프로젝트 소프트웨어, 하드웨어 또는 기타에서 발생할 수 있습니다.

항상 진보를 이룰 수 있고 기존 코드를 다시 작성하지 않고 새로운 버그를 도입하지 않고도 새로운 기능을 추가 할 수있는 좋은 소프트웨어 개발 방법이 있습니까?

물론 독립 모듈을 만들면 종속성이 크게 줄어들어야합니다. 소프트웨어를 설계 할 때이 점을 고려해야합니다. 고려 사항, 계층, 계층, 컨트롤러 개체, 인터페이스 등의 분리를 고려해야합니다.

"작업 코드에 버그를 도입하지 않고 항상 발전시켜 소프트웨어를 더 재미있게 작성할 수있는 방법은 무엇입니까?"

1-요구 사항을주의 깊게 이해하십시오. 디자인하기 전에 요구 사항을 닫는 것을 고려해야 할 수도 있습니다. 반복 개발을 수행하면이 작업을 수행 할 가능성이 없습니다. 일부 방법론은 이것을 권장하지만 개인적으로는 이것이 모든 프로젝트 유형에 적합하지 않다고 생각합니다. 견고한 요구 사항에 맞게 소프트웨어를 구축하면 더 나은 디자인이 가능합니다.

2-이 긴 철학을 이해하도록하십시오.

신중하게 3 계획 구현

코드 전 4- 디자인.

5 적절한 경우 일반적인 디자인을 사용하십시오.

6- 디자인 확인 도구로 프로토 타입을 사용하십시오.


이것들은 모두 훌륭한 조언입니다. (1) BIG DEAL을 릴리스하고 릴리스 전에 많은 테스트와 QA를 수행하고, (2) 모듈을 BIG DEAL로 만들고, 해당 인터페이스에 대한 테스트와 함께 잘 정의 된 문서화 된 인터페이스가 있는지 확인하십시오. 인터페이스 및 어설 션은 인터페이스가 위반되었는지 확인하고 모듈이 "릴리스"되면 수정되지 않습니다 (OCP).
Nathan Farrington

4

사람들이 보통 지적하기가 매우 빠르기 때문에 소프트웨어의 장점 중 하나는 하드웨어에 비해 변경하기가 쉽고 비교적 저렴하다는 것입니다. 이것은 근본적으로 잘못되었다는 것을 늦게 깨달을 때 특히 중요합니다. 하드웨어와 마찬가지로 백만 달러를 잃어버린 것처럼 시뮬레이터 등을 사용하고 bazinga를 테스트합니다. 이것은 소프트웨어로 전환 할 때 패러다임이 다소 실패하는 곳이라고 생각합니다.

평범한 소프트웨어 개발자의 머리에 들어가십시오. 당신이 가진 것은 엄청나게 마감 시간이 매우 바쁜 사람입니다. 그의 관리자는 나중에 언제든지 수정할 수 있기 때문에 몇 가지 버그를 남겨두면된다고 말합니다. 테스트는 종종 사후 검토이지만 테스트 중심 시나리오에서도 테스트는 최소로 유지되고 코드는 최소 테스트로 작성되며, 많은 경계 사례를 놓칠 수 있도록 바로 가기가 수행되는 경우가 많습니다. 시스템은 철저히 단위 테스트를 거칠 수 있지만 전체적으로 엄격한 테스트는 거의 없으며 스트레스 테스트는 거의 없습니다. 여기에는 소프트웨어를 처음부터 작성하는 것이 더해지며, 소프트웨어를 작성하기 전에 소프트웨어를 시뮬레이트 할 기회가 거의 없습니다. 주로 하드웨어에서 발견되는 것과 같은 세밀한 빌딩 블록에서 소프트웨어를 거의 작성하지 않기 때문입니다.

OP의 질문으로 돌아갑니다. 모든 소프트웨어를 파생시키는 빌딩 블록 시스템을 정의 할 수 있습니까? 혹시. 매우 비용 효율적입니까? 아마도 이상적인 것은 아닙니다. 당신이이 이상 을지지 할 수있을만큼 충분한 구성 요소, 테스트 및 기타 도구 시스템을 개발할 때프로그래밍 시스템을 사용하면 경쟁자가 이미 시장에 진출했을 것입니다. 심지어 일반 프로그래머의 관점에서 볼 때 "쿠키 커터"스타일의 프로그래밍 시스템은 매우 제한적이며 가능성이 매우 높습니다. 지루한. 나는 개인적으로 API를 개발하고 있는데, 대부분의 모듈 코드가 완전히 정제되고 완전히 표준화되어 이제 코드 템플릿을 생성하고 공백을 채울 뿐이다. 대부분의 시간은 간단한 커넥터 코드를 작성하고 모듈을 최대한 빨리 꺼내는 데 소비 할 수 있습니다. 진지하게 정신을 빼앗기고 있습니다. 같은 종류의 코드를 반복해서 코딩하는 것 이상을 수행 할 수있는 기회는 거의 없기 때문에 다른 프로젝트 기회가 다가 오면 다른 어떤 것도 할 수있는 기회를 얻습니다.

그렇다면 어떻게 고품질의 소프트웨어를 제공 할 수 있습니까? 나는 이것이 당신이 선택한 도구와 방법론에 달려 있다고 생각합니다. 나에게 대답은 좋은 BDD API를 사용하는 것이 었습니다. 읽기 쉽고 매우 세분화 된 코드를 만들 수 있었기 때문입니다. 재사용 가능한 최소한의 방법으로 테스트 모음을 작성하고 사양 언어로 테스트를 설명 할 수 있습니다. 이런 식으로, 나는 빌딩 블록을 설계하고 점검하는 책임을 제외하고는보다 구성 요소 화 된 개발 방식에 가까워졌습니다. 또한 테스트 출력은 실패가 발생한 테스트의 정확한 부분을 정확하게 나타내므로 실패가 설정에 있는지 또는 어설 션에 있는지 추측 할 필요가 없습니다.

방법론 조정도 도움이됩니다. 저는 린 개발 원칙을 적용하고 애자일 운동이 몇 년 동안 시작된 많은 다른 기술 및 원칙과 결합하는 데 큰 옹호자입니다. 내가 좌절감을 느끼는 데 사용했던 많은 낭비적인 관행을 제거함으로써 개발을보다 즐거운 활동으로 만드는 데 큰 도움이되었습니다. 나는 때때로 코드에 버그가 나타날 때가 있지만 때로는 버그가 자주 발생하는 문제가 남아 있지만 이제는 더 많은 시간을 보내고 더 강력한 테스트를 작성하는 데 더 많은 시간을 투자하고 100을 목표로하는 인센티브를 얻습니다. % 테스트 범위. 더 좋은 점은, 하루가 끝날 때 모든 녹색 표시등이 나타나는 것을 보는 것이 정말 기분이 좋고,


궁금한 점은 테스트가 중요하지만 마음을 사로 잡는다는 점입니다.
Nathan Farrington

@NathanFarrington 지적 해 주셔서 감사합니다. 내 요점은 테스트에 대해 긍정적으로 이야기하는 것이었지만 다른 것을 입력하는 동안 그것에 대해 생각하고 있었으므로 그 단락에서 완전히 잘못되었습니다! 조명하려고하는 실제 지점에 맞게 수정했습니다!
S.Robins 2012 년

3

소프트웨어에 대한 나의 주요 좌절 중 하나는 결코 "완료"되지 않았다는 것입니다. 추가해야 할 다른 기능이 항상 있습니다.

그것이 당신을 좌절시키는 경우, 다른 직업을 고려하십시오. 진심으로.

소프트웨어 의 요점 은 기능을 추가 할 수있는 것입니다. "소프트웨어"를 처음 발명 한 이유는 기능을 추가 할 수 있기 때문입니다.

기능을 추가 할 때 종종 이전에는 제대로 작동하던 버그가 발생합니다.

품질 관리 문제입니다.

인터페이스를 위반하지 않는 한 하드웨어에서는 발생하지 않습니다.

소프트웨어에서도 마찬가지입니다.

항상 진보를 이룰 수 있고 기존 코드를 다시 작성하지 않고 새로운 버그를 도입하지 않고도 새로운 기능을 추가 할 수있는 좋은 소프트웨어 개발 방법이 있습니까?

예. 실제로 품질 보증을 연습해야합니다.


1
나는 트롤을 시도하지 않고 있으며, 아마도 소프트웨어를 사용하지 않을 수도 있습니다. 그러나 "소프트웨어의 핵심은 기능을 추가 할 수있는 것"이라고 말합니다. 진짜야? 폰 노이만 (Von Neumann)은 논리 및 산술 단위를 재배 선하지 않고도 하나 이상의 수학 함수를 계산할 수있는 컴퓨터를 구축 할 수있는 소프트웨어를 발명했습니다. 이 소프트웨어 기능 철학이 어디에서 왔는지 궁금합니다. 하드웨어에는 기능이 있지만 하드웨어의 목적은 기능을 추가하는 것이 아닙니다.
Nathan Farrington

품질 보증에서는 테스트를 의미한다고 가정합니다. 예, 제 직감에 따르면 우수한 소프트웨어를 생산하려면 광범위한 테스트가 필요합니다. 그러나 나는 그것이 그것을 넘어서는 것이라고 생각합니다. 하드웨어에서 모듈에 버그가있을 수 있습니다. 그러나 새 하드웨어를 추가 할 때 기존 하드웨어 모듈에 새 버그가 발생하지 않습니다. 결국 모든 모듈의 모든 버그를 찾아서 수정할 수 있습니다. 그러나 소프트웨어에서 종종 코드가 추가되지 않고 변경 (모듈이 변경됨)되어 버그가 발생할 수 있습니다. 나는 순전히 부가적인 소프트웨어 개발 방법론을 찾고 있었다고 생각합니다.
Nathan Farrington

나는 당신의 대답에 대해 더 현명한 의견을 가지고 있습니다. 소프트웨어가 "완료"되지 않은 이유는 아마도 릴리스에 대해 매우 난해한 접근법을 사용했기 때문일 것입니다. 새로운 기능 중 하나는 회귀 테스트가없고 QA가 거의없는 다음 릴리스와 같습니다. 만약 출시가 큰 거래 였다면 나는 결코 수행되지 않은 소프트웨어에 대한 내 생각이 사라질 것이라고 확신했다.
Nathan Farrington 2012 년

@NathanFarrington : Turing은 끊임없이 변화하는 Enigma 코드를 깰 수있는 소프트웨어를 발명했습니다. "품질 보증에 따르면 테스트를 의미합니다". 그릇된. 품질 보증을 의미합니다. 개발의 모든 측면에는 충족되어야하는 품질 표준이 있어야합니다. 테스트는 한 종류의 아티팩트의 품질을 평가하는 한 가지 (제한적) 방법입니다. "버그가 발생할 수있는 코드가 변경되었습니다." 옳은. 이는 소프트웨어의 고유 기능이 아니라 품질 보증의 실패입니다.
S.Lott

우리는 분명히 주제를 벗어납니다. 이 링크 에 따르면 Turing 's Colossus는 범용 적이 아니고 (컴퓨팅 의미에서) 저장된 프로그램 (소프트웨어)을 사용하지 않았습니다.
Nathan Farrington

2

하드웨어가 "쓰기"되는 것과 유사한 방식으로 소프트웨어를 작성할 수 있습니까? 항상 진보를 이룰 수 있고 기존 코드를 다시 작성하지 않고 새로운 버그를 도입하지 않고도 새로운 기능을 추가 할 수있는 좋은 소프트웨어 개발 방법이 있습니까?

디자인과 소프트웨어의 정확성을 확인하기 위해 " 정식적인 방법 "을 살펴 보는 것이 좋습니다 . 하드웨어 설계에 사용하는 시뮬레이터 도구가 밀접한 일을하려고합니다. 공식적인 방법이 어디 가까운이 시점에서 산업에 유용한에있는 내가 그 도구를 믿지 않는, 강한 인센티브를 가지고있는 유일한 산업이 결함 무료로 항공 전자 공학의학 흥미롭게도이 (, FDA는 분명히 소프트웨어가 다르다 "라고 해당 하드웨어의 하드웨어에서 또한 Verilog / VHDL로 개발하는 경우 이진 논리를 고수하고 있습니다. 이것은 복잡성을 크게 줄입니다. Y2K 문제와 동등한 하드웨어는 없습니다.

큰 문제는 상황이 복잡하다는 것입니다. 복잡성을 제거 할 수 없으며 이동 만 할 수 있습니다.


1

인터페이스와 기능을 정의하고 테스트 벤치를 작성하고 하드웨어 모듈을 구현 한 다음 시뮬레이터를 사용하여 하드웨어를 테스트합니다. 그런 다음 해당 하드웨어 모듈을 빌딩 블록으로 사용하여 더 크고 더 나은 것을 만들 수 있습니다. 해당 모듈에 기능을 추가해야하는 경우 두 번째 모듈을 작성하고 기능을 추가하십시오. 원래 모듈은 제대로 작동하고 여전히 유용 할 수 있으므로 절대 버리지 마십시오.

소프트웨어 세계에서는 "모듈"을 라이브러리라고하며 동일한 방식으로 사용합니다. 많은 도서관들은 그들이 잘 기능 할 수 있도록 만들어졌으며, 뭔가 중요한 것이 다음 개정으로 이어질 때까지 아무런 변화없이 만족스럽게 일을하고 있습니다. 그것들을 에폭시가 들어있는 소프트웨어라고 생각하십시오 :-)

소프트웨어에 대한 나의 주요 좌절 중 하나는 결코 "완료"되지 않았다는 것입니다. 추가해야 할 다른 기능이 항상 있습니다. 기능을 추가 할 때 종종 이전에는 제대로 작동하던 버그가 발생합니다. 인터페이스를 위반하지 않는 한 하드웨어에서는 발생하지 않습니다.

호그 워시. 아마도 당신은 다른 많은 납땜을하지 않는 "하드웨어"사람들보다 개인적으로 더 나을지 모르지만, 많은 불량 회로 설계, 칩 고장 ( 예 : 유명한 인텔 "f00f"문제)을 보았지만 그렇지 않습니다. 전체적으로들과 대화하십시오. 그리고 가짜 하드웨어가 "부드러워"짐에 따라 문제를 예방하기가 더 어려워집니다.

하드웨어가 "쓰기"되는 것과 유사한 방식으로 소프트웨어를 작성할 수 있습니까? 항상 진보를 이룰 수 있고 기존 코드를 다시 작성하지 않고 새로운 버그를 도입하지 않고도 새로운 기능을 추가 할 수있는 좋은 소프트웨어 개발 방법이 있습니까?

예. 우리는 그 방법론을 많이 사용하지 않습니다. 그것들은 작동하는 데 비용이 많이 드는 경향이 있으며 대부분의 프로그래머는 자신의 제한 내에서 일하는 것을 좋아하지 않습니다. 예를 들어, 인간의 삶이 관련 될 때 우리는 사용자를 죽이지 않으려 고 노력합니다.

마지막 요점 : 소프트웨어는 하드웨어, 심지어 프로그래밍 된 하드웨어와는 다른 재무 모델을 가지고 있습니다. 대부분의 비 소비자 소프트웨어 및 일부 소비자 소프트웨어는 변경을 장려하는 방식으로 판매됩니다. "1 년에 $ 10,000 + 1 년에 18 %를 지불하십시오"라고 비즈니스에 말할 수 있으면 본질적으로 몇 년마다 제품을 재판매 할 수 있습니다. 그러나이 수수료를 정당화하려면 고객에게 원하는 변경 사항을 제공해야합니다. 흠 ... 애플의 하드웨어 노후화 곡선을 생각하면, 아마도 이것이 전혀 다르지 않을 것입니다-하드웨어는 실제로 그것을 다시 구매하게합니다!


내가 누구보다 낫다고 말한 적이 없어 ;-) 하드웨어에 버그가 있으면 뉴스가됩니다. 소프트웨어에 버그가 있으면 대기 소프트웨어에는 항상 버그가 있습니다. 너무 비싸고 재미 있지 않기 때문에 사용하지 않는 방법은 무엇입니까?
Nathan Farrington

0

작업 코드에 버그를 도입하지 않고 항상 발전시켜 소프트웨어를 더 재미있게 작성하려면 어떻게해야합니까?

귀하의 질문에 대한 최종 답변을 찾고 싶습니다. 그러나 실제로는 쉬운 방법이 없기 때문에 극단적 인 프로그래밍과 TDD 기술이 인기를 얻고 있습니다. 일어날 일이기 때문에 변화를 수용해야합니다. 나는이 방법이 더 재미 있는지 모르겠지만 확실히 스트레스가 적습니다. ;-)

http://en.wikipedia.org/wiki/Extreme_Programming

하드웨어와 상호 작용할 때 하드웨어에는 x 가치가 필요하고 그 모든 것 (이론상)이 필요하지만 오늘날 사람들과 상호 작용할 때 x가 필요하고 내일에는 y가 필요할 수 있습니다. 이것이 바로 탈취 및 인력 요구 사항의 변화입니다. . Persons! = 기계이므로 대부분의 시간을 변경하지 않는 코드는 불가능합니다.

또한 이전 / 삭제 된 답변에 대해 말했듯이 사람들이 코딩을 시작하기 전에 생각하게하여 중요하지 않은 변경을 피하십시오. 의사 결정 등에 사용자를 더 참여 시키십시오. 변경 비용을 명확하게하고, 더 계획을 세우십시오. 이는 "코딩 방법"이 아니고 "코딩이 아닌"방법입니다. 요구 사항에 대해서는 변경이 적고 더 재미 있기 때문입니다.


1
좋은 대답입니다. 익스트림 프로그래밍을 완료했습니다. 고객의 요구에 따라 전체 프로젝트 방향이 매주 바뀔 수있는 곳과 정확히 반대되는 것처럼 보입니다. 나는 반복적 인 릴리스에 반대하지 않고, 단지 두 번째 버전이 첫 번째 버전에는 없었던 버그를 도입하는 것을 원하지 않습니다. 또한 초기 설계로 장기적으로 노력을 아낄 수 있습니다.
Nathan Farrington

항상 말했듯이 최고의 코드는 코드가 아닙니다. :-)
H27studio

0

비슷한 방식으로 소프트웨어를 작성할 수 있습니까?

그렇습니다. 하드웨어를 개발하고 가능한 모든 것을 테스트하는 것처럼 조심하면 소프트웨어의 품질이 비슷해집니다.

그건 그렇고, HW 버그에 대해 들어 보지 못했습니까? 훨씬 더 나쁘고 SW 버그가 많고 수정하기가 더 어렵습니다 (소프트웨어 업그레이드뿐만 아니라)


1
예, 하드웨어에도 버그가 있으며 프로세서와 같이 잘 테스트 된 성숙 하드웨어도 있습니다. 좋은 하드웨어는 하드웨어 버그가 소프트웨어에서 수정 될 수 있도록 설계되었습니다! 내 원래 질문의 이유는 많은 소프트웨어를 작성했지만 버그를 도입하는 것이 얼마나 쉬운 지와 시스템 전체가 얼마나 지저분했는지에 대해 항상 당황했습니다. 저는 깔끔한 종류의 사람이므로 하드웨어 개발 방법론이 항상 더 자연스러워 보였습니다. 범위와 관련이있을 수도 있습니다.
Nathan Farrington 2012 년

1
@NathanFarrington 소프트웨어는 보통 HW보다 더 복잡합니다. HW는보다 철저한 테스트를 거칩니다. SW는 쉽게 변경 될 수 있으므로 사람들은 그다지주의를 기울이지 않는 경향이 있습니다.
BЈовић

0

또한 하드웨어의 소프트웨어 버그가 종종 사람들을 죽일 수 있다고 지적합니다. 따라서 요구 사항을 철저히 파악하고 철저하게 테스트하기 위해 더 많은주의가 필요합니다. 이러한 요구 사항은 하드웨어가 변경 될 때까지 변경할 필요가 없습니다. 그리고 새로운 하드웨어는 다시 쓰기를 요구할 수 있기 때문에 바스프가 너무 많이 쌓이지 않는 것 같습니다.

반면에 비즈니스 요구 사항은 지속적으로 변경되기 때문에 때로는 변경을 요청하기 전에 하나의 요구 사항을 프로덕션에 적용하기가 어렵습니다. 때때로, 나는 생산에 들어가기 전에 요구 사항이 여러 번 변경되었습니다. 이것은 여러 가지 결과입니다. 먼저 비즈니스 측면의 프로젝트 이해 관계자는 자신이 "바쁘고" "중요한"사람이기 때문에 자신이 원하는 것을 철저히 정의하는 데 시간을 소비하는 데 관심이 적으며 사람들이 죽지 않고 가족이 그를 고소하거나 감옥에 갇히게합니다. 그는 과정의 일부를 날려 버린다. 둘째, 프로젝트 이해 관계자는 하드웨어가 덜 추상적이기 때문에 실제로 하드웨어가 무엇을 원하는지 더 잘 이해하는 경향이 있습니다. 그들은 그들이 볼 때까지 그들이 원하는 것을 정말로 모릅니다. 하드웨어에 대한 문제는 적습니다.


당신은 유효한 포인트가 있습니다. 프로세서, USB 컨트롤러, PCI Express 엔드 포인트, 메모리 컨트롤러 등 하드웨어에서 일반적으로 사용하는 작업 유형은 잘 알려져 있습니다. 그런 다음 모든 응용 프로그램 비즈니스 로직을 소프트웨어에 적용합니다. 어쩌면 소프트웨어 스택을 진행하면서 더 복잡하고 이해하기 어려울까요?
Nathan Farrington

-1

응용 프로그램에 결합 할 수있는 완성 된 '브릭'이 많은 고급 도구가 있습니다. 벽돌은 사용하기 위해 완성 된 조각입니다. 단지 결합해야합니다. 고객이 이상하고 예기치 않은 변경을 요청할 때까지 더 쉽다고 생각할 수도 있습니다.

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