" 80년대 중반 이후로 OOP에 대한 몇 가지 미신이 있었습니다. 그 중 하나인 Reuse Myth 는 OOP를 사용하면 매번 다시 작성하는 대신 현재 코드를 상속하고 확장할 수 있기 때문에 개발을 보다 생산적으로 수행할 수 있다고 말합니다. 또 다른 하나는 분석, 설계 및 구현 이 모두 객체 이기 때문에 서로 매끄럽게 흐름을 의미하는 디자인 에 대한 신화입니다. 물론 이러한 신화 중 어느 것도 OOP 패러다임이 될 수 없습니다."
Боже, временами я просто ненавижу объектно-ориентированное программирование. Наверное, я не один такой. Бессмертные слова Эдсгера Дейкстры гласят: «Объектно-ориентрованное программирование — это исключительно плохая идея, которую могли придумать только в Калифорнии.” Обычно я не жалуюсь, но сейчас, думаю, самое время оглянуться назад и...
삼촌은 대부분의 학문적 환경과 마찬가지로 이론가이자 발라볼입니다. 그리고 그가 교수(제목이 부풀려진 지 오래다)이자 책의 저자인 것은 중요하지 않습니다.
이 뒤죽박죽 엉뚱한 말은 오랫동안 존재해 왔으며 소프트웨어 제품의 복잡성이 기하급수적 으로 증가하는 것을 완전히 무시합니다. 30-20-10년 전에 일어난 일은 현재 프로젝트의 규모와 복잡성과 결코 비교할 수 없습니다. 그리고 그들은 여전히 샌드박스에서 노는 것을 선호하여 모델로 축소합니다.
그를 심어서 자원, 경제 및 경쟁력있는 요구 사항을 포함하여 많은 요구 사항이 있는 실제 제품을 만들 수 있습니다. 그는 즉시 자신의 추론과 병합하여 가능한 모든 것을 실패합니다. 오히려 해법을 찾는 단계에서 어린이 주장 자리에서 쫓겨나기도 한다.
세계는 수많은 은탄을 시도했지만 모두 사용할 수 없는 것으로 밝혀졌고 오랫동안 폐기되었습니다. 복잡성이 지속적으로 증가하고 라이브러리(및 oop가 있음) 및 프레임워크(및 oop가 있음)가 계속해서 증가하므로 어떻게든 복잡성을 제어할 수 있습니다.
그리고 복잡성의 증가에서 벗어날 수 없습니다. 지식의 질에 대한 요구 사항을 따라갈 수없는 문맹 개발자는 훨씬 더 어려울 것입니다.
점점 낮아지고 있는 프로그래머의 수준에 맞추기 위해 더 간단한 언어를 만들려는 시도가 더 많이 있을 것입니다. 점점 더 많은 소프트웨어 회사가 단순히 잘못된 기술을 믿고 경쟁에서 지고 아무것도 없는 자신을 발견하게 될 것입니다. 그들의 경쟁자들은 제품 결과 측면에서 더 무겁지만 더 효율적인 기술을 사용할 것입니다.
오랫동안 소프트웨어 회사에 대한 투자는 치명적인 일이었습니다. 사망률과 실패는 놀랍고 더 나빠질 것입니다.
왜요? 예, 이것은 기술자가 아닌 경제적 요구 사항이 많은 비즈니스이기 때문입니다. 라이브 및 상설 소프트웨어 회사의 80%는 마케팅 및 영업으로 구성됩니다. 그리고 잘못 선택된 기술(여기서는 대다수가 단순성보다 우선권을 가짐)은 후속 판매를 쉽게 죽입니다. 결승에서 더 열심히 달려서 더 좋은 결과를 얻은 선수들이 항상 있기 때문이다.
이제 최대 수십만 라인의 마이크로 프로젝트에 대해 설명합니다. 이것은 한 사람의 머리에 맞고 그에게 통제의 환상을 유지할 수있는 기회가 있기 때문에 무엇이든 할 수 있습니다. 확장을 시도할 때 - 고통, 실망 및 죽음.
결과:
프로젝트의 복잡성이 증가하고 있으며 계속 증가할 것입니다.
많은 새로운 아이디어와 접근 방식이 결과를 제공하지 않고 죽을 것입니다.
소프트웨어의 대부분은 작성되었으며 oop, hard 및 고뇌로 작성됩니다.
소프트웨어 스타트업에 대한 투자는 실패 비율이 증가할 것입니다. 교수가 할 일이 없는 사업이다.
삼촌은 대부분의 학문적 환경과 마찬가지로 이론가이자 발라볼입니다. 그리고 그가 교수(제목이 부풀려진 지 오래다)이자 책의 저자인 것은 중요하지 않습니다.
이 뒤죽박죽 엉뚱한 말은 오랫동안 존재해 왔으며 소프트웨어 제품의 복잡성이 기하급수적으로 증가하는 것을 완전히 무시합니다. 30-20-10년 전에 일어난 일은 현재 프로젝트의 규모와 복잡성과 결코 비교할 수 없습니다. 그리고 그들은 여전히 샌드박스에서 노는 것을 선호하여 모델로 축소합니다.
그를 심어서 자원, 경제 및 경쟁력있는 요구 사항을 포함하여 많은 요구 사항이 있는 실제 제품을 만들 수 있습니다. 그는 즉시 자신의 추론과 병합하여 가능한 모든 것을 실패합니다. 오히려 해법을 찾는 단계에서 어린이 주장 자리에서 쫓겨나기도 한다.
세계는 수많은 은탄을 시도했지만 모두 사용할 수 없는 것으로 밝혀져 오랫동안 폐기되었습니다. 복잡성이 지속적으로 증가하고 라이브러리(및 oop가 있음) 및 프레임워크(및 oop가 있음)가 계속해서 증가하므로 어떻게든 복잡성을 제어할 수 있습니다.
그리고 복잡성의 증가에서 벗어날 수 없습니다. 지식의 질에 대한 요구 사항을 따라갈 수없는 문맹 개발자는 훨씬 더 어려울 것입니다.
점점 낮아지고 있는 프로그래머의 수준에 맞추기 위해 더 간단한 언어를 만들려는 시도가 더 많이 있을 것입니다. 점점 더 많은 소프트웨어 회사가 단순히 잘못된 기술을 믿고 경쟁에서 지고 아무것도 없는 자신을 발견하게 될 것입니다. 그들의 경쟁자들은 제품 결과의 관점에서 더 무겁지만 더 효율적인 기술을 사용할 것입니다.
오랫동안 소프트웨어 회사에 대한 투자는 치명적인 일이었습니다. 사망률과 실패는 놀랍고 더 나빠질 것입니다.
왜요? 예, 이것은 기술자가 아닌 경제적 요구 사항이 많은 비즈니스이기 때문입니다. 라이브 및 상설 소프트웨어 회사의 80%는 마케팅 및 영업으로 구성됩니다. 그리고 잘못 선택된 기술(여기서는 대다수가 단순성보다 우선권을 가짐)은 후속 판매를 쉽게 죽입니다. 결승에서 더 열심히 달려서 더 좋은 결과를 얻은 선수들이 항상 있기 때문이다.
이제 최대 수십만 라인의 마이크로 프로젝트에 대해 설명합니다. 이것은 한 사람의 머리에 맞고 그에게 통제의 환상을 유지할 수있는 기회가 있기 때문에 무엇이든 할 수 있습니다. 확장을 시도할 때 - 고통, 실망 및 죽음.
결과:
프로젝트의 복잡성이 증가하고 있으며 계속 증가할 것입니다.
많은 새로운 아이디어와 접근 방식이 결과를 제공하지 않고 죽을 것입니다.
소프트웨어의 대부분은 작성되었으며 oop, hard 및 고뇌로 작성됩니다.
소프트웨어 스타트업에 대한 투자는 실패 비율이 증가할 것입니다. 교수가 할 일이 없는 사업이다.
탈출구는 없고 고통과 고통만 있을 뿐
이달의 베스트 포스트, 아마도 올해! Renat, 당신이나 당신의 회사는 Habré에 대한 기사를 작성하지 않겠습니까( 회사는 등록되지도 않았습니다! )? 당신은 많은 것을 말할 수 있지만, 당신의 경험은 게시물의 스니펫에서만 배울 수 있습니다. 진지하게, 매우 화제가 되었고 확실히 밝혀졌습니다. 게시물에 대한 설명: https://habrahabr.ru/post/344356/
На протяжении последних месяцев я использую Go для имплементаций Proof of Concept (прим.пер.: код для проверки работоспособности идеи) в свободное время, отчасти для изучения самого языка программирования. Программы сами по себе очень просты и не являются целью написания статьи, но сам опыт использования Go заслуживает того, чтобы сказать о нем...
이달의 베스트 포스트, 어쩌면 올해의 베스트 포스트! Renat, 당신이나 당신 의 회사는 Habré에 대한 기사를 쓰지 않겠습니까? 당신은 많은 것을 말할 수 있지만, 당신의 경험은 게시물의 스니펫에서만 배울 수 있습니다. 진지하게, 매우 화제가 되었고 확실히 밝혀졌습니다. 게시물에 대한 설명: https://habrahabr.ru/post/344356/
우리는 Habré에 대한 기사가 일반적으로 얻는 1,000 - 5,000명의 독자/뷰가 아니라 수백만 명을 위해 일합니다.
우리는 업계 표준을 만들고 전 세계에 영향을 미치는 솔루션을 출시하고 있습니다. 왜 우리는 어떤 종류의 Habr이 필요하고 심지어 러시아 세그먼트의 좁은 틈새 시장에 끼어 있습니다.
공리가 있습니다. 복잡성은 어디에도 사라지지 않습니다 . 따라서 사용자를 위한 "프로그래밍의 단순성"은 복잡성을 컴파일러로 이동시키는 것입니다. 복잡성은 말하자면 컴파일러에 의해 무대 뒤에서 처리되고 컴파일러는 이미 "전혀 그렇지 않은 것보다 적어도 어떻게든 작동하게 하는 것이 낫다"는 원칙에 따라 프로그래머의 변태를 숨기려고 시도하고 있습니다. ." 프로젝트 소유자는 더 이상 프로그래머가 아니라 컴파일러입니다. 무슨 일이 일어나고 있는지 더 이상 명확하지 않기 때문에 코드를 개발하고 유지하는 것이 불가능해집니다.
그리고 복잡성의 증가에서 벗어날 수 없습니다. 지식의 질에 대한 요구 사항을 따라갈 수없는 문맹 개발자는 훨씬 더 어려울 것입니다.
점점 낮아지고 있는 프로그래머의 수준에 맞추기 위해 더 간단한 언어를 만들려는 시도가 더 많이 있을 것입니다. 점점 더 많은 소프트웨어 회사가 단순히 잘못된 기술을 믿고 경쟁에서 지고 아무것도 없는 자신을 발견하게 될 것입니다. 그들의 경쟁자들은 제품 결과 측면에서 더 무겁지만 더 효과적인 기술을 사용할 것입니다.
기사 가 거짓말을 하고 있다!
나는 그 기사를 더 이상 읽지 않았다. 아마도이 작성자의 넌센스는 댓글에서 즉시 지적되었을 것입니다.계속 읽으십시오. 모든 것이 있습니다.
절차적 코딩에서는 코드를 작성할 때 거의 항상 프로그램의 아키텍처에 대해 생각할 수 있습니다. 유연성과 자유로움이 완전하기 때문에
+
이것만으로도 OOP, 특히 거래와 같은 계산 알고리즘의 경우 잊어버릴 수 있습니다.
OOP의 신화에 대해 - 희미한 OOP 지지자를 위한 것이 아닙니다.
" 80년대 중반 이후로 OOP에 대한 몇 가지 미신이 있었습니다. 그 중 하나인 Reuse Myth 는 OOP를 사용하면 매번 다시 작성하는 대신 현재 코드를 상속하고 확장할 수 있기 때문에 개발을 보다 생산적으로 수행할 수 있다고 말합니다. 또 다른 하나는 분석, 설계 및 구현 이 모두 객체 이기 때문에 서로 매끄럽게 흐름을 의미하는 디자인 에 대한 신화입니다. 물론 이러한 신화 중 어느 것도 OOP 패러다임이 될 수 없습니다."
삼촌은 대부분의 학문적 환경과 마찬가지로 이론가이자 발라볼입니다. 그리고 그가 교수(제목이 부풀려진 지 오래다)이자 책의 저자인 것은 중요하지 않습니다.
이 뒤죽박죽 엉뚱한 말은 오랫동안 존재해 왔으며 소프트웨어 제품의 복잡성이 기하급수적 으로 증가하는 것을 완전히 무시합니다. 30-20-10년 전에 일어난 일은 현재 프로젝트의 규모와 복잡성과 결코 비교할 수 없습니다. 그리고 그들은 여전히 샌드박스에서 노는 것을 선호하여 모델로 축소합니다.
그를 심어서 자원, 경제 및 경쟁력있는 요구 사항을 포함하여 많은 요구 사항이 있는 실제 제품을 만들 수 있습니다. 그는 즉시 자신의 추론과 병합하여 가능한 모든 것을 실패합니다. 오히려 해법을 찾는 단계에서 어린이 주장 자리에서 쫓겨나기도 한다.
세계는 수많은 은탄을 시도했지만 모두 사용할 수 없는 것으로 밝혀졌고 오랫동안 폐기되었습니다. 복잡성이 지속적으로 증가하고 라이브러리(및 oop가 있음) 및 프레임워크(및 oop가 있음)가 계속해서 증가하므로 어떻게든 복잡성을 제어할 수 있습니다.
그리고 복잡성의 증가에서 벗어날 수 없습니다. 지식의 질에 대한 요구 사항을 따라갈 수없는 문맹 개발자는 훨씬 더 어려울 것입니다.
점점 낮아지고 있는 프로그래머의 수준에 맞추기 위해 더 간단한 언어를 만들려는 시도가 더 많이 있을 것입니다. 점점 더 많은 소프트웨어 회사가 단순히 잘못된 기술을 믿고 경쟁에서 지고 아무것도 없는 자신을 발견하게 될 것입니다. 그들의 경쟁자들은 제품 결과 측면에서 더 무겁지만 더 효율적인 기술을 사용할 것입니다.
오랫동안 소프트웨어 회사에 대한 투자는 치명적인 일이었습니다. 사망률과 실패는 놀랍고 더 나빠질 것입니다.
왜요? 예, 이것은 기술자가 아닌 경제적 요구 사항이 많은 비즈니스이기 때문입니다. 라이브 및 상설 소프트웨어 회사의 80%는 마케팅 및 영업으로 구성됩니다. 그리고 잘못 선택된 기술(여기서는 대다수가 단순성보다 우선권을 가짐)은 후속 판매를 쉽게 죽입니다. 결승에서 더 열심히 달려서 더 좋은 결과를 얻은 선수들이 항상 있기 때문이다.
이제 최대 수십만 라인의 마이크로 프로젝트에 대해 설명합니다. 이것은 한 사람의 머리에 맞고 그에게 통제의 환상을 유지할 수있는 기회가 있기 때문에 무엇이든 할 수 있습니다. 확장을 시도할 때 - 고통, 실망 및 죽음.
결과:
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
마운드에서 OOP에 대해 이야기하기
레나트 팻쿨린 , 2018.01.17 09:17
삼촌은 대부분의 학문적 환경과 마찬가지로 이론가이자 발라볼입니다. 그리고 그가 교수(제목이 부풀려진 지 오래다)이자 책의 저자인 것은 중요하지 않습니다.
이 뒤죽박죽 엉뚱한 말은 오랫동안 존재해 왔으며 소프트웨어 제품의 복잡성이 기하급수적으로 증가하는 것을 완전히 무시합니다. 30-20-10년 전에 일어난 일은 현재 프로젝트의 규모와 복잡성과 결코 비교할 수 없습니다. 그리고 그들은 여전히 샌드박스에서 노는 것을 선호하여 모델로 축소합니다.
그를 심어서 자원, 경제 및 경쟁력있는 요구 사항을 포함하여 많은 요구 사항이 있는 실제 제품을 만들 수 있습니다. 그는 즉시 자신의 추론과 병합하여 가능한 모든 것을 실패합니다. 오히려 해법을 찾는 단계에서 어린이 주장 자리에서 쫓겨나기도 한다.
세계는 수많은 은탄을 시도했지만 모두 사용할 수 없는 것으로 밝혀져 오랫동안 폐기되었습니다. 복잡성이 지속적으로 증가하고 라이브러리(및 oop가 있음) 및 프레임워크(및 oop가 있음)가 계속해서 증가하므로 어떻게든 복잡성을 제어할 수 있습니다.
그리고 복잡성의 증가에서 벗어날 수 없습니다. 지식의 질에 대한 요구 사항을 따라갈 수없는 문맹 개발자는 훨씬 더 어려울 것입니다.
점점 낮아지고 있는 프로그래머의 수준에 맞추기 위해 더 간단한 언어를 만들려는 시도가 더 많이 있을 것입니다. 점점 더 많은 소프트웨어 회사가 단순히 잘못된 기술을 믿고 경쟁에서 지고 아무것도 없는 자신을 발견하게 될 것입니다. 그들의 경쟁자들은 제품 결과의 관점에서 더 무겁지만 더 효율적인 기술을 사용할 것입니다.
오랫동안 소프트웨어 회사에 대한 투자는 치명적인 일이었습니다. 사망률과 실패는 놀랍고 더 나빠질 것입니다.
왜요? 예, 이것은 기술자가 아닌 경제적 요구 사항이 많은 비즈니스이기 때문입니다. 라이브 및 상설 소프트웨어 회사의 80%는 마케팅 및 영업으로 구성됩니다. 그리고 잘못 선택된 기술(여기서는 대다수가 단순성보다 우선권을 가짐)은 후속 판매를 쉽게 죽입니다. 결승에서 더 열심히 달려서 더 좋은 결과를 얻은 선수들이 항상 있기 때문이다.
이제 최대 수십만 라인의 마이크로 프로젝트에 대해 설명합니다. 이것은 한 사람의 머리에 맞고 그에게 통제의 환상을 유지할 수있는 기회가 있기 때문에 무엇이든 할 수 있습니다. 확장을 시도할 때 - 고통, 실망 및 죽음.
결과:
이달의 베스트 포스트, 아마도 올해! Renat, 당신이나 당신의 회사는 Habré에 대한 기사를 작성하지 않겠습니까( 회사는 등록되지도 않았습니다! )? 당신은 많은 것을 말할 수 있지만, 당신의 경험은 게시물의 스니펫에서만 배울 수 있습니다. 진지하게, 매우 화제가 되었고 확실히 밝혀졌습니다. 게시물에 대한 설명: https://habrahabr.ru/post/344356/
이달의 베스트 포스트, 어쩌면 올해의 베스트 포스트!
OOP에 대한 주제와 관련하여 이 게시물에서 구체적으로 어떤 점이 마음에 드셨나요? 모든 경우에 상업적인 것에 대해 일반화하는 것은 완전히 옳지 않을 것입니다. 결국 투자자는 바보가 아니며 전문가를 참여시켜 프로젝트 의 위험을 평가하도록 합니다...
이 기사에는 교수가 없지만 여전히 토론에 대한 적절한 반론이 제시되지 않은 특정 논리적 논증이 있습니다.
또한 프로그래밍의 용이함이 프로젝트에 항상 나쁜 것은 아니라는 것도 분명합니다...
이달의 베스트 포스트, 어쩌면 올해의 베스트 포스트! Renat, 당신이나 당신 의 회사는 Habré에 대한 기사를 쓰지 않겠습니까? 당신은 많은 것을 말할 수 있지만, 당신의 경험은 게시물의 스니펫에서만 배울 수 있습니다. 진지하게, 매우 화제가 되었고 확실히 밝혀졌습니다. 게시물에 대한 설명: https://habrahabr.ru/post/344356/
우리는 Habré에 대한 기사가 일반적으로 얻는 1,000 - 5,000명의 독자/뷰가 아니라 수백만 명을 위해 일합니다.
우리는 업계 표준을 만들고 전 세계에 영향을 미치는 솔루션을 출시하고 있습니다. 왜 우리는 어떤 종류의 Habr이 필요하고 심지어 러시아 세그먼트의 좁은 틈새 시장에 끼어 있습니다.
OOP에 대한 주제와 관련하여 이 게시물에서 구체적으로 어떤 점이 마음에 드셨나요? 모든 경우에 상업적인 것에 대해 일반화하는 것은 아마도 완전히 옳지 않을 것입니다. 결국 투자자는 바보가 아니며 프로젝트의 위험을 평가하기 위해 전문가를 끌어들입니다 ...
이 기사에는 교수가 없지만 여전히 토론에 대한 적절한 반론이 제시되지 않은 특정 논리적 논증이 있습니다.
또한 프로그래밍의 용이함이 프로젝트에 항상 나쁜 것은 아니라는 것도 분명합니다...
아마추어 같은 장난은 그만둬주세요.
당신은 단순히 기술 문맹으로 금지됩니다. 우리 포럼에는 호전적인 무지가 필요하지 않습니다.
...
또한 프로그래밍의 용이함이 프로젝트에 항상 나쁜 것은 아니라는 것도 분명합니다...
공리가 있습니다. 복잡성은 어디에도 사라지지 않습니다 . 따라서 사용자를 위한 "프로그래밍의 단순성"은 복잡성을 컴파일러로 이동시키는 것입니다. 복잡성은 말하자면 컴파일러에 의해 무대 뒤에서 처리되고 컴파일러는 이미 "전혀 그렇지 않은 것보다 적어도 어떻게든 작동하게 하는 것이 낫다"는 원칙에 따라 프로그래머의 변태를 숨기려고 시도하고 있습니다. ." 프로젝트 소유자는 더 이상 프로그래머가 아니라 컴파일러입니다. 무슨 일이 일어나고 있는지 더 이상 명확하지 않기 때문에 코드를 개발하고 유지하는 것이 불가능해집니다.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
마운드에서 OOP에 대해 이야기하기
레나트 팻쿨린 , 2018.01.17 09:17
...
그리고 복잡성의 증가에서 벗어날 수 없습니다. 지식의 질에 대한 요구 사항을 따라갈 수없는 문맹 개발자는 훨씬 더 어려울 것입니다.
점점 낮아지고 있는 프로그래머의 수준에 맞추기 위해 더 간단한 언어를 만들려는 시도가 더 많이 있을 것입니다. 점점 더 많은 소프트웨어 회사가 단순히 잘못된 기술을 믿고 경쟁에서 지고 아무것도 없는 자신을 발견하게 될 것입니다. 그들의 경쟁자들은 제품 결과 측면에서 더 무겁지만 더 효과적인 기술을 사용할 것입니다.
...
아마추어 같은 장난은 그만둬주세요.
당신은 단순히 기술 문맹으로 금지됩니다. 우리 포럼에는 호전적인 무지가 필요하지 않습니다.