코드 작성을 시작하기 전에 프로그래머가 알고리즘을 설계하는 것이 더 좋은 이유는 무엇입니까?

적절한 알고리즘이 프로그램의 품질과 궁극적으로 효율성을 향상시키는 데 실제로 도움이됩니까?

알고리즘 없이도 양질의 프로그램을 만들 수 있습니까?

최신 프로그래밍에서 적절한 알고리즘이 필수입니까?

나는이 질문이 역사적 관점을 구걸한다고 생각한다.

"오래된 시절"(이것은 개인적 증인이 아니기 때문에 지금은 그 시대의 나의 재구성 일뿐입니다. 상황을 다르게 경험하면 자유롭게 시정하십시오) HW 공간과 성능은 오늘날과 비교할 때 나빴습니다. 그래서 사람들이 작성한 모든 것이 매우 효율적이어야했습니다. 따라서 그들은 작업을 수행하는 데 필요한 공간 / 시간 성능을 달성하기 위해 최고의 알고리즘을 발명하기 위해 많은 것을 생각하고 연구해야했습니다. 이것의 또 다른 요인은 개발자가 주로 인프라 라고 부르는 것 , 즉 운영 체제, 프로토콜 스택, 컴파일러, 장치 드라이버, 편집기 등에서 작업하고 있다는 것입니다.이 모두는 많은 사람들이 많이 사용하므로 성능이 실제로 차이를 만듭니다 .

오늘날 우리는 심지어 기본 랩탑 (휴대 전화에서도)에서 멀티 코어 프로세서와 기가 바이트의 메모리로 놀라운 HW를 겪고 있습니다. 이는 당연히 많은 경우에있어서 성능-따라서 알고리즘이 중심 문제가되지 않음을 의미하며 빠른 솔루션을 제공하는 것보다 빠른 솔루션을 제공하는 것이 더 중요합니다. OTOH에는 수많은 프레임 워크가있어 문제를 해결 하고 동시에 많은 수의 알고리즘 을 캡슐화합니다 . 따라서 알고리즘에 대해 생각하지 않아도 백그라운드에서 많은 알고리즘을 사용하고있을 수 있습니다.

그러나 여전히 성능이 중요한 영역이 있습니다. 이 영역에서는 코드를 작성하기 전에 알고리즘에 대해 많은 생각을해야합니다. 그 이유는 알고리즘이 디자인의 중심이기 때문에 주변 코드에서 많은 데이터 구조와 관계를 결정하기 때문입니다. 그리고 알고리즘이 제대로 확장되지 않았다는 것을 너무 늦게 알게되면 (예를 들어 O (n ³ ) 그래서 10 개의 항목에서 테스트 할 때 멋지고 빠르지 만 실제로는 수백만을 가질 것입니다) 단단하고 오류가 발생하기 쉽고 생산 코드에서이를 대체하는 데 많은 시간이 소요됩니다. 기본 알고리즘이 적합하지 않은 경우 마이크로 최적화는 도움이되지 않습니다.

무언가를 지적하기 위해 :

알고리즘 자체는 문제의 일반적인 단계별 솔루션입니다. 따라서 문제를 해결 한 경우 실제로 알고리즘을 사용했습니다.

여기서 가장 중요한 점은 알고리즘을 사용하여 문제를 해결해야한다는 것입니다. 대부분 코딩으로 넘어 가기 전에 문제에 대해 생각하는 것이 좋습니다.이 단계를 종종 디자인이라고합니다. 그러나 얼마나 많은 방법으로 당신이 이것을 할 것인가는 당신에게 달려 있습니다.

또한 알고리즘 개념을 플로우 차트 와 혼합해서는 안됩니다 (여기서 진행되고있는 것 같습니다). 순서도는 하나의 그래픽 표현 일 뿐이며 알고리즘을 설명하기 위해 옛날에 사용되었습니다. 요즘에는 거의 사용되지 않습니다.

편집하다:

실제로 알고리즘을 표현하는 방법은 여러 가지가 있으며 프로그래밍 언어 코드 자체도 그 중 하나입니다. 그러나 종종 전체 문제를 한 번에 해결하지 않고 개요 만 작성한 다음 빈 칸을 채우는 것이 훨씬 낫거나 쉽습니다.

• 내가 개인적으로 가장 좋아하는 것은 의사 코드이며, 문제의 알고리즘에 대한 일반적인 추상 개요 만 다루기 위해 pseudocode 로 세부 정보를 얻는 것은 어리석은 일입니다. 실제 코드입니다.

• 그러나 개요에는 실제 코드를 사용할 수 있습니다. 예를 들어, TDD 사람들은 코딩 할 때 알고리즘을 설계하는 것을 좋아하며, 한 번에 해결할 수 없기 때문에 실제 코드에서 프로그램 실행의 개요를 설계하고 모의 객체 (또는 함수, 메소드)를 사용합니다. .) 나중에 채울 공백으로.

• UML 활동 다이어그램 은 다형성 및 멀티 스레딩과 같은 새로운 항목에 대한 표기법이 추가 된 구식 플로우 차트의 현대적인 구현으로 보입니다. 나는 실제로 그것들을 많이 사용하지 않았기 때문에 이것이 얼마나 유용한 지 말할 수 없다. 나는 완전성을 위해 그것을 언급하고있다.

• 또한 상태를 전환하는 알고리즘을 기반으로하는 경우 상태 다이어그램 이 매우 유용합니다.

• 일반적으로 특정 알고리즘 뒤에 아이디어 를 스케치 해야한다는 의미 는 좋은 방법입니다.

좋은 비유는 요리를 시작하기 전에 레시피를 알아야한다는 것입니다. 좋아, 당신이 갈 때 그것을 조정할 수 있지만 시작하기 전에 원하는 것을 여전히 알아야합니다. 양고기 스튜를 만들고 싶다면 빵 한 덩어리를 굽는 것과는 다른 일을 할 것입니다.

코드는 알고리즘을 구현합니다. 알고리즘을 설계하지 않고 코드를 작성하는 것은 벽을 만들기 전에 집을 페인트하는 것과 같습니다. 알고리즘은 프로그래밍 초기부터 "MUST"였습니다.

귀하의 언어에 능통하면 품질과 생산성을 향상시키는 데 도움이됩니다. 작은 알고리즘 문제를 해결하는 것은 동일한 MVC를 100 번 반복하는 것보다 훨씬 유용합니다.
유창함을 얻는 다른 방법이 있다고 생각합니다.

현대 프로그래밍 영역에서 알고리즘이 필수가됩니까?
'cool codez'를 작성하는 'php ninja'이 아닌 한 이미 '필수'입니다. 모든 '최고의'회사 (Google, Amazon 등)는 인터뷰에서 알고리즘 경험을 테스트하므로 아무 이유없이 그렇게하지 않을 것입니다.

그러나 원래 시점으로 돌아가서 개선하고 싶다면 끊임없이 도전해야합니다. 그리고 일반적인 작업 (현재 "100 개 이상의 객체에 대한 CRUD 관리자 작성")이 항상 좋은 과제를 제공하지는 않으므로 알고리즘이이를 보완합니다.

코딩을 시작하기 전에 최소한 알고리즘에 대한 아이디어가 필요하다고 말하고 싶습니다. 데이터 구조 등을 기반으로 코딩하는 동안 아이디어를 수정하게 될 것입니다.

프로파일 링에서 해당 영역에 성능 문제가 있음을 제안하면 나중에 코드를 다시 수정할 수 있습니다.

잘못된 코드를 작성하기 전에 실수를 수정하는 것이 더 빠르기 때문입니다.

보다 유망하게도, 서로 다른 프로그래머들 사이에서 10 대 1의 생산성 차이가 일상적으로 측정됩니다. 생산성이 10 배 수준 인 프로그래머를 보면 실제로 코딩하는 데 가장 적은 시간 을 소비합니다 . 코드 입력 시간이 병목 현상이되어서는 안됩니다. 대신, 요구 사항을 직선, 계획, 테스트 등을 수행하는 데 많은 시간을 소비합니다.

반대로, 일시 정지없이 코딩을하는 프로그래머를 살펴보면, 예측 가능한 문제가 발생할 때 필연적으로 코드를 반복해서 작성해야하며, 최종 결과는 유지 관리가 쉽고 버그가 많습니다. (우연히 당신은 소프트웨어 개발에 소비되는 돈의 평균 80 %가 유지 보수 단계에 있다는 것을 알고 있었습니까?

일반적으로 알고리즘과 데이터 구조가 먼저 코드화됩니다. 그러나 그것은 프로그래밍 영역에 많이 의존합니다. 나는 많은 응용 수학 형식 작업을 수행했으며 실제로 당시의 폭포 모델을 내려다 보았습니다. 낮은 수준에서 중간 수준의 알고리즘을 당연한 것으로 간주 할 수 없었기 때문입니다. 쓰지 않은 서브 시스템의 존재를 중심으로 큰 구조를 설계 한 다음 게임에서 후반에 중요한 서브 시스템 중 하나에 대한 수학이 제대로 수행되지 않는다는 것을 발견하십시오. 그래서 나는 항상 가장 도전적인 하위 시스템에 대해 먼저 생각했고, 의심 할만한 이유가 있다면, 먼저 그것들을 작성하고 테스트했습니다. 그러나 일부 문제 영역의 경우 많은 계획 없이도 계속 진행할 수 있습니다.

섹션에서 알고리즘을 디자인 한 다음 해당 섹션을 분할하고 각 섹션을 개별적으로 코딩하십시오. 이렇게하면 두 가지 관점을 혼합 할 수 있습니다.

1. 언어 기능을 사용하여 알고리즘 작동
2. 코드를 생각하기 전에 아이디어를 언어와 통합하지 마십시오. 언젠가 알고리즘을 다른 언어로 이동해야합니다.

나를 위해, 그것은 거의 모든 코드입니다. 생산성이 가장 높은 프로그래머에게는 이것이 사실이라고 생각합니다. 텍스트를 작성하는 것만 큼 쉽게 코드를 작성할 수 있습니다.

가능한 한 요구 사항을 실행 가능한 테스트 (코드)로 캡처하려고합니다. 디자인은 단지 고급 코딩입니다. 대상 언어로 디자인을 캡처하여 다른 형식으로 디자인 한 다음 번역하는 것이 더 빠르고 정확합니다.

대부분의 사용자가 텍스트 요구 사항을 효과적으로 검토 할 수 없다는 것을 알게되었습니다. 순차적 사용 사례에서는 문제가 없지만 사용 사례는 UI의 모든 측면을 캡처 할 수 없습니다. 가장 좋은 점은 구현시 첫 번째 작업을 수행하고 사용자가 시도하고 의견을 얻고 그에 따라 코드를 수정하도록하는 것입니다.

앉아서 코딩을 시작하면 "디자인"여부에 관계없이 알고리즘을 염두에 두어야합니다.

완전한 알고리즘을 염두에두고 앉아 코딩을 시작하면 다음 중 하나를 수행하게됩니다.

1) 키를 무작위로 으 깨기. 아마도 컴파일러 오류가 발생합니다.

2) 원하는 것을 제외하고는 아무것도 할 수있는 컴파일 가능한 코드 작성

3) 문제의 작은 부분을 해결하기 위해 코드를 작성하고 집계 방식으로 진행할 때 코드를 작성하지만 실제로 생각하지는 않습니다. 따라서 결국 문제가 해결됩니다. 그러나 코드는 매우 효율적이지 않으며 역 추적 및 시간 낭비 가능성

따라서 사람들은 보통 머리에 알고리즘을 사용하여 프로그래밍합니다. 그것은 종이나 다른 매체에 반해 있거나 추론되었을 수 있습니다.

키보드에서 떨어진 문제, 특히 프로그래머로서의 초기에 대한 공격에 대해 생각하는 것은 좋은 훈련이 될 수 있습니다. 다른 답변에서 알 수 있듯이, 경험이 많을수록 "즉석에서"좀 더 다루기 쉬운 문제를 더 잘 코딩 할 수 있습니다. 그러나 어렵거나 큰 문제의 경우 키보드에서 생각하고 디자인하는 것이 유용합니다. 코드와 관련하여 언어 구성과 관련하여 가장 즉각적인 작업에 접근하는 방법에 대해 생각할 가능성이 높습니다. 문제. 예를 들어, 펜과 종이의 문제에 대해 생각하면 코드의 언어 측면에서 더 많은 자유를 얻게되고보다 추상적 인 수준에서 생각할 수 있습니다.

소프트웨어 구축을 근본적으로 가치있는 것의 구축에서 무언가로 보는 것을 그만 둘 필요가 있습니다. 그렇지 않습니다. 따라서, 다른 어떤 것과 마찬가지로, 간결한 계획이나 디자인은 항상 필요합니다.

적절한 알고리즘이 프로그램의 품질과 궁극적으로 효율성을 향상시키는 데 실제로 도움이됩니까?

적절한 건축 계획 / 도식이 양질의 주택을 효율적으로 건설하는 데 도움이됩니까?

알고리즘 없이도 양질의 프로그램을 만들 수 있습니까?

적절한 건축 계획없이 양질의 주택을 효율적으로 건설 할 수 있습니까? 당으로 무한 원숭이 정리 , 확률, 영원을 위해 무작위로 입력 그래 (단지 백만 같은 원숭이는 결국 셰익스피어의 전집을 입력합니다.

최신 프로그래밍에서 적절한 알고리즘이 필수입니까?

코드 원숭이가되고 싶지 않고 똥처럼 보이고 작동하는 소프트웨어를 제공하지 않으려면 반드시 그래야합니다. 코드를 유지하기 어려운 것처럼 보이기 때문에 내가 구해야했던 모든 프로젝트는 그 질문에 대한 부정적인 대답으로 시작했습니다.

사실, 현대 프로그래밍은 카우보이 프로그래밍 소프트웨어 엔지니어로부터 멀어졌으며, 필요한 경우 일종의 계획 을 세웠습니다 .

알고리즘 및 데이터 구조 라이브러리 (예 : C ++ 또는 Java 컬렉션 라이브러리의 Boost)가있는 경우에도 해당 알고리즘을 적절하게 사용하고 합리적이고 높은 수준으로 구성하는 방법을 알아야합니다. 레벨 알고리즘.

더 좋지 않습니다. 아무것도 "디자인"하지 않는 것이 좋습니다. 그것은 프로그램을 쓰지 않는 사람들을위한 것입니다. 문제의 실제 경험이있는 사람들은 알고 있습니다. 수학자, 엔지니어 또는 물류 전문가라면 다른 곳에서 프로세스를 수행해야합니다. 그러나 그것은 '프로그래밍'이 아닙니다.

먼저 일종의 테스트 및 벤치 마크를 수행하십시오.

그런 다음 무엇이든 쓰십시오. 시간이 부족하거나 더 이상 개선 할 수 없을 때까지 refactor-rewrite -loop를 수행하십시오.

많은 사람들이 실제로 컴퓨터에서 아무것도하지 않고 컴퓨터로 일을 할 수 있다고 생각하는 것 같지만, 이것이 가장 일반적인 신화 중 하나라고 생각합니다. 건축 우주 비행사.

또한 Algo를 작성하기 전에 최적화 할 수 없습니다.

IOW, "금속에 가까이 머 무르십시오".