높은 수준의 경영진이 함수형 프로그래밍을 고려하도록 설득하는 데있어 사실적인 주장은 무엇입니까? [닫은]


15

있다 함수형 프로그래밍은 좋은 생각 인 이유에 대해 "이론적"인수 톤 (그래서 제대로 열린 질문으로 머물렀던 것을 너무 많은, 그리고).

그러나 대부분은 이론 ( "우아함"등)이나 개발자를 겨냥한 주장입니다.

문제는 대기업의 고위 경영진에게 아이디어제시하는 것이 목적 일 때 대부분 쓸모 가 없다는 것입니다. 일부는 개발자조차 아니고 일부는 비즈니스 논쟁에 관심이있는 비용, 인적 자본 관리 , 제품 배송, 고객 서비스 및 수익; 사실로 뒷받침 할 수없는 이론적 포인트에 대한 정량적 사실뿐만 아니라

Java / C ++ / (Perl | Python)과 같은 절차 적 / OOP의 일반적인 혼합에 비해 기능적 프로그래밍 을 개념 (특정 언어는 아님) 으로 채택하는 것을 고려할 때 이러한 비즈니스 문제를 해결하기 위해 제시해야 할 강력한 주장이 있습니까? .

바람직하게는 정량적 및 / 또는 연구 또는 사례 연구를 기반으로하는 주장을 찾고 있습니다. 예를 들어, "이 참조에 따르면, Lisp / F #의 멀티 스레드 시스템의 버그 비율은 Java의 10 %"또는 "최고 관심 분야의 기능 프로그래밍이라는 원하는 기술의 선호도를 나타내는 상위 졸업생의 80 %"입니다.

내가 알고 그레이엄은 starup를위한 함수형 프로그래밍의 사용 사례를 발표 하고 더 큰 회사 설립을 위해 유효 할 수있다 가정하고 자신의 주장의 일부에 개방 될 것이다.

나는 당신이 Perl, 아마도 파이썬, 그리고 아마도 Java 8 또는 C ++ 14에서 함수형 프로그래밍에 가까운 것을 할 수 있다는 것을 완벽하게 알고 있습니다. 그러나 이것이 Perl, C ++ 또는 Java를 사용하는 조직이 기능적 대 해당 언어로도 OOP / 절차 접근

이 언어의 목적 상 "대형"은 전용 개발 엔지니어링 / 도구 그룹을 보유 할만큼 충분히 큰 것으로 정의되며, 이는 모든 개발자가 사용 / 수행 할 수있는 것을 지시합니다. 그리고 최소 수백 명의 개발자가 저가 입니다.


1
당신이 찾고있는 것 같아요? paulgraham.com/avg.html 사실, 기사가 약간 구식이라고 생각합니다. 많은 기능적 개념 사이에서 주류 언어로 들어갔습니다.
Doc Brown

34
높은 수준의 관리로 인해 어떤 프로그래밍 언어와 방법이 사용되어야합니까? 그들은 왜 그러한 결정에 관여했을 것입니까? 확실히 그것은 기술 관리자의 문제입니까?
고성능 Mark

8
@HighPerformanceMark : "고급 관리"대신 "기술 관리자"를 대체하고 질문을 다시 평가하십시오.
Robert Harvey

2
어떤 사업을하십니까? 계약 프로그래밍 및 컨설팅을 수행하는 경우 기능적 프로그래밍은 경영진이 고객에게 깊은 인상을 줄 수있는 화두가 될 수 있습니다.
JeffO

3
경영진이 현재 사용중인 언어에 대해 어떤 비즈니스 논쟁을 했습니까?
JeffO

답변:


7

최소한 관리를 즐겁게 할 수있는 매우 간단한 주장이 있습니다.

현대 컴퓨터는 주파수 스케일링이 한계에 도달했기 때문에 예전처럼 "빠르지"않은 것으로 잘 알려져 있습니다. 코어를 추가하여 잠재적 인 생산성을 높입니다.

이것은이 아키텍처의 이점을 최대한 활용하려면 프로그램을 병렬화해야한다는 것을 의미합니다. 그러나 병렬 프로그래밍은 수많은 새로운 과제로 인해 순차 프로그래밍보다 훨씬 어렵습니다 ( 포괄적 개요는 Wiki 기사 참조 ).

함수형 프로그래밍은 이러한 문제 중 일부를 제거하는 데 도움이됩니다. 예를 들어 부작용없이 불변 변수 및 메서드 만 사용하는 경우 경쟁 조건은 적용되지 않습니다. 함수형 프로그래밍에 대한 학습 곡선은 종종 가파르지만 병렬 프로그래밍에 대한 학습 곡선은 더 가파르고 전혀 직관적이지 않을 수 있습니다.

따라서보다 효율적인 방법으로보다 효율적인 프로그램을 작성하는 것이 어려운 경우, 병렬 프로그램을 작성하는 교육 비용과 기능적 프로그래밍을 배우기위한 교육 비용을 비교할 수 있으며 두 가지 접근 방식으로 인한 위험이 발생할 수 있습니다.

기능적 및 명령형 프로그래밍 스타일을 모두 지원하는 혼합 언어와 관련하여 한 단계부터 전환에 유용 할 수 있습니다 (사람들은 "친숙한"방식으로 사용하기 시작하고 점차 새로운 접근 방식을 배울 수 있습니다). 함수 프로그래밍이 가져올 수있는 잠재적 인 이점이 다른 사용자의 어설픈 코드로 취소 될 수 있기 때문에 다른면에서 이는 변장의 축복 일 수 있습니다. 명확한 코딩 가이드 라인 (예 : Twitter의 " Scale Scala " 참조)을 설정하여이를 완화 할 수 있지만 가이드 라인을 따르려면 특정 수준의 팀 성숙도가 필요합니다. 이러한 관점에서 볼 때, 순수 기능 언어는 설계에 의해 부과되는 엄격한 규칙으로 인해 소프트웨어 개발에있어 "더 쉬워 질"수 있습니다.


이러한 주장을 뒷받침하기위한 실제 연구 / 증거를 찾을 수 있다면, 특히 "기능 언어가 이러한 과제를 해결하는 데 도움이됩니다"– 지금까지는 이것이 가장 유용한 답변이 될 것입니다.
DVK


3
많은 OOP 언어가 기능 프로그래밍도 지원한다는 점을 제외하고는 목욕물로 아기를 버리면서 기능적 측면을 사용할 수 있습니다.
Andy

1
문제는 "기능적 언어"가 아니라 "기능적 프로그래밍"에 관한 문제였습니다. 문구를 바꿀 것입니다.
Ashalynd

40

당신은 잘못된면에서 이것에 접근하고 있습니다. 대부분의 회사에서 경영진은 "프로그래밍 패러다임을 선택"할 책임이 없으며, 팀 작업을 효율적으로 수행 할 책임이 있습니다. 팀 전체가 기능적 프로그래밍이 작업의 속도 나 품질을 향상시킬 것이라고 확신한다면 경영진을 설득하기가 너무 어렵지 않아야합니다. 또한 팀이 기존의 프로그래밍 언어로 기능 구성을 사용하기 시작하고 모든 사람이 그에 만족한다면 허가를 요구할 필요조차 없습니다 (프로그래머가 아닌 사람이 아닌 사람과의 차이점을 이해하지 못할 수도 있습니다). 기능적 및 기능적 구성, 왜 그 문제를 그와 논의하고 싶습니까?).

그러나 팀의 나머지 부분이 FP에 대해 다른 의견을 가지고 있고 다른 팀 구성원이 이해하지 못하는 기능 코드에 대해 불평하기 시작하면 관리상의 문제가 발생할 수 있습니다. 경우에, 팀은 효율성을 잃는다.

요점은 다른 팀원이나 팀 리더를 설득하지만 높은 수준의 경영진은 아니라는 것입니다!

편집 : 귀하의 코멘트로 인해이 - 실제로, 이것은 이다 질문 ;-)에 대한 답변. 제가 말하고있는 한 가지 사실은 "팀 전체가 FP가 업무를 수행하는 데 도움이된다고 생각합니다 . IMHO는 높은 수준의 경영진이 벌을받을 확률이 가장 높은 주장이며, 실제로 적용 할 수 있습니다." "기술적 인 추론을 이해하기에는 너무 멍청하기 때문"이 아니라 기술 전문가가 기술 결정을 내려야한다는 것을 알기에 충분히 현명하고 또한 신뢰할 수 없을만큼 똑똑하기 때문에 비 기술적 인 사람들에게는 직접적으로 거의 작업하지 않습니다. 한 전문가의 의견에 따라.


7
나는 19 명의 사람들이 그 질문에 전혀 답하지 않는 대답 을 찬성했다는 것에 놀랐 습니다 . 실제 상황에서 실용적인 질문입니다. 팀원은 목소리가 없으며 설득 할 필요가 없습니다. 또한 있을 수 없습니다 작업 - 그리고 둘 것 나는 그 문제에 관해서는 - 승인되지 않은 기술 / 언어에, 문제는 결정이 분명히있다.
DVK

1
@DVK 다른 사람이 귀하의 코드를 보지 않는다면 다른 사람이 귀하의 언어가 좋다고 설득 할 필요가 없습니다. 사용을 시작하십시오.
user253751

2
@DVK-경영진이 회사에서 사용되는 언어를 제어하는 ​​방법에 대한 통찰력을 제공해야합니다. 대부분의 경우 경영진은 팀과 리더에게 맡겨져 있기 때문에이 분야에 대한 의견이 거의 없습니다.
JeffO

3
@DVK : 사람들은 그들이 찾은 질문에 가장 도움이되는 답변을지지합니다. 대부분의 사람들이 당신이 잘못된 문제에 접근하고 있다는 답변을지지한다면, 많은 프로그래머들이 비슷한 상황에 처해 있고이 "답변이 아닌"이 도움이된다는 것을 알 수 있습니다. 대부분 비즈니스에 근본적으로 건강에 해로운 것이 있으며 언어 선택과는 아무런 관련이 없습니다. 대부분은 그 문제를 해결해야한다는 데 동의합니다. 언어를 선택한 후에 직접 시도하면 일련의 솔루션이 아니라 다음 장애물로 연결됩니다.
Cort Ammon-복원 Monica Monica

1
@CortAmmon 질문에 어차피 회사가 관리되는 방식에 문제가 있음을 기꺼이 동의 할 것이지만, 그러한 문제를 해결할 위치에있을 가능성은 거의 없습니다. CTO가 야기 할 수있는 문제를 직접 보았습니다 (사실, 어제 회사가 "프로그램 파일 외부에 소프트웨어를 배포하지 않는다는 규칙으로 인해 발생하는 문제를 해결하는 데 상당한 시간을 소비해야했습니다" "Windows 시스템에 디렉토리가 있지만 Ruby는 이름에 공백이있는 디렉토리에 설치되지 않습니다.
Jules

16

함수형 프로그래밍이 전 세계에 도입되지 않은 이유를 이해하려면 프로그래밍 언어 결정에 대한 기업의 사고를 이해해야합니다. 잠시 동안 Java를 선택하려면 다음을 수행하십시오.

  1. 일반적인 Java 코드를 다량으로 작성할 수있는 프로그래머가 있습니다. 이것은 Lisp 나 Haskell (또는 Scala) 프로그래머에게는 해당되지 않습니다.
  2. 다른 사람은 모두 Java를 사용하므로 좋을 것입니다. Corrolary : 관리자는 명령 구조에서 아무도 모르는 일부 언어와 Java 선택을 정당화 할 필요가 없습니다.

귀하의 조직이 이미 명사에 세워져 있다면 기능적 프로그래밍을 완전히 바꾸는 것은 결코 일어나지 않을 것입니다. 언어 선택 (및 언어를 둘러싼 다른 모든 선택)은 이미 기업 문화에 깊이 포함되어 있습니다.

소프트웨어 개발자로 성장하는 것이 목표라고 가정하면 최선의 방법은

  1. 유용하고 적절한 기능을 기존 프로그램에 통합하십시오 .
  2. 언어에 추가 될 때 새로운 기능 언어 기능을 사용하십시오.
  3. 기능적 언어에는없는 OO 언어의 언어 결함을 극복하기 위해 존재하는 객체 지향 디자인 패턴을 학습하십시오.

Paul Graham의 주장은 실제로 신생 기업에만 적용되며 순수 기능 언어를 사용하여 시작한 회사에 대한 많은주의 이야기가 있었지만 첫 번째 비즈니스 순서가 즉시 기능 코드베이스를 변환하는 다른 회사가 인수했습니다. 기존 소프트웨어 개발자가 이해할 수 있도록 OO 언어로


1
아니요, 제 목표는 (이 질문의 목적 상) "소프트웨어 개발자로 성장하는 것"이 ​​아닙니다. 저의 목표는 결정을 내리는 사람들에게 제시 할 수있는 최상의 주장을 모아서 FP를 승인 된 접근 방식으로 받아들이는 것입니다. 더 이상 아무것도 없습니다. 특히 표준 OOP / 절차 스택과 비교하여 FP의 장점을 강조합니다.
DVK

또한, 내가 중대한 문구 실수를하지 않는 한, 그 질문은 주장 된 의도의 결과로 "도매 변경"을 암시한다는 의미는 아닙니다.
DVK

명사 왕국에 +1 나는 그것을 "명사와 동사 사이의 전쟁"이라고 부릅니다.
Rob

4
@DVK : 시간이 시작된 이후로 무엇이든 관리를 확신시키는 방법은 동일 합니다. 돈을 절약하는 방법을 보여주십시오.
Robert Harvey

9

나의 (어떤 냉소적 인) 경험에서, 우리는 함수형 프로그래밍을 사용하는 상점에서 일했고 여러 다른 사람들과 인터뷰했습니다.

  1. 함수형 프로그래밍 경험이 있고 기술이 아닌 임원을 설득 할 수있는 CTO 및 기타 고급 기술 인력이 항상있었습니다. (그리고 우연히도이 사람들은 나보다 당신의 질문에 더 잘 대답 할 수 있습니다.)
  2. 이 사람들이 회사를 떠나서이 성향이없는 사람들로 대체되면, 남쪽으로 갈 것입니다. 새로운 사람들은 이전의 것을 구축하는 데 사용되는 기묘한 프로그래밍 언어와 패러다임에 대해 잘못되는 모든 것을 비난 할 것입니다 (특히 자신의 실패를 포함하여). 그들은 기능적 프로그래밍 기술로 나머지 사람들을 소외시켜 회사 밖으로 밀어 낼 것입니다. 기능적 언어로 구축 된 시스템은 유지 보수되지 않습니다. 내 생각에 이런 종류의 일은 비즈니스가 기능적 언어를 채택 할 때 가장 큰 위험을 감수하고 과소 평가해서는 안됩니다.
  3. 이를 위해서는 "구입 대신 구축"문화가 있어야합니다. 기능적 언어를 채택하면 "구매"옵션이 줄어 듭니다.
  4. 거의 항상 있었다 어떤 생각의 기술 및 비 기술적 인 비방에 타협. 이러한 타협 중 가장 일반적인 것은 비 JVM 언어가 고려되지 않았다는 것입니다. Clojure와 Scala가 제안되었고, Haskell과 O'Caml은 바로 방금 나왔습니다.

4

고위 경영진이 프로그래밍 언어 선택에 관여 할 때 / 고위 경영진에 대해 고려해야 할 사항

  • 생산력
    • 현재와 ​​미래의 직원 모두
    • 모든 역할 (건축가, 개발자, 테스터, OP 등)
  • 지원되는 플랫폼
    • 운영 체제 (하드웨어?)
  • 언어 / 플랫폼 출판사
    • 라이센스
  • 언어 / 플랫폼의 성숙
    • 출판사 및 / 또는 커뮤니티의 지원
    • 라이브러리
  • 현재 코드베이스 마이그레이션
    • 또는

이들은 함수형 프로그래밍 언어에만 국한되지 않습니다. 이것들과 함께 데이터를 제공하지 않으면 이것들은 또한 인수가 아닙니다. 비즈니스 환경에 전적으로 의존하는 데이터는 제공 할 수 없습니다. 우리가 할 수있는 유일한 일은 웹에서 데이터를 수집하여 특정 언어에 대한 지식과 관심이 얼마나되는지 보여줍니다. StackOverflow의 많은 질문이나 Linkedin의 많은 태그를 대중적인 언어로 번역 할 때주의하십시오.


1
기업은 또한 직원 채용에 대해 우려하고 있기 때문에 기능 개발을 대체하기가 어렵다면 이것이 그러한 결정에 참여하는 좋은 이유라고 말하고 싶습니다.
Andy

1
@Andy-그렇습니다. 이것이 제가 질문을 반박하지 않는 이유이며 관리자가 제가 언급 한 주제에 관심을 가져야한다고 생각합니다. 문제 (???)가 정의되기 전에 솔루션 (기능 프로그래밍 언어)을 선택하는 것이 다소 걱정입니다.
Erno

기능 개발자를 대체하기가 정말 어렵습니까? 여기 및 인터넷의 다른 사이트에 게시하는 정보를 얻은 개발자 수에 따라 관리자가 생각하는 것보다 훨씬 많은 기능 개발자가 있다고 생각합니다.
Giorgio

@Giorgio-나는 그것들을 대체하기가 어렵다고 말한 적이 없지만 내 경험에 따라 가용성은 위치마다 다를 수 있습니다. 일부 대학 졸업생은 기초를 배우지 않은 반면 일부 대학은 전문 지식을 습득합니다. 사업을 위해서는 장기적으로 그리고 새로운 고용인의 요구를 살펴 보는 것이 매우 중요합니다.
Erno

@ Erno : 나는 당신의 의견에 동의합니다. 앤디의 의견에 대해 언급하고있었습니다. 어쨌든, 나는 항상 기능 프로그래머가 거의 없으며 FP가 난해한 것으로 간주됩니다. 최근에 저는 FP 작업보다 훨씬 많은 FP 개발자가 있다는 인상을 받았습니다.
Giorgio

3

나는 논쟁이나 사실이 도움이 될 것이라고 생각하지 않습니다. 그리고 당신이 해결하고자하는 문제를 언급하지 않고서는 확실히 아닙니다.

일반적인 신념과 전형적인 자기 평가에 반하여 장의 느낌에 따라 많은 결정이 내려집니다. 그리고 종종 이러한 결정은 결정을 내리는 개인의 많은 경험을 잠재 의식 수준에서 통합하기 때문에 매우 좋은 결정입니다.

"모든 컴퓨터가 끝날 때까지 C와 같은 언어를 고수 할 것"과 같은 결정에 이의를 제기하려면 몇 가지 주장을 제시해야합니다.

첫 번째 단계는 아마도 고위 경영진이 그러한 기술적 결정에 대해 언급해야하는 결정의 원인과 이유를 밝히는 것입니다. 물론 나는 여기서 추측 할 수 있지만, 기술적 인 개인이 나쁘게 한 결정에 대한 상당한 기록을 가지고있을 가능성이 높습니다. 대면하자 : 대부분의 개발자는 회사 수준에서 (기술적 인 결정조차) 결정을 잘하지 못한다.

일단 당신이이 사람들이 신뢰를 얻기 위해 그들과 이야기하는 것을 발견했다. 아마도 가장 좋은 방법은 다음과 같습니다. 그들이 우려하는 것, 그들이 보는 위험과 기회는 무엇인가. 그들이 겪고있는 문제는 무엇입니까? 여기에서 기술 사람들이 이러한 종류의 결정에 참여하게 할 수 있습니다. 경영진은 종종 이러한 결정을 내리고 싶지 않지만 다른 사람을 신뢰하지 않습니다. 따라서 팀이 아키텍처 결정에 참여하기 시작하고 건전한 관리 결정이 귀하 / 팀을 신뢰할 수 있다는 것을 보여줄 수 있습니다.

건전한 아키텍처 결정을 내리려면 다음이 중요합니다.

  • 이해 관계자 (관리, 사용자, 관리자, 영업, 고객 ...)로부터 정보 수집
  • 해당 입력에 대한 기본 결정
  • 명확하게 의사 소통 : (제안 된) 결정이 무엇인지; 그들이 완화하려는 목표는 무엇입니까? 이해 상충과 지연이있는 것 : 그들이 얼마나 잘 일했는지.

직원이 10K + 이상인 대기업에서 근무하는 경우 다음 수업 중 일부를 배울 준비를하십시오.

  • 코딩 속도는 실제로 결론과 관련이 없습니다.
  • 수십 년 규모의 유지 관리 성과 같은 것들이 있습니다.
  • 기능적 언어를 사용하여 해결할 수 있다고 생각하는 문제는 실제로 결론과 관련이 없습니다.
  • 1000 명의 개발자 교육과 같은 문제, 5 년 미만의 기술 경험을 가진 개발자가 작성한 코드 기반 변경 및 유지에 대한 자연스러운 저항이 있습니다.

귀하의 주장을 듣고 고려한다는 신뢰 수준에 도달하면 귀하, 팀 및 경영진이 요구하는 요구 사항을 수집하고 고려할 수있는 방법을 마련하게됩니다.

이 프로세스가 특정 영역에서 기능적 접근 방식을 사용하도록 권장하는 경우 수행됩니다.

이 프로세스에서 현재 주 프로그래밍 언어가 제공하는 기능을 넘어 기능적 접근 방식을 무시할 것을 권장하는 경우에도 수행됩니다.

나쁜 소식은 : 회사의 규모와 스타일에 따라 몇 년에서 몇십 년이 걸릴 수 있습니다.

좋은 소식은 : 당신은 길에서 많은 것을 배울 것입니다.

첫 번째 단계는 대화를 시작하고 특히 고위 경영진의 말을 듣는 것이므로 Just Listen 을 읽는 것으로 시작하는 것이 좋습니다 .


3

한 가지 좋은 접근 방식은 업계에서 좋은 결과를 보여주고 채택되었음을 보여주는 것입니다.

다음에서 데이터를 얻을 수 있습니다.

이상적으로는 일부 상장 회사의 관리자, 특히 해당 산업 분야의 관리자와 대화하고 숫자와 평가를 얻으십시오.

Google은 Haskell, OCaml 등에 대한 기타 유사한 링크를 많이 보유하고 있습니다.


3
OO 실무자들이 FP 지원자 수 를 크게 상회하기 때문에 일부 회사는이를 반대 사례 로보고 있다 .
Robert Harvey

1
@RobertHarvey-적어도 내 경우에는 약간의 청어 논쟁입니다. 그들은 이미 그것을 알고있을 정도로 지능적입니다. 그들이 알지 못하는 것 (그리고이 답변에서 찾은 것)은 Eaton Vance가 Scheme을 사용하고 Faceboook , BoA / ML, Deutsche Bank 및 Google [ Hassell 사용]을 사용한다는 것 입니다. 즉, 다른 가치있는 사람들이 결정했기 때문에 발가락을 담그는 것이 좋습니다. 내가 물었던 질문을 해결하려고 시도한 유일한 유용한 답변은 (그리고 사람들이 대답하는 것처럼 느끼지 않는) 유일한 투표권을 가진 사람이라는 것이 놀랍습니다.
DVK

1
@ dvk : 당신이 묻는 질문은 (내가 올바르게 이해한다면) FP가 좋은 것이라고 상사에게 어떻게 확신 시키는가? 글쎄, 때로는 그렇지 않습니다. 우리는 변하기 쉬운 세상에 살고 있으며, 함수형 프로그래밍은 솔직히 조금 이상합니다. 나를 믿지 않으면 모나드를 살펴보십시오. 이러한 기묘함을 해결하는 답변 (및 소프트웨어 설계 및 개발 프로세스에 미치는 영향)은 생각 여부에 관계없이 유용합니다.
Robert Harvey

@RobertHarvey (1) 다시 가져옵니다. 이제 유용한 답변 중 두 가지가 가장 낮은 투표로 선정되었습니다. :) 방금 게시 된 새로운 답변은 사실로 개선 될 수 있지만 좋은 출발입니다.
DVK

@RobertHarvey-그렇습니다. 문제는 "FP가 좋은 것입니까"또는 "사람들에게 FP가 좋은 것을 확신시킬 수 있는가"가 아닙니다. 문제는 "정확한 것을 확신 시키려고 할 때 어떤 주장을지지 할 수 있는가"였습니다. 그것은 "어떻게 FP를 긍정적으로 내 작업 / 코딩에 몰래 도입 할 수 있는가"가 아니 었습니다. 이것이 당신이 대답 한 것입니다.-그것이 처음에 묻지 않을 옵션이라면, 나는 코딩 할 것입니다. )
DVK

2

당신은 잘못된 방향에서 이것에오고 있습니다.

당신은 자신의 오락을위한 기능적 패러다임으로의 전환 관리를 설득하려고 노력하고 있으며, 당신이 그것을 원하는 실제 이유와 관련이없는 이것을 지원하기 위해 논쟁을 벌이려고합니다. 그렇지 않으면 당신은 질문을 할 필요가 없을 것입니다. 왜냐하면 당신은 당신의 머리 위에서 논증을 나열 할 수 있기 때문입니다.

오히려, 당신이 생각해야 할 것은 현재 비즈니스 요구가 무엇이며 그것이 가장 잘 제공되는 방법입니다. 기능 패러다임을 사용하는 것이 가장 좋습니다. -놀아요 그러나 운영 비즈니스 요구, 동료에 대한 필요한 교육, 미래 프로그래머의 배경, 유지 보수 등을 고려하여 공정한 분석을 수행하는 경우 종종 그렇지 않습니다.


2
이것은 다소 건전한 방법이며 질문에 대답하는 데 너무 도움이되지 않습니다. 질문에 대한 "접근법"에 대한 OP 지원을 피하는 것으로부터 추상화되어야합니다.
VF1

1

기술적 인 기술이없는 고위 경영진은 기능적 패러다임의 사용과 같은 기술적 측면에 신경 쓰지 않아야합니다. 이것은 그들의 전문 영역이 아니며 소액 관리 냄새가납니다. 그들은 실제로 기술을 필요로하는 사람들에게 그러한 결정을 위임하지 않는 이유는 무엇입니까?

이것은 기술적 인 배경을 가진 사람들 (첫 번째 경우)과 하나가없는 사람들 (두 번째 경우)을 설득하기위한 힌트입니다.

첫 번째 경우

프로그래밍을 아는 사람들과 이야기하는 경우 기능적 프로그래밍 패러다임없이 작성된 코드와 기능적 스타일로 작성된 동일한 코드를 비교하면 충분히 설득력이있을 수 있습니다.

명령형 스타일을 사용하는 샘플 C # 코드 :

var categorizedProducts = new Dictionary<string, List<Product>>();

// Get only enabled products, filtering the disabled ones, and group them by categories.
foreach (var product in this.Data.Products)
{
    if (product.IsEnabled)
    {
        if (!categorizedProducts.ContainsKey(product.Category))
        {
            // The category is missing. Create one.
            categorizedProducts.Add(product.Category, new List<Product>());
        }

        categorizedProducts[product.Category].Add(product);
    }
}

// Walk through the categories.
foreach (var productsInCategory in categorizedProducts)
{
    var minimumPrice = double.MaxValue;
    var maximumPrice = double.MinValue;

    // Walk through the products in a category to search for the maximum and minimum prices.
    foreach (var product in productsInCategory.Value)
    {
        if (product.Price < minimumPrice)
        {
            minimumPrice = product.Price;
        }

        if (product.Price > maximumPrice)
        {
            maximumPrice = product.Price;
        }
    }

    yield return new PricesPerCategory(category: productsInCategory.Key, minimum: minimumPrice, maximum: maximumPrice);
}

함수형 프로그래밍을 염두에두고 동일한 코드를 다시 작성했습니다.

return this.Data.Products
    .Where(product => product.IsEnabled)
    .GroupBy(product => product.Category)
    .Select(productsInCategory => new PricesPerCategory(
              category: productsInCategory.Key, 
              minimum:  productsInCategory.Value.Min(product => product.Price), 
              maximum:  productsInCategory.Value.Max(product => product.Price))
    );

그런 다음 물어보십시오.

  1. 첫 번째 샘플에서 프로그래머가 몇 가지 실수를 할 수 있습니까? 두 번째는 어떻습니까?

  2. 실수를 찾는 것이 얼마나 어려운가요?

  3. 코드를 수정하는 것이 얼마나 어렵습니까?

세 가지 요소 모두 생산성과 제품 비용에 영향을줍니다.

두 번째 경우

프로그래밍을 모르는 사람들을 다루는 경우 기술적 인 내용이 많지 않습니다. 설득력있는 방법 중 하나는 기능적 패러다임이 작업과 동료의 작업에 미치는 실제 영향을 보여주는 것입니다.

예를 들어, 동일한 팀이 만든 두 프로젝트 (하나는 FP를 사용하고 다른 하나는 사용하지 않음)를 비교하십시오. 버그의 수가 훨씬 적거나 회사가 실제로 정시에 제공 한 첫 번째 프로젝트라는 것을 보여 주면 충분히 설득력이 있어야합니다.


3
나는 당신이 한 일을 보았지만, 당신의 모범은 완전히 설득력이 없습니다. 기본적으로 기능적 예제를 명령형 예제로 풀었습니다. 실제적인 회사 문제에서는 발생하지 않습니다. 당신은 yield return어쨌든 Linq는 시나리오에 사용되는 당신이 코드를 준비 할 방법의 예되고, 속임수의 비트, 그리고 당신의 if문은 원 사업자와 더 간결하게 작성할 수 있습니다. 첫 번째 예제는 모두 명령형 함수로 리팩터링되어 복잡성이 숨겨집니다.
Robert Harvey

@RobertHarvey 첫 번째 예제를 여러 명령형 함수로 리팩터링 할 수 있지만 해당 쿼리에 고유 한 사용자 지정 명령형 함수입니다. 쿼리가 올바른지 확인하기 위해 여전히 모든 정보를 확인해야합니다. 리팩토링은 명령형 코드의 크기를 더욱 증가시킵니다. 컴팩트하게 작성할 수 있더라도 모든 작업이 부작용을 겪기 때문에 코드를주의해서 읽어야합니다. 줄 끝의 삼항 연산자의 두 번째 부분에서 수행되는 부작용을 놓치고 싶지 않을 것입니다.
Doval

1
@RobertHarvey 두 개의 코드 스 니펫이 동일한 지 확실하지 않습니다. 반복을 건너 뛰는 대신 두 번째 목록을 작성하여 명령 식 하나가 "필터링"하기 때문입니다. 실제 동등 물이 하나의 루프 만 사용하므로 더 깊게 중첩되지 않습니까?
Doval

5
기능적 개념을 다른 명령형 / OO 언어로 통합 하는 데에는 좋은 사례를 제시 하지만 , 이미 필수 / OO 인 회사 환경에서 완전히 기능적인 언어를 사용하는 경우에는 반드시 좋은 것은 아닙니다.
Robert Harvey

귀하의 예와 관련된 또 다른 (아마도 덜 유효한) 문제 : 첫 번째 예는 대부분 읽을 수있는 대부분 비 FP Perl로 작성할 수 있습니다-볼륨의 30 %. 아마 적을 수도 있습니다. 수락 여부에 따라 달라집니다 map/ grep비 FP한다. IOW, 당신은 Java가 나쁜 언어이며 FP가 좋은 접근 방식이 아니라는 주장을 제시하고 있습니다.
DVK
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.