- Dmitry Mamonov , Wrike "자전거에서 오토바이까지: 이미 만들어진 프레임워크를 사용하는 것보다 자신만의 솔루션을 개발하는 것이 더 나은 이유."
- Vladimir Krasilshchik , Yandex “환영합니다. 그렇지 않으면 자전거 타는 사람은 허용되지 않습니다.”
- Vyacheslav Lapin , EPAM – "진입 곡선" 해킹
기술적인 관점에서 자체 제품을 개발하는 프로세스는 아웃소싱 프로젝트와 어떻게 다릅니까? 처음부터 개발에 투자하는 것이 언제 합리적이고 언제 기성 솔루션을 사용하는 것이 더 낫습니까?
소프트웨어 개발에서 자신만의 자전거를 만드는 것은 일의 낭만으로 간주됩니다. 프로그래머들은 자신의 자전거를 자랑스럽게 공유하고 Github에 게시합니다. 발표자에 따르면 이것은 무언가를 배우기 위한 목적의 "Hello World" 프로젝트이거나 "머리카락이 자라는 당구공을 왜 발명했는지 기억이 나지 않지만 엄청나게 어려웠습니다. "라는 수준의 말도 안되는 프로젝트입니다.
그의 연설에서 연사는 "사이클리스트" 또는 "사이클리스트의" 팀 리더가 투르 드 프랑스에 가기 전에 스스로에게 물어봐야 할 질문에 대해 논의할 것입니다. 그는 실용적인 접근 방식에 따라 외관이 정당화되고 지시된 라이브러리 및 프레임워크의 예와 실용적인 고려 사항에 따라 외관이 불가능한 창작물의 예를 제공합니다.
"자전거"를 발명하는 것은 훌륭한 교육 기술입니다! 예술가 지망생들은 대부분 대가의 그림을 베끼는 경우가 많은데 왜 IT계에서는 NIH 증후군을 악으로 간주하는 걸까요? 결국, 라이브러리나 프레임워크가 어떻게 작동하는지 이해하려면 일반적으로 비슷한 것을 작성하여 스스로 해결하는 문제를 해결하는 것이 가장 좋습니다.
우리가 지속적이고 영구적인 학습 모델로 전환한 이후(실제로 학습과 작업이 하나의 통일된 프로세스가 됨) "자전거 만들기"는 본질적으로 학습 실습으로서 우리를 완벽하게 지원합니다. 튜토리얼, 기사를 읽고 시청합니다. 회의에서 연설하고 전투 프로젝트에서 이 중 일부를 시도하여 새로운 기술로의 "진입 곡선"을 따라 최단 경로를 찾으십시오.
그러나 이는 고객의 비즈니스 문제를 해결하는 가장 짧고 저렴하며 안전한 방법이 아닌 경우가 많기 때문에 고객이 이에 동의하는 경우는 거의 없습니다. 이러한 상황에서 “가난한 개발자”는 어디로 가야 합니까? 이에 대해서는 Vyacheslav의 보고서에서 논의할 것입니다.
그 밖에 읽을 내용: |
---|
GO TO FULL VERSION