스파게티 코드
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
스파게티 코드는 프로그램의 제어 흐름이 복잡하게 얽혀 있어 이해와 유지보수가 어려운 코드를 의미한다. 주로 goto 문의 남용, 전역 변수의 무분별한 사용, 부적절한 상속, 콜백 함수의 과도한 사용 등이 원인이며, 1970년대부터 부정적인 의미로 사용되었다. 스파게티 코드는 소프트웨어 테스트, 디버깅, 개선 및 확장을 어렵게 만든다. 해결 방법으로는 리팩토링 또는 재작성을 통해 가독성과 유지보수성을 높이는 방법이 있으며, 테스트 주도 개발 방법론을 함께 사용하면 효과적이다. 관련 용어로는 개별 클래스는 이해하기 쉽지만 전체적인 프로그램 구조는 파악하기 어려운 라비올리 코드, 계층 구조가 지나치게 복잡하게 얽혀 있는 라자냐 코드가 있다.
GOTO 문을 구조적 프로그래밍 구문 대신 과도하게 사용하여 복잡하고 유지 보수가 불가능한 프로그램을 만드는 코드를 흔히 스파게티 코드라고 부른다.[2] 이러한 코드는 복잡하고 얽힌 제어 구조를 가지며, 프로그램 흐름이 개념적으로 스파게티 그릇처럼 꼬이고 얽히게 된다.[3]
스파게티 코드라는 용어는 1970년대부터 여러 참고 자료에서 등장하기 시작했다.[7] 리처드 콘웨이는 1978년 저서에서 프로그램이 "마치 스파게티 한 접시처럼 깔끔하지 않은 논리 구조를 갖는다"라고 묘사했으며,[8] 1979년 데이비드 그리스와 공동 저술한 책에서도 이를 반복했다.[9] 1988년 논문에서는 계획 부족으로 인해 폭포수 모델 개발로 이어지는 구식 방식인 '코드 앤 픽스 모델'을 설명하는 데 사용되었다.[10] 폴 놀은 1979년 저서에서 '스파게티 코드'와 '쥐 둥지'라는 구문을 형편없이 구조화된 소스 코드를 묘사하는 동의어로 사용했다.[11]
스파게티 코드는 여러 가지 원인으로 발생할 수 있다.
2. 정의
미국 국립 표준 기술 연구소(NIST)의 1980년 간행물에서는 '''''스파게티 프로그램'''''이라는 문구를 사용하여 "단편화되고 흩어진 파일"을 가진 구식 프로그램을 묘사했다.[4]
스파게티 코드는 반패턴을 설명할 수 있는데, 객체 지향 프로그래밍 코드가 절차적 스타일로 작성되는 경우이다. 예를 들어 메서드가 지나치게 길고 지저분한 클래스를 만들거나, 다형성과 같은 객체 지향 개념을 포기하는 경우가 이에 해당한다.[5] 이러한 형태의 스파게티 코드가 있으면 시스템의 이해도가 크게 떨어질 수 있다.[6]
명령형 프로그래밍에서 프로그램은 컴퓨터에 대한 절차서이며, 프로그램에 쓰여진 대로 컴퓨터에 대한 지시(명령어)가 차례대로 실행되어 컴퓨터가 이를 해석함으로써 작동한다. 중간 표현과 가상 머신을 이용하는 형태도 있지만, 최종적으로는 기계어로 변환되어 컴퓨터가 직접 해석할 수 있는 명령어가 된다. 메모리에 존재하는 변수 등으로 관리되는 프로그램의 상태를 동적으로 변화시키면서 프로그램에 쓰여진 대로 문을 차례대로 실행한다. 기본적으로는 위에서 아래로 내려가는 순서대로 프로그램 행이 한 문장씩 실행되지만, 행 번호나 레이블을 지정하여 멀리 떨어진 곳으로 점프하는 명령어나, 서브루틴 호출과 복귀 등, 멀리 떨어진 곳으로 점프하여 다른 코드를 실행한 후 다시 원래 위치로 돌아오는 명령어도 있다. 스파게티 프로그램이란, 규율 없는 부주의한 점프의 남용으로 인해 명령 실행 순서가 복잡하게 얽혀 있거나, 프로그램의 상태를 관리하기 위한 변수가 프로그램 전체에서 읽고 쓰여지는 등, 마치 스파게티가 엉킨 것과 같은 상태가 된 프로그램을 말한다.
스파게티 프로그램은 테스트, 내부 동작 분석 및 디버깅을 어렵게 한다. 결과적으로 프로그램 개발 및 완성을 방해하고, 소프트웨어 개선이나 확장을 어렵게 만든다.
구조적 프로그래밍을 지원하는 현대적인 환경에서도, 변수명 등이 부적절하여 이해하기 어렵거나, 복잡한 조건 분기, 또는 처리 내용 및 기능의 묶음에 따라 적절하게 분할되지 않은 장황한 서브루틴 및 거대한 클래스 등에 의해, 가독성 및 유지보수성이 결여된 스파게티 프로그램은 쉽게 발생할 수 있다. 스레드 등을 사용한 비동기 프로그래밍 또한, 또 다른 의미의 스파게티화를 초래하기 쉽다.
소스 코드의 가독성은 읽는 사람의 기량이나 지식에도 좌우되는 상대적인 지표이므로, 초보자에게 난해한 코드가 반드시 스파게티 프로그램이라고 할 수는 없다. 그러나, 기교를 부린 코드나, 처리 속도 등의 최적화를 위해 가독성, 범용성, 확장성 등을 희생시킨 코드는, 무엇을 하고 싶은지 이해하기 어렵고, 경험 많은 프로그래머라도 내용 이해에 시간이 걸리거나 오해할 수 있다. OS나 API, 라이브러리의 문제를 해결하기 위해 응용 소프트웨어에서 필요하게 되는 코드도, 언뜻 보기에는 무의미하게 보이는 경우도 있다. 또한, 자신이 쓴 코드라도 나중에 다시 읽을 때 자세한 내용을 잊어버리는 경우도 많다. 이때, 사양서나 소스 코드 내의 주석에 충분한 설명이 없거나, 코드 수정으로 사양서나 주석이 구현과 달라지면, 해독 불가능한 스파게티 코드가 되어버린다.
서브루틴이나 클래스를 처음 구현했을 때는 정연하고 읽기 쉬운 코드였다 하더라도, 기능 추가나 사양 변경에 대응하기 위해 코드를 수정하고, 상태를 관리하기 위한 변수나 조건 분기 등이 증가함에 따라 점차 가독성이 상실되고, 설계도 진부화되어 스파게티 코드가 되어버리는 경우도 있다.[18]
3. 역사
1981년 ''The Michigan Technic''에 실린 글에서는 포트란을 "전적으로 스파게티 코드로 구성"되어 있다고 설명했다.[13] 리처드 해밍은 자신의 강연에서[14] 이 용어의 어원을 이진 코드로 초창기 프로그래밍을 할 때의 상황과 관련하여 설명했다. 당시에는 오류 수정 시 누락된 명령어를 삽입하기 위해 명령어들을 이리저리 옮겨야 했고, 이 과정이 반복되면서 프로그램의 제어 흐름이 스파게티처럼 복잡하게 얽히게 되었다는 것이다.
goto 문의 남용은 BASIC과 같은 구조화되지 않은 프로그래밍 언어에서 스파게티 코드를 만들어내는 주요 원인으로 지적되었다. goto 문은 프로그램의 흐름을 예측하기 어렵게 만들고 가독성을 떨어뜨려 오류 발생 가능성을 높였다. 구조화 이전의 BASIC은 이러한 문제점으로 인해 혹평을 받았고, 이후 행 번호와 GOTO 문을 폐지하고 구조적 프로그래밍을 지원하는 "구조화 BASIC"이 등장하게 되었다.
C, C++, Java, C# 등 후대의 언어들은 예외 처리나 레이블이 붙은 break 문 등을 통해 goto 문의 사용을 최소화하거나, 아예 사용하지 않도록 유도하고 있다.
하지만 1980년대까지는 구조화되지 않은 프로그래밍 언어가 널리 사용되었고, 제한된 메모리 환경에서 프로그램을 작성해야 했기 때문에 어쩔 수 없이 GOTO문이 사용되는 경우가 많았다. 특히 패미컴과 같은 게임 개발에서는 CPU의 버그를 이용하는 기교적인 프로그래밍 기법이 사용되기도 했으며, 이는 프로그램의 스파게티화를 더욱 심화시켰다.
3. 1. 한국의 특수한 상황
1980년대 한국의 컴퓨터 환경은 메모리 용량이 매우 제한적이었다. 이러한 환경 때문에 프로그래머들은 코드의 크기를 최대한 줄여야 했다.[19] 잡지 등에서는 코드 압축 기술을 겨루는 콘테스트가 열리기도 했으며, 이 과정에서 가독성을 희생한 스파게티 코드가 허용되기도 했다. 예를 들어, MSX·FAN 잡지의 "1화면 프로그램" 코너에서는 매우 짧은 코드를 만들기 위해 가독성을 포기한 코드들이 많이 채택되었다.[19]
당시 사용된 코드 압축 기술의 예시는 다음과 같다:
일반적인 BASIC 코드에서 트리거 입력을 대기하는 루틴은 다음과 같이 작성한다.
10 IF STRIG(0)=0 THEN GOTO 10
하지만, "1화면 프로그램"에 채택된 작품에서는 다음과 같은 기술이 사용되었다.
10 FORI=0TO1:I=-STRIG(0):NEXT
이 외에도, 가독성이 전혀 없는 머신어 소스를 아스키 코드 제어 문자열을 포함하지 않는 범위의 8비트 값으로 시프트시키고, 그 캐릭터 코드군과 디코더만 기술하는 프로그램이 채택되는 경우도 있었다.
일반적인 표기법으로 작성된, "*"를 컨트롤러로 좌우로 움직이는 프로그램은 다음과 같다.
10 CLS
20 LET X=14
30 LOCATE X,10:PRINT " ";
40 LET S=STICK(0)
50 IF S=3 THEN X=X+1: IF X>28 THEN X=28
60 IF S=7 THEN X=X-1: IF X<0 THEN X=0
70 LOCATE X,10:PRINT "*";
80 GOTO 30
하지만 압축을 위해 자주 사용되던 방법으로 작성하면 다음과 같이 된다.
1 CLS:X=14
2 LOCATE X,10:PRINT" ";:S=STICK(0):X=X-(S=3)*(X<28)+(S=7)*(X>0):LOCATE X,10:PRINT"*";:GOTO 2
이는 조건 분기를 생략하고, 수평 좌표 변수 X의 범위를 체크하는 관계식을 수치로 취급하여 하나의 대입문으로 만든 것이다.
또한, 31바이트로 프로그램을 작성하는 "어셈블러 단가"라는 장르도 있었는데, 이러한 작품들에서도 스파게티 형태의 점프가 자주 사용되었다.
4. 스파게티 코드의 원인
구조적 프로그래밍을 지원하는 현대적인 환경에서도, 다음과 같은 원인으로 인해 스파게티 코드가 발생할 수 있다.
스레드 등을 사용한 비동기 프로그래밍 또한, 또 다른 의미의 스파게티화를 초래하기 쉽다.
소스 코드의 가독성은 읽는 사람의 기량이나 지식에 따라 달라지는 상대적인 지표이다. 초보자에게 난해한 코드가 반드시 스파게티 프로그램이라고 할 수는 없다. 그러나, 함부로 기교를 부린 코드나, 처리 속도 등의 최적화를 위해 가독성·범용성·확장성 등을 희생시킨 코드는, 경험이 많은 프로그래머라도 내용 이해에 시간이 걸리거나 오해할 수 있다. OS나 API·라이브러리의 문제를 회피하기 위해 응용 소프트웨어 측에서 어쩔 수 없이 필요하게 되는 코드도, 언뜻 보기에는 무의미하게 보이는 경우도 있다. 또한, 자신이 쓴 코드라 하더라도, 나중에 다시 읽을 때에는 자세한 내용을 잊어버리는 경우도 많다. 이럴 때, 사양서나 소스 코드 내의 주석에 충분한 설명이 없거나, 혹은 코드 수정에 의해 사양서나 주석이 구현과 괴리되어 있으면, 즉시 해독 불가능한 스파게티 코드가 되어버린다.
서브루틴이나 클래스를 처음 구현했을 때는 정돈되고 읽기 쉬운 코드였더라도, 기능 추가나 사양 변경에 대응하기 위해 코드를 수정하고, 상태를 관리·유지하기 위한 변수나 조건 분기 등이 증가함에 따라 점차 가독성이 상실되고 설계가 진부화되어 스파게티 코드가 되어버리는 경우도 있다.[18]
과거에는 프로그래밍 언어의 한계나 하드웨어 제약으로 인해 스파게티 코드가 불가피한 경우도 있었다.
하지만 현대에는 메모리 용량이 풍부하고 가독성이 중요하며, 유지보수와 코드 변경이 용이하고, 시스템이 안정적으로 작동하는 것이 중요하다고 여겨지기 때문에 스파게티 코드는 절대 작성해서는 안 되는 것으로 여겨진다.
4. 1. goto 문의 남용
GOTO 문을 구조적 프로그래밍 구문 대신 과도하게 사용하여 복잡하고 유지 보수가 불가능한 프로그램을 만드는 코드를 흔히 스파게티 코드라고 부른다.[2] 이러한 코드는 복잡하고 얽힌 제어 구조를 가지며, 프로그램 흐름이 개념적으로 스파게티 그릇처럼 꼬이고 얽히게 된다.[3]
다음은 BASIC 프로그래밍 언어에서 스파게티 코드의 예시이다. 이 프로그램은 1부터 100까지의 각 숫자를 제곱과 함께 화면에 출력한다. 들여쓰기는 코드가 수행하는 다양한 작업을 구분하는 데 사용되지 않으며, 프로그램의 `GOTO` 문은 줄 번호에 의존성을 만든다. 한 영역에서 다른 영역으로의 실행 흐름을 예측하기가 더 어렵다.
```basic
1 i=0
2 i=i+1
3 PRINT i;"squared=";i*i
4 IF i>=100 THEN GOTO 6
5 GOTO 2
6 PRINT "Program Completed."
7 END
```
다음은 동일한 코드를 구조적 프로그래밍 스타일로 작성한 것이다.
```basic
1 FOR i=1 TO 100
2 PRINT i;"squared=";i*i
3 NEXT i
4 PRINT "Program Completed."
5 END
```
위의 두 예시에서 for 루프와 함수는 제어 흐름을 제공하지만, ''goto'' 문은 임의적인 제어 흐름을 장려하기 때문에 아래쪽의 프로그램은 한 영역에서 다른 영역으로 이동이 형식적이고 예측하기가 더 쉽다.
아래의 두 베이직 코드는 같은 작동을 한다.
```gwbasic
10 DIM i
20 i = 0
30 i = i + 1
40 IF i <> 10 THEN GOTO 90
50 IF i = 10 THEN GOTO 70
60 GOTO 30
70 PRINT "Program Completed."
80 END
90 PRINT i; " squared = "; i * i
100 GOTO 30
```
```gwbasic
10 DIM i
20 FOR i = 1 TO 9
30 PRINT i; " squared = "; i * i
40 NEXT
50 PRINT "Program Completed."
```
이때 앞쪽의 GOTO 문을 사용한 코드에 비해 뒤쪽의 코드는 for 문을 사용했고, 작동 방식이 더 직관적이다.
명령형 프로그래밍에서 프로그램은 컴퓨터에 대한 절차서이며, 프로그램에 쓰여진 대로 컴퓨터에 대한 지시(명령어)가 차례대로 실행되어 컴퓨터가 이를 해석함으로써 작동한다. 중간 표현과 가상 머신을 이용하는 형태도 있지만, 최종적으로는 기계어로 변환되어 컴퓨터가 직접 해석할 수 있는 명령어가 된다. 메모리에 존재하는 변수 등으로 관리되는 프로그램의 상태를 동적으로 변화시키면서 프로그램에 쓰여진 대로 문을 차례대로 실행한다. 기본적으로는 위에서 아래로 내려가는 순서대로 프로그램 행이 한 문장씩 실행되지만, 행 번호나 어떤 레이블을 지정하여 멀리 떨어진 곳으로 점프하는 명령어나, 서브루틴 호출과 복귀 등, 멀리 떨어진 곳으로 점프하여 다른 코드를 실행한 후 다시 원래 위치로 돌아오는 명령어도 있다. 스파게티 프로그램이란, 규율 없는 부주의한 점프의 남용으로 인해 명령 실행 순서가 복잡하게 얽혀 있거나, 프로그램의 상태를 관리하기 위한 변수가 멀리 떨어진 곳(프로그램 전체의 여기저기)에서 읽고 쓰여지는 등, 마치 스파게티가 엉킨 것과 같은 상태가 된 프로그램을 말한다.
4. 2. 전역 변수의 무분별한 사용
전역 변수는 프로그램의 어느 곳에서든 접근할 수 있어 편리하지만, 이로 인해 의도치 않은 부작용이 발생할 수 있다.[18] 가능한 지역 변수를 사용하고, 전역 변수의 사용은 최소화해야 한다. 변수의 스코프(유효 범위)를 항상 의식하고, 변수의 역할이 불명확한 경우 블록의 맨 앞에 변수 선언과 주석문을 통해 명확히 해야 한다.
4. 3. 부적절한 상속 (객체 지향 프로그래밍)
객체 지향 프로그래밍에서 상속은 코드를 재사용하고 확장하는 강력한 기능이지만, 남용하면 클래스 간의 관계가 복잡해져 스파게티 코드를 유발할 수 있다.[5] 특히 다중 상속은 여러 문제를 야기할 수 있으므로, 인터페이스를 활용하거나 객체 합성을 사용하는 것이 권장된다.[6]
4. 4. 콜백 함수의 과도한 사용
이벤트 기반 프로그래밍, 특히 GUI 프로그래밍에서 콜백 함수는 필수적이지만, 과도하게 사용하면 프로그램의 흐름을 파악하기 어려워진다.[30] 이러한 비동기 프로그래밍의 복잡성을 완화하기 위해 퓨처(Future), async/await 등의 개념이 도입되었다.
4. 5. 기타 요인
콜백 함수, 객체 지향 다형성을 실현하는 가상 함수, 덕 타이핑에 사용되는 리플렉션과 같은 동적 결합(동적 디스패치 또는 동적 바인딩)은 알고리즘 재사용성을 향상시키는 데 유용한 기능이지만, 실행 시점에서 실체를 특정(이름 해결)해야 하고, 통합 개발 환경 기능을 사용해도 호출 구조나 의존 관계를 직접 추적할 수 없기 때문에 남용하면 스파게티 코드를 유발하기 쉽다.[30] 함수 오버로딩이나 연산자 오버로딩, C++의 템플릿과 같은 정적 결합이라도, 템플릿 메타 프로그래밍 등으로 남용하면 스파게티 코드를 유발하기 쉬워진다. Dynamic dispatch영어
5. 스파게티 코드 해결 방법
스파게티 코드는 유지 보수 및 기능 추가를 방해하므로 가능하다면 수정하는 것이 바람직하다. 스파게티 코드를 해결하는 방법은 다음과 같다.
- '''구조적 프로그래밍''': BASIC 프로그래밍 언어에서 `GOTO` 문은 줄 번호에 의존성을 만들고, 한 영역에서 다른 영역으로의 실행 흐름을 예측하기 어렵게 하여 스파게티 코드를 유발한다. 반면 for 루프와 함수는 제어 흐름을 예측 가능하게 만들어 스파게티 코드를 방지한다.
- '''부적절한 코드 개선''': 현대적인 환경에서도 변수명이 부적절하거나, 조건 분기가 복잡하거나, 처리 내용 및 기능에 따라 적절하게 분할되지 않은 서브루틴 및 클래스 등으로 인해 가독성과 유지보수성이 낮은 스파게티 프로그램이 발생할 수 있다.
- '''기타''': 스레드 등을 사용한 비동기 프로그래밍 또한, 또 다른 의미의 스파게티화를 초래하기 쉽다.
하지만 실무 시스템에서는 안정성이 중요하며, 부주의한 코드 수정은 시스템 안정성을 해치고 사용자에게 피해를 줄 수 있다. 따라서 "일단 잘 작동하는 프로그램은 함부로 수정하지 않는다"는 원칙이 널리 행해지기도 한다.[18]
5. 1. 리팩토링
테스트 주도 개발 방법론이 확립되면서 프로그램 변경의 위험성은 상대적으로 낮아져, 부적절한 상태의 프로그램은 적극적으로 수정하는 리팩토링이 장려된다. 그러나 스파게티 코드는 수정에 따른 장단점과 방치했을 때의 장단점을 비교하여, "일단 잘 작동하는 프로그램은 함부로 수정하지 않는다"는 판단이 실무에서 널리 행해지기도 한다.각종 범용 운영 체제, 소프트웨어 개발 도구, 금융 기관의 기간 시스템, 산업용 기계의 제어 소프트웨어, 업무용 애플리케이션 등은 안정성이 매우 중요하며, 부주의한 코드 수정으로 시스템 안정성을 해치면 업무 중단 및 사용자에게 막대한 피해를 줄 수 있다. 또한 금전적 손실 보상이나 사용자 이탈로 이어질 수 있다.
스파게티 코드를 충분한 분석과 테스트 없이 경솔하게 수정하면 기존 기능 및 동작 호환성을 해치거나, 다른 버그를 추가하거나, 수정했던 버그를 부활시킬[18] 가능성이 높다. 시간, 예산, 인력이 충분한 경우에도 이러한 경향은 나타난다. 스파게티 코드는 복잡하게 얽혀 해독, 분할, 분리가 어려워 대규모 작업이 필요한 경우가 많다.
따라서, 너무 심각한 스파게티 코드는 수정하는 대신 과감하게 포기하고 새롭게 구조화된 프로그램을 작성하는 것이 더 효율적일 수 있다.
5. 2. 재작성
심각한 스파게티 코드는 고치는 것보다 새로 만드는 것이 더 효율적일 수 있다. 기존 코드의 문제점을 분석하고, 구조적 프로그래밍 원칙을 적용하여 새롭게 설계하는 것이 좋다.[18]너무 심하게 꼬인 스파게티 코드는 수정하기보다, 차라리 버리고 처음부터 구조적으로 잘 짜인 프로그램을 새로 만드는 것이 훨씬 빠를 수 있다.
6. 스파게티 코드와 관련된 용어
객체 지향 프로그래밍에서 사용되는 라비올리 코드는 개별 클래스들은 이해하기 쉽지만, 전체적인 구조는 파악하기 어려운 코드를 의미한다.[15]
라자냐 코드는 계층 구조가 너무 복잡하게 얽혀 있어, 한 계층을 변경하면 다른 모든 계층을 변경해야 하는 코드를 의미한다.[16]
참조
[1]
학술지
Straightening spaghetti-code with refactoring?
https://web.archive.[...]
2018-03-05
[2]
학술지
Pronouns and procedural meaning: The relevance of spaghetti code and paranoid delusion
https://web.archive.[...]
2018-03-05
[3]
서적
Java Concepts for AP Computer Science
J. Wiley & Sons
2017-01-02
[4]
서적
ASTM special technical publication
United States Government Printing Office
[5]
학술지
DECOR: A Method for the Specification and Detection of Code and Design Smells
2010-01
[6]
서적
2011 15th European Conference on Software Maintenance and Reengineering
2011
[7]
문서
Macaroni is better than spaghetti
Association for Computing Machinery
1977
[8]
서적
A primer on disciplined programming using PL/I, PL/CS, and PL/CT
Winthrop Publishers
[9]
서적
An Introduction to Programming
Little, Brown
[10]
학술지
A spiral model of software development and enhancement
1988-05
[11]
서적
Structured programming for the COBOL programmer: design, documentation, coding, testing
M. Murach & Associates
[12]
컨퍼런스
Use and abuse of exceptions — 12 guidelines for proper exception handling
Springer Berlin Heidelberg
[13]
학술지
BASICally speaking...FORTRAN bytes!!
1981-03
[14]
서적
The Art of Doing Science and Engineering
Taylor & Francis
1996
[15]
컨퍼런스
The OO-binary relationship model : A truly object oriented conceptual model
https://pure.uvt.nl/[...]
1991-05-13
[16]
학술지
Teaching Good Practices In Software Engineering by Counterexamples
https://www.research[...]
2018-03-05
[17]
웹사이트
スパゲッティコード（スパゲッティプログラム）とは - 意味をわかりやすく - IT用語辞典 e-Words
https://e-words.jp/w[...]
[18]
웹사이트
スパゲッティコードの意味とは？具体例や対策について詳しく解説
https://products.sin[...]
[19]
웹사이트
ジャンプ ステートメント - break、continue、return、goto - C# | Microsoft Learn
https://learn.micros[...]
[20]
웹사이트
using ステートメント - 破棄可能なオブジェクトが正しく使用されるようにする - C# | Microsoft Learn
https://learn.micros[...]
[21]
웹사이트
try-with-resources 文 | Java SE 7 Documentation | Oracle
https://docs.oracle.[...]
[22]
웹사이트
アンチパターンってなに？ | Think IT（シンクイット）
https://thinkit.co.j[...]
[23]
웹사이트
初期化 - cppreference.com
https://ja.cpprefere[...]
[24]
웹사이트
memcpy, memcpy_s - cppreference.com
https://ja.cpprefere[...]
[25]
웹사이트
How to: Define move constructors and move assignment operators (C++) | Microsoft Learn
https://learn.micros[...]
[26]
웹사이트
Opinion -- 川俣 晶：ソフト開発を成功させる1つの方法 - ＠IT
https://atmarkit.itm[...]
[27]
웹사이트
Lecture 4: IPC & Threads / CSE 120: Principles of Operating Systems
https://cseweb.ucsd.[...]
カリフォルニア大学サンディエゴ校
[28]
웹사이트
JEP 428: javaマルチスレッドプログラミングを容易にする構造化並行性
https://www.infoq.co[...]
[29]
웹사이트
Windows with C++ - The Pursuit of Efficient and Composable Asynchronous Systems | Microsoft Learn
https://learn.micros[...]
[30]
웹사이트
まずコードの可読性を最適化しよう | POSTD
https://postd.cc/opt[...]
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com