소프트웨어를 개발하면 IQ가 증가합니까?

예, 프로그래밍 소프트웨어는 부분적으로 IQ를 높이십시오, IQ 테스트에서 평가되는 논리-수학 및 창의적 지능에 직접적인 도움이 되기 때문입니다.

그러나 소프트웨어 개발이 우리의 인지 능력에 유리하다는 점을 명심하는 것이 중요합니다. 환경에서 양육되는 한 좋은 관행과 지속적인 학습.

• 1.- 사고 방식에 영향을 미치는 우수한 소프트웨어 개발 사례
• 1.1.- 간단
• 1.1.1.- 컴퓨터가 계속 충돌하는 이유는 무엇입니까?
• 1.1.2.- 나쁜 프로그래머란?
• 1.1.3.- 좋은 프로그래머가 되려면?
• 1.1.4.- 단순화된 방식으로 프로그래밍하는 것이 더 어렵습니까?
• 1.2.- 테스트
• 1.2.1.- 소프트웨어 테스트의 부재 또는 부정확한 사용으로 인해 발생한 컴퓨터 오류
• 1.2.1.1.- 미사일 탐지기 레이더 고장
• 1.2.1.2.- 선원의 파괴 I
• 1.2.1.3.- Therac-25, 방사선 치료 선형 가속기
• 1.2.1.4.- 배 요크타운(CG-48)과 0으로 나누기
• 1.2.1.5.- 분할 오류가 있는 인텔 펜티엄 프로세서
• 1.2.2.- 완벽에 가까운 소프트웨어의 예
• 1.2.3.- 소프트웨어 테스트의 현재 환경은 무엇입니까?
• 1.2.3.1.- 오늘날의 소프트웨어 테스트 오류 및 불일치
• 1.2.3.2.- 일관성 없는 소프트웨어 테스트에 대한 제안된 솔루션으로 공식 개발
• 2.- 지속적인 학습은 우리 뇌에 어떤 이점이 있습니까?
• 2.1.- 지능은 신경 효율성을 기반으로 합니다. - Erhan Genç
• 2.2.- 프로그래밍은 우리의 정신 능력에 어떤 영향을 미칩니까?
• 2.2.1.- 프로그래밍에 사용하는 도구는 정신 모델에 영향을 미칩니다.
• 2.2.1.1.- 2021년 IT 분야가 가장 추천되는 분야 중 하나인 이유는 무엇입니까?
• 2.2.2.- 뇌에 건강하다
• 2.2.3.- 프로그래밍하는 동안 뇌의 최대 5개 영역을 자극합니다.

사고 방식에 영향을 미치는 우수한 소프트웨어 개발 사례

우리가 이미 소프트웨어 프로젝트를 개발한 경험이 있을 때, 우리는 이미 이상적인 소프트웨어 프로젝트가 무엇인지에 대한 멘탈 모델을 구축했습니다. 하지만, 소프트웨어 프로젝트를 올바르게 개발하려면 어떻게 해야 합니까?

오늘날 우리는 방법론에 대해 인터넷에서 풍부한 정보를 찾을 수 있기 때문에 별로 복잡해 보이지 않을 수 있습니다. SCRUM 또는 Extreme Programming과 같은 프로젝트 개발용. 둘 다 프로젝트의 개발 주기 동안 조직을 보장하기 위해 따라야 하는 지침을 제공합니다. 관찰, 시간 추정 및/또는 팀워크.

우리의 관점에서:

조직화(높은 생산성을 위해)는 프로그래밍을 배우는 것보다 훨씬 더 어려울 수 있습니다. (이제 막 시작하는 분들을 위해), 또는 새로운 기술을 마스터 하는 것은 구조화된 프로젝트를 개발하는 것이 정말 어렵기 때문에, 정확하고 무엇보다 읽기 쉬운 방법.

알버트 아인슈타인은 언젠가 이렇게 말했습니다.

간단하게 설명할 수 없다면 충분히 이해하지 못한 것입니다. Albert Einstein

이것은 예를 들어 특히 소프트웨어 개발과 같은 모든 학습 영역에 적용됩니다. 코드를 단순화할 수 없고 제3자가 프로젝트를 이해할 수 있도록 구성할 수 없는 경우 우리는 그것을 잘하지 않습니다.

이러한 의미에서 우리는 실천을 통해 달성해야 합니다. 우리의 사고 방식과 행동 방식을 형성. 또한 다양한 프레임워크에서 제공하는 지침과 지침을 고려하여 방법론 및 / 또는 우리 프로젝트에 적용된 전문가의 권장 사항. 그러나 편지에 대한 그러한 지침을 따르는 것은 바람직하지도 효율적이지도 않습니다. 우리는 유연해야 하고 엄격하지 않아야 합니다.

다음으로 2에 대해 설명하겠습니다. 좋은 소프트웨어 개발 관행 당신이 고려해야 할 당신의 프로젝트를 수행할 때 그리고 나는 결국 당신의 사고 방식을 바꾸게 될 것이라고 확신합니다.

간단

코드를 가능한 한 간단하게 만드십시오!

라고 하는게 뉴스가 아니다. 컴퓨팅의 가장 큰 문제 중 하나는 복잡성입니다.. 그러므로, 단순함은 아마도 소프트웨어 세계에서 가장 중요하고 가치 있는 품질일 것입니다..

시간이 지남에 따라 컴퓨터는 우리 생활에서 없어서는 안될 존재가 되었으며 사회에 매우 중요한 변화를 가져왔습니다. 간단히 말해서, 컴퓨터는 우리가 더 적은 인력으로 더 많은 일을 할 수 있게 해주기 때문에 유용합니다.

한 사람이 컴퓨터가 1년 동안 하는 모든 작업을 수행하려고 한다고 가정해 보겠습니다. 아마도 그가 남은 인생은 몇 년이 걸릴 것입니다. 즉, 컴퓨터의 진정한 가치는 속도와 정확성입니다. 그리고 그것은 훌륭합니다!

그러나 컴퓨터에는 큰 결함이 있기 때문에 그렇게 완벽할 수는 없습니다. 컴퓨터에는 항상 결함이 있습니다. 아마도 우리는 일반적으로 소프트웨어 결함이 있는 횟수를 아직 인식하지 못했을 것입니다. 자주 사용하는 것이 컴퓨터만큼 결함이 있었다면 지금쯤이면 제거했을 것입니다.

내가 아는 사람들의 전부는 아니지만 대부분은 일주일에 적어도 1번의 피해를 경험합니다. 나는 적어도 일주일에 한 번은 어떤 종류의 실패를 겪었거나 친구나 동료는 약 10년 동안 같은 일을 겪었습니다.

세어보면 내 경험상 480가지 다른 형태의 고장이 있습니다. 그리고 그것은 멋지지 않습니다.

컴퓨터가 계속 충돌하는 이유는 무엇입니까?

소프트웨어에 관해서는 단 하나의 이유가 있습니다. 나쁜 프로그래머입니다.

약 5년 전에 나는 그 이유가 나쁜 프로그래머라는 의심을 가지고 있었습니다. 그러나 나는 확신이 서지 않았다. 이제 IT 분야에서 몇 년의 경험을 더하고 출판물을 통해 많은 전문가들과 상의한 결과 더 이상 의심하지 않습니다.

나는 나쁜 프로그래머가 수많은 컴퓨터 오류에 책임이 있다고 완전히 말할 수 있습니다.

나쁜 프로그래머란?

소프트웨어 프로그래머를 탓하는 것은 좀 불공평해 보이지만, 내가 아는 대부분의 사람들이 고급 소프트웨어 개발에 전념할 때 더욱 그렇습니다. 논리적 사고를 상당히 발달시킨 전문가입니다.

대다수의 프로그래머가 상당히 논리적인 사람들이라면 왜 그렇게 많은 버그가 있는 소프트웨어가 있습니까? 컴퓨터 오류의 주요 원인은 복잡성.

컴퓨터를 만드는 것은 내가 아는 가장 복잡한 과정일 것입니다. 수백만 개의 작업을 실행할 수 있습니다. 또한 동기화되어 작동해야 하는 수천 개의 부품이 있습니다. 컴퓨터가 단독으로 사용하는 운영 체제는 수천만 줄의 코드로 구성됩니다. Windows 10에만 4백만 개 이상의 파일과 50만 개 이상의 폴더가 있습니다. 이에 대한 증거는 다음 캡처입니다.

더 완전한 아이디어를 제공하기 위해 아래에서 자세히 설명합니다. 운영 체제당 코드 줄 수:

운영 체제	코드 라인
Linux 3.1 Kernel	15 수백만
Windows XP	40 수백만
Windows 7	40 수백만
Windows Vista	50 수백만
Debian 5.0 (기본 코드)	67 수백만
Mac OS X «Lion»	85 수백만

추가 정보를 남겨드립니다.

페이스북은 약 6,100만 라인의 코드를 가지고 있으며 구글은 약 20억 라인의 코드를 가지고 있습니다.. 물론 Google에서 제공하는 수많은 서비스가 이를 정당화합니다.

컴퓨터가 작동하는 소프트웨어는 너무 복잡해서 아무도 코드를 완전히 이해할 수 없을 것입니다.

따라서 프로그래밍은 복잡성을 줄여 단순성을 달성하려는 환경에서 존재해야 합니다. 이런 식으로 우리는 특별한 재능이 없는 프로그래머라도 계속해서 애플리케이션 작업을 할 수 있도록 합니다. 그렇지 않으면 코드가 작업하는 것이 거의 불가능할 정도로 높은 수준의 복잡성에 도달할 수 있습니다.

간단히 말해서 프로그래밍의 핵심은 "복잡성을 단순함으로 줄이십시오."입니다.

좋은 프로그래머가 되려면?

훌륭한 프로그래머는 이해하기 쉽고 유지 관리하기 쉽고 버그를 찾기 쉬운 것을 만듭니다. 그러나 단순함을 더 적은 코드 줄이나 더 이상 현대 기술을 사용하지 않는 것과 혼동하지 마십시오. 때때로 코드를 단순화하면 코드 줄이 늘어날 수 있으므로 항상 문서화하십시오.

일반적으로 고급 기술이나 현대 기술은 자연스럽게 단순함을 지향합니다. 그것들을 올바르게 사용하는 방법을 배우기만 하면 되는데, 이는 종종 어려운 일입니다.

단순화된 방식으로 프로그래밍하는 것이 더 어렵습니까?

일반적으로 우리는 단순화된 방식으로 프로그래밍하는 것이 빨리 하는 것보다 더 많은 시간이 걸린다고 생각합니다. 예를 들어, 업무의 일부 작업을 수행해야 할 때 우리는 일반적으로 생각하고 계획하는 데 멈추지 않고 신속하게 수행하려고 합니다. 우리는 더 이상 틀릴 수 없습니다!

최대한의 이해를 찾기 위해 문제에 대해 생각하는 데 더 많은 시간을 보내는 것이 더 효율적입니다. 이러한 방식으로 솔루션 작성을 빠르게 시작하고 중단하는 것보다 단순화된 솔루션을 제안할 수 있습니다. 구현이 불필요하게 복잡해졌다는 것을 깨닫습니다.

주변을 둘러보고 소프트웨어 프로그램에서 복잡성이 되었다는 큰 문제를 깨닫기만 하면 됩니다.

끔찍한 것에 새로운 기능을 추가하려고 할 때 정체되는 많은 응용 프로그램이 있습니다. 거대하고 복잡한 코드 괴물이 되었습니다.

간단한 프로그래밍의 기본과 방법에 대해 더 알고 싶다면 다음 책을 읽는 것을 추천한다. 나는 그것을 좋아했다!

Tests

항상 테스트를 실행합니다. 그들은 선택 사항이 아닙니다!

실제로는 절대 선택 사항이 아니어야 하지만 많은 프로그래머는 여전히 어떤 유형의 소프트웨어 테스트도 사용하지 않고 응용 프로그램을 개발하고 있습니다. 코드 오류는 최종 고객이 보고하기 때문입니다. 이것은 보통 일반 프리랜서의 경우입니다.

테스트 없는 프로그래밍은 안전 벨트 없이 운전하거나 안전망 없이 공중 그네 곡예를 하는 것과 같습니다. 현재로서는 항상 소프트웨어를 테스트하는 모범 사례를 채택해야 합니다.

소프트웨어 테스트의 부재 또는 부정확한 사용으로 인해 발생한 몇 가지 선행 사례를 살펴보겠습니다. 수백만 달러의 경제적 손실을 일으켰고 어떤 경우에는 수십 명의 목숨을 앗아갔습니다.

소프트웨어 테스트의 부재 또는 부정확한 사용으로 인해 발생한 컴퓨터 오류

아래에 언급된 이벤트를 통해 소프트웨어 테스팅에 대한 반성과 중요성을 더욱 높일 수 있을 것이라고 확신합니다.

미사일 탐지기 레이더 고장.

1983년 소련의 미사일 탐지 경보 시스템이 미국이 5발의 미사일을 발사했으며 진행 중이라고 보고했을 때 일어난 일입니다.

다행히 직관 및/또는 기준에 따라 담당자가 즉각 대응 명령을 내리지 않았고, 문맥에 맞지 않고 미사일의 수 때문에 공격을 이상하게 여겼기 때문에 기습 공격에 일반적으로 사용되는 것이 아니었기 때문입니다.

몇 시간 후, 모든 것이 미사일 레이더 시스템 오류로 인한 것으로 확인되었습니다. 시스템이 구름에 있는 태양의 반사를 혼동하기 때문에 당시에는 감지하기 다소 어려운 오류 미사일로 특정 위치에. 잠시 동안 제 3 차 세계 대전을 시작합니다. 그러나 다음을 철저히 수행한 후에는 피할 수 있었습니다.

• 환경 연구 경보 시스템이 배포될 위치
, 그리고
• 모든 유형의 입력 변수 주입 시스템에 영향을 줄 수 있는.

둘 다 소프트웨어 테스트의 일부인 관행입니다.

선원의 파괴 I

1962년에 발생하여 약 1,850만 달러의 손실을 입었고, 매리너 1호는 매리너 프로그램의 첫 번째 임무로 금성 상공을 비행하려 했지만 성공하지 못했습니다.

이륙 후 293초, 소프트웨어 버그 발견. 이 버그는 궤적을 바꿨습니다. 몇 초 후에 그것을 파괴하라는 명령을 보내야 했고, 따라서 더 이상 손상을 입히지 않도록 낙하를 방지해야 했습니다.

오류는 나중에 확인되었습니다. 코드의 공식이 잘못 프로그래밍되었습니다.

Therac-25, 방사선 치료 선형 가속기

당신은 스스로에게 물을 것입니다, 방사선 치료 선형 가속기 란 무엇입니까? 선형 가속기는 다양한 각도에서 종양을 겨냥한 X선 빔을 방출하는 기계입니다. 좋은 점은 이러한 장치가 주변 영역에 영향을 미치지 않으면서 종양의 모양에 맞게 X선을 맞춤화할 수 있다는 것입니다.

1985년 6월과 1987년 1월 사이에 AECL(Atomic Energy of Canada Limited)에서 생산한 Therac-25 방사선 과다 복용으로 인해 최소 6건의 사고와 3건의 사망에 참여했습니다.

조사 끝에 결론은 rac-25 사고의 주요 원인은 다음과 같습니다.:

• 잘못된 소프트웨어 개발 관행.
• 열악한 요구 사항 분석.
• 나쁜 소프트웨어 디자인.

그리고 그것이 충분하지 않다면, therac-25가 실행되는 소프트웨어는 식별이 거의 불가능한 방식으로 개발되었습니다. 버그나 오류를 자동으로 수정합니다.

발견된 다른 원인:

• AECL은 소스 코드를 검토하기 위해 독립 엔터티를 보낸 적이 없습니다.
• 위험 관리와 관련된 기능은 설계에서 고려되지 않았습니다.
• 시스템에서 센서의 올바른 작동을 확인할 수 없습니다.
• 상수 값을 유지하는 대신 값을 변경하는 플래그 변수가 있습니다.
• 변수 "class3" 오버플로.
• 그 중.

배 요크타운(CG-48)과 0으로 나누기

믿거 나 말거나 뛰어난 전투력과 특히 기술 장비로 수많은 상을 수상한 군함 Yorktown Ship은 소프트웨어 오류로 인해 견인되었습니다.

1997년 9월, 승무원이 데이터베이스 필드에 0을 입력하여 시스템이 내부적으로 0으로 나누기를 실행하게 했고, 이로 인해 버그가 발생하여 결국 버퍼 오버플로가 발생하고 결국 선박의 추진 시스템에 오류가 발생했습니다.

분할 오류가 있는 인텔 펜티엄 프로세서

1993년에 인텔은 계산이 잘못된 새로운 프로세서를 출시했습니다. 그것들은 알아차리기가 매우 어려웠지만 오류를 볼 수 있으려면 상당히 정확한 결과가 필요한 작업을 실행해야 했기 때문입니다.

그럼에도 불구하고 인텔은 수치화하기 힘든 이미지 손상을 제외하면 약 3억5000만 달러의 손실을 입었다.

내가 방금 언급한 5가지 경우는 불행히도 컴퓨터 오류로 인해 발생하는 수많은 인명을 희생시키고 올바른 소프트웨어를 작성해야 한다는 분명한 증거입니다.

소프트웨어엔지니어는 구조엔지니어나 토목엔지니어 뿐만 아니라, 필요한 기능의 신뢰성과 이행.

눈치채셨겠지만 테스팅은 모든 프로젝트의 기본적인 부분입니다. 그들은 선택 사항이 아닙니다!

Ilene Burnstein은 그녀의 책에서 다음과 같이 말했습니다. “실용적인 소프트웨어 테스팅”, 소프트웨어 테스트에는 3가지 주요 프로세스가 있습니다.

• 테스트 케이스 개발
• 테스트 케이스 실행
• 결과 분석

테스트 케이스를 구축하는 데 시간을 들이지 않는다면 제대로 하고 있지 않은 것입니다. 가능한 한 많은 사례를 시뮬레이션하는 다양한 시나리오로 테스트 사례를 구축하는 것이 중요합니다. 불행히도 시나리오를 100% 시뮬레이션하는 것은 불가능합니다.

Edsger Dijkstra는 다음과 같이 말했습니다.

테스트는 프로그램에 오류가 있음을 보여줄 수 있지만 오류가 없음은 보여줄 수 없습니다. Edsger Dijkstra (1972년 튜링상 수상)

그러나 잘못된 테스트 실행으로 인해 컴퓨터 오류가 발생하는 경우가 많은 것처럼 상을 받을 만한 성공 사례도 있습니다.

완벽에 가까운 소프트웨어의 예

오늘날에는 자동화 능력의 증가로 인해 다른 제품만큼 신뢰할 수 있는 소프트웨어를 개발하는 것이 가능합니다.

파리 지하철 14호선은 완전 자동화되어 있습니다. 열차는 무인 운전이며 소프트웨어로 운영됩니다. 이 열차 노선은 1998년에 개통되었습니다.

사실이지만 완벽함은 보장할 수 없고 수십 년이 지났지만 결함이 발견되지 않았습니다. 철저한 테스트 작업 덕분에 테스트 프로세스에서 약 86,000개의 명령이 실행되었습니다.

일반적으로 일부 국가에서는 인명 손실이 발생할 수 있는 시스템에 대해서만 완벽한 소프트웨어를 보장할 수 있는 엄격한 테스트 프로세스가 필요합니다.

대다수의 소프트웨어 회사는 높은 비용 때문에 이러한 엄격한 테스트 프로세스 구현을 거부합니다. 이는 이러한 작업에 대한 충분한 교육과 경험을 갖춘 테스트에 전념하는 전문가를 찾기가 어렵다는 것을 의미하며, 소프트웨어 테스팅 프로세스의 구현은 소프트웨어 자체 개발 비용과 같거나 더 높을 수 있기 때문입니다.

물론 INTEL의 경우와 마찬가지로 "당신은 당신의 차례가 될 때까지 배우지 않습니다", 프로세서 소프트웨어의 계산 오류로 인해 약 3억 5천만 달러의 손실을 입어야 했습니다. 소프트웨어 테스트 연구에 가장 많은 예산을 투자하는 IT 회사 중 하나가 된 실수.

소프트웨어 테스트의 현재 환경은 무엇입니까?

소프트웨어 프로젝트 개발 경로는 잘 정의된 3단계로 구성됩니다.

• 명세서
• 디자인 및 코딩
• 검증

검증 단계에서 담당 엔지니어는 소프트웨어가 사양에서 계획된 사항을 준수하는지 확인하고, 그들이 하는 방법은 "테스트"입니다.

소프트웨어가 검증되면 모든 사양을 충족하는 것으로 가정하고 검증 주기가 마지막으로 반복됩니다. 올바른 유효성 검사를 확인하기 위해.

위에서 설명한 것은 불일치라는 큰 문제가 있습니다. 아래에서 설명하겠습니다.

오늘날의 소프트웨어 테스트 오류 및 불일치

현재 검증 방법 "테스트"의 가장 중요한 문제는 소프트웨어가 다음을 준수하는지 확인하지 않는다는 것입니다. 사양에 나와 있습니다. 사양의 초안은 항상 개별 해석 경향이 있는 용어와 함께 자연어로 이루어지기 때문입니다. 이는 프로젝트가 끝날 때 분명히 알게 될 모호성을 생성합니다.

두 번째 문제는 가능한 모든 경우를 테스트할 수는 없습니다.. 다음과 같은 작은 소프트웨어가 있다고 가정합니다.

• 임의의 숫자를 입력으로 받고,
• 10을 더하고
• 결과로 합계 값을 반환합니다.

입력 데이터가 무한하므로 가능한 모든 경우를 테스트하는 것은 불가능합니다. 이것이 소프트웨어 테스트가 때때로 매우 작은 샘플인 선택된 사례의 샘플에서만 실행되는 이유입니다. 이러한 나쁜 관행의 이유는 재정적 및 시간적 제약으로 인해 정당화됩니다. 결론적으로, 그러한 주장에 대한 증거가 충분하지 않기 때문에 테스트 단계를 완료한 후 소프트웨어가 정확하다고 말할 수 없습니다.

우리가 소프트웨어가 옳다는 것을 확인함으로써 (우리가 컴퓨팅 분야에 전념한다면) 논리적이 되려고 노력한다면 테스트 단계를 완료하고 오류를 찾지 못한 후 다음과 같은 문제가 발생합니다. “무지에 대한 부름의 오류”.

논리학에서는 무지에 대한 부름이라고도 알려진 논증 ad ignorantiam 또는 논증 ad ignorantiam, 반대의 증거가 없다고 주장하는 명제의 참(또는 거짓)을 유지하는 것으로 구성된 오류입니다. 또는 상대방이 반대에 대한 설득력 있는 증거를 제시할 수 없거나 거부한다고 주장하는 것. 모호함에 대한 이러한 조바심은 종종 다음과 같은 문구로 비판을 받습니다. "증거의 부재는 부재의 증거가 아니다" 즉, 이 오류는 범해진다. 명제의 참 또는 거짓이 그것에 대한 기존의 무지에 기초하여 추론될 때. 무지에 대한 부름의 오류

눈치채셨겠지만, 우리는 소프트웨어 테스트를 전통적인 방식으로 적용할 때 많은 실수를 범합니다. 이로 인해 발생하는 비용을 알지 못합니다.

아이디어를 제공하기 위해:

• 소프트웨어 테스트의 기존 방법은 소프트웨어의 결함을 감지하는 것입니다.
• 그 후, 디버깅 단계, 즉 오류의 원인을 이해하기 위해 코드를 검토하는 단계에 들어갑니다. 마지막으로 소프트웨어 결함을 수정합니다.
• 이러한 방식으로 작업하는 프로그래머는 평균적으로 자신의 오류를 디버깅하는 데 시간의 49.9%를 보냅니다.
• 이는 연간 1560억 달러의 전 세계 지출을 의미합니다.

일관성 없는 소프트웨어 테스트에 대한 제안된 솔루션으로 공식 개발

우리가 이미 보았듯이 주요 문제 중 하나는 사양의 모호성입니다. 정확성과 논리적 수학적 감각이 부족합니다. 한 가지 해결책은 모호함의 여지가 없는 형식적인 언어를 사용하는 것입니다.

우리의 소프트웨어 프로젝트 개발을 위한 공식적인 방법을 사용함으로써, 소프트웨어의 속성 및/또는 기능의 확실성은 연역, 즉 수학(p -> q)을 통해 보장됩니다.

이 형식적인 방법은 준비에 훨씬 더 많은 시간과 예산이 필요합니다. 사양을 정교화하는 데 훨씬 더 많은 정밀도가 필요하기 때문에 코드를 작성할 때 사양을 기반으로 신뢰성을 입증할 수 있도록 모호성을 제거해야 하기 때문입니다.

양질의 소프트웨어를 만들기 위해 이러한 수요의 한계에 도달하는 것은 현실과는 거리가 먼 것 같습니다. 그러나 현재 공식 개발을 기반으로 시스템을 구축하는 회사가 있으며 일반적으로 작은 오류로 인해 즉시 인명 손실이 발생할 수 있는 중요한 영역에 전념하는 회사가 있습니다.

그러나 소규모에서는 이러한 수준의 수요가 수익성이 없습니다. 최소한 기존의 테스트를 준수해야 합니다.

아래에서 양질의 프로젝트를 개발하려는 경우 놓치지 말아야 할 일련의 우수 사례를 공유합니다.

지속적인 학습은 우리 뇌에 어떤 이점이 있습니까?

학습은 뇌의 연료와 같습니다.

대학에서 우리는 끊임없이 공부를 희생했지만 그 어느 것도 충분하지 않았습니다. 공부한 경력과 상관없이 1분마다 새로운 정보가 나오기 때문입니다.

항상 새로운 것을 배울 것입니다.

명심해야 할 것은 우리가 학습할 때 우리의 뇌는 신경 구조의 변화에 ​​영향을 받는다는 것입니다.

현대 연구에 따르면 뇌는 영구적으로 변화하고 변형하는 능력을 가지고 있습니다. (가소성), 그리고 어린이뿐만 아니라 성인에게도.

이러한 뇌의 변화는 다음으로 인해 발생할 수 있습니다. 지속적인 학습의 모범 사례, 시냅스 연결을 재구성하고 때로는 새로운 연결을 만듭니다.

이전에는 사람의 뇌가 크거나 무거울수록 지능이 높다고 믿었습니다. 그러나 최근 연구에 따르면 IQ가 높은 사람들은 신경망이 덜 조밀하지만 동시에 훨씬 더 조직화되어 있습니다.

이 연구를 위해 IQ는 다음 요인에 따라 계산되었습니다.

• 분석 능력
• 반사 능력
• 문제 해결

다음은 해당 연구에 대한 추가 정보입니다.

지능은 신경 효율성을 기반으로 합니다. - Erhan Genç

Erhan Genç가 이끄는 팀은 18세에서 40세 사이의 건강한 남녀 259명의 뇌를 분석했습니다. 대뇌피질의 수상돌기, 즉 세포들이 지능을 발휘할 때 서로 통신하는 데 사용했던 신경세포의 확장을 측정하기 위해.

연구에 앞서 모든 참가자는 IQ 테스트를 받았습니다. 수상 돌기를 연구한 후, IQ가 높을수록 대뇌 피질에 있는 수상돌기가 더 적은 것으로 결정되었습니다.

즉, 똑똑한 사람들은 더 많은 뉴런을 가질 뿐만 아니라 뉴런 간의 수지상 연결도 더 적다고 결론지었습니다. 인지시. 이는 그들이 덜 조밀한 신경망을 가지고 있음을 의미합니다.

이 연구는 500명의 표본으로 검증되었으며 동일한 결론에 도달했습니다.

연구의 주저자인 Erhan Genç는 다음과 같이 결론지었습니다.

지능적인 두뇌는 얇지만 매우 효율적인 신경망이 특징입니다. 이것은 신경 활동을 최소화하면서 높은 수준의 사고를 달성하는 데 도움이 됩니다. Erhan Genç

프로그래밍은 우리의 정신 능력에 어떤 영향을 미칩니까?

이전 단락에서 이미 언급했듯이, 프로그래밍은 그것을 실행하는 사람들의 사고 방식에 영향을 미치고, 그런 의미에서 그것은 우리의 정신 능력.

그러나 어떤 방식으로 합니까? 봅시다.

프로그래머는 다른 사람들과 매우 다르게 생각합니다., 반드시 그런 것은 아니지만 일반적으로 평균보다 논리적이고 합리적인 경향이 있기 때문입니다.

우리는 프로그래밍을 배우기로 결정했기 때문에 시작할 언어를 선택해야 합니다. 그러한 선택이 완전히 사실은 아니지만, 일반적으로 대다수가 소프트웨어 개발의 세계에 헌신하는 사람들 중 경험 없이 우리의 모국어를 선택하거나 강제된 프로그래밍 언어로 시작하도록 강요당했습니다. 대학 및 / 또는 대학의 교사.

그러나 이러한 제한은 인터넷에서 찾을 수 있는 정보의 양으로 인해 점점 줄어들고 있습니다. 독학 학습의 높은 인센티브와 촉진.

프로그래밍 언어의 패러다임은 이미 많은 사람들의 마음을 형성했습니다, 어떤 경우에는 시작 언어에 따라 다른 것보다 더 많은 제한이 있습니다. 이것은 당신의 모국어가 당신의 성공이나 실패를 정의한다는 것을 의미하지는 않지만, 프로그래밍의 세계에서 시작하는 패러다임은 우리의 생각에 패턴을 삽입합니다..

아래에서 언급하겠습니다 프로그래밍이 뇌에 영향을 미치는 3가지 방법:

1. 프로그래밍에 사용하는 도구는 정신 모델에 영향을 미칩니다.

우리가 시작한 프로그래밍 언어는 사고 방식에 직접적인 영향을 미치는 패러다임과 관용구가 수반되는 도구에 불과합니다. 아무렇지 않게, 에즈거

분산 프로그래밍의 선구자 중 한 명인 Dijkstra는 다음과 같이 말했습니다.

우리가 사용하는 도구는 우리의 사고 습관 그리고, 그러므로 우리의 생각하는 기술. Edsger Dijkstra

이제 우리가 시작하는 프로그래밍 언어가 얼마나 중요한지, 그리고 일반적으로 프로그래밍할 때 사용하는 모든 도구 집합이 얼마나 중요한지 알았으므로 첫 번째 프로그래밍 언어를 선택할 때 가장 먼저 고려해야 할 사항은 편안함입니다.

이제 막 시작했다면 돈에 현혹되지 마십시오. 다른 것보다 더 많은 돈을 받는 프로그래밍 언어가 있는 것은 사실이지만, 돈이 목표가 되어서는 안 됩니다. 그렇다면 COBOL, PASCAL, FORTRAN, 문서가 거의 없고 현재 실행하는 언어가 거의 없는 언어로 프로그래밍을 시작하는 것이 좋습니다. 이것이 필요한 곳에서 매우 높은 급여를 받는 이유입니다.

실제로 소프트웨어 개발에 전념하면 사고 습관과 인지 능력에 도움이 될 뿐만 아니라 현재 성장하고 있는 고소득 분야이기 때문에 안정적인 경제적 미래 이상을 보장할 수 있습니다.

오늘이 시작하기에 가장 좋은 시간입니다. 그 이유를 살펴보겠습니다.

2021년 IT 분야가 가장 추천되는 분야 중 하나인 이유는 무엇입니까?

라틴 아메리카 및 카리브해 경제 위원회(ECLAC)에 따르면 라틴 아메리카 국가는 2021 년 경기 침체 이후 성장을 시작할 것입니다.

2021년에는 3.7%의 성장이 예상되며, 주요 주인공은 디지털 세계에 전념하는 사람들이 될 것입니다..

2. 뇌에 건강하다

이미 언급했듯이 학습은 뇌에 긍정적인 영향을 미칩니다. 이런 의미에서 프로그래밍은 두뇌에 직접적으로 도움이 되는 정신적 운동으로 간주됩니다.

프로그래밍이 두뇌 ​​건강에 미치는 이점을 확인하는 몇 가지 배경을 살펴보겠습니다.

1991년 조사에서 인지 결과에 대한 컴퓨터 프로그래밍의 영향을 연구하고 다음과 같이 결정했습니다. 프로그래밍 관련 분야의 학생들은 IQ 테스트에서 평균보다 16백분위수 더 높은 점수를 얻습니다..

1999년의 또 다른 대규모 연구는 지적으로 참여하는 활동이 인지 저하로부터 개인을 완충하는 역할을 한다는 것을 확인했습니다.

2009년 후반에 한 연구에 따르면 노년에 뇌 자극 활동에 참여하는 사람들이 위험을 낮추고 알츠하이머 및 기타 유형의 치매 발병을 지연시킬 수도 있습니다.

3. 프로그래밍하는 동안 뇌의 최대 5개 영역을 자극합니다.

2014년에 “기능적 자기 공명 영상을 통한 소스 코드 이해” 프로그래머가 작업하고 코드 비트를 이해하려고 할 때 두뇌 활동을 관찰하기 위해 기능적 자기 공명 영상 스캔을 사용했습니다.

뇌의 5개 영역이 관련되어 있다고 결론지었습니다.

• BA 6: 중전두이랑(주의, 언어, 작업기억)
• BA 21: 평균 측두회(의미 기억 검색)
• BA 40: 하부두정엽(작업기억)
• BA 44: 하전두이랑(작업기억)
• BA 47: 하전두이랑(언어, 작업 기억)

참가자는 20줄의 코드 조각을 검토해야 했으며 이는 큰 도전이 아닙니다. 그리고 이것이 수학 계산과 관련된 뇌 영역에서 활동이 감지되지 않은 이유입니다.

알아차릴 수 있었던 것은 일반적으로 언어 처리, 기억 및 주의력과 관련된 뇌 부분의 높은 개입이었습니다.

프로그래밍은 초능력에 가장 가까운 것입니다. Drew Houston, 드롭박스 CEO