함수형 프로그래밍을 하도록 동료를 설득할 때 해야 할 것과 하지 말아야 할 것.

팀원들이 함수형 프로그래밍(또는 현재 팀에 알려지지 않은 기술/실무/도구)을 채택하도록 설득하는 데 도움이 되는 후보 목록입니다.

다른 많은 사람들과 마찬가지로 나도 기능성programming에 푹 빠졌는데 문제는 우리 팀에서 나 혼자뿐이라는 것이었습니다.

나는 함수형 프로그래밍이 우리 코드 베이스에 큰 영향을 미칠 수 있다고 믿었기 때문에 동료 개발자들이 변경하도록 설득하려고 노력했습니다.

이것들은 그 경험에서 내가 해야 할 일과 하지 말아야 할 일입니다.

모든 것을 위한 솔루션으로 판매하지 마십시오

첫째, 😬가 아닙니다.

예, 함수형 프로그래밍은 훌륭하고 많은 문제를 해결하지만 묘책은 아니며 다른 많은 함정이 있습니다. 모두에게 그것이 그들의 모든 문제를 해결할 것이라고 말하는 것은 첫 번째 장애물에 충돌할 매우 높은 기대치를 생성할 것입니다.

문제 해결을 위한 또 다른 접근 방식으로 제시하십시오.

특정 문제를 가지고 팀에 기능적인 방식으로 수행할 수 있는 방법을 보여주세요. 그렇게 하면 이점이 명확하고 소화하기가 훨씬 쉬워집니다. Either monad의 도움으로 더 명확해질 복잡한 파이프라인을 선택합니다.

완전히 기능적인 방식으로 다음 기능을 작성하지 마세요.

자, 기능이 완벽하게 작성되었지만 해당 코드를 이해할 수 있는 사람은 당신뿐입니다 🤓. 기능을 adequate way에 작성하는 것보다 통합 코드 기반을 갖는 것이 훨씬 더 중요합니다. 이름과 생소한 패턴에 혼란을 느끼고 팀이 압도당할 수 있습니다.

const simple = fn1 => fn2 => fn3 => fn4 => fn1(fn2(fn3, fn4)); WTF?!?

워크숍을 하다

워크샵은 새로운 기술과 패러다임을 가르치는 훌륭한 방법입니다. 아주 기본적인 것부터 시작하여 고급 영역으로 이동하고, 기존 기능을 가져와 함께 리팩터링하면서 모범 사례와 이점을 나타냅니다.

싸우지마

많은 사람들이 탭 대 공백, vim 대 emacs… 명령형 대 기능형 😤과 같은 어리석은 일로 시간을 낭비하고 싸우는 것을 좋아합니다. 사람들이 기능을 자동으로 거부하게 만들므로 전투를 최대한 피하십시오ideas.

융통성을 발휘하십시오

누군가 당신의 아름다운 함수형 모듈에 명령형 코드를 섞어도 괜찮습니다. 이 개발자에게 가서 왜 그/그녀가 그런 방식을 선택했는지에 대한 토론을 열고 그에게 다른 접근 방식을 보여주고 그의 방식을 받아들일 수 있도록 열려 있습니다.

변경은 프로세스이므로 작업 프로젝트에서 기능 코드 작성을 포기하거나 중단하지 마십시오.

경험에서 얻은 팁이 있습니까? 공유해주세요!