| 스피커 |
성적 증명서 |
| 오로라 티파니 데이비스 |
안녕하세요, 저는 오로라 티파니 데이비스입니다. JMP Live 팀의 소프트웨어 개발자입니다. 오늘은 JMP Live 팀의 소프트웨어 개발 방식에 대해 이야기해 드리고자 합니다. |
| |
먼저, 소프트웨어를 만드는 것이 어떤 모습일지 상상해 보세요. 개발자가 아니라면, 여러분의 머릿속에 그려진 이미지는 아마도 TV나 영화에서 본 이미지일 것입니다. |
| |
혼자 일하는 사람, 정말 똑똑한 사람, 심지어 천재일지도 모르는 사람을 상상해 보세요. 그들의 작업 과정은 정말 간단합니다. |
| |
그들은 문제에 대해 생각하고, 코드를 작성하고, 제대로 작동하는지 확인합니다. 그리고 아마도 실제로 작동할 겁니다. 왜냐하면 그들은 천재이니까요. |
| |
우리 모두가 JMP Live의 천재라면 이 간단한 과정이 우리에게 도움이 될 것입니다. 하지만 우리는 그렇지 않고 현실 세계에 살고 있습니다. 그래서 그보다 좀 더 많은 것이 필요합니다. |
| |
우선, 우리는 혼자 일하지 않습니다. 우리는 매우 협력적으로 일하며, 우리의 프로세스에는 그저 단순한 소프트웨어가 아니라 고품질의 소프트웨어를 생산하기 위한 단계가 있습니다. |
| |
소프트웨어 개발에는 정답이 없다는 점을 강조하고 싶습니다. 회사마다, 심지어 회사 내에서도 다를 수 있지만, 저희가 진행하는 프로세스를 안내해 드리겠습니다. |
| |
JMP Live에서 새로운 기능을 개발한다면 무엇을 할 것인지 말씀드리겠습니다. |
| |
우선, 코드를 쓰기 전에, 꼭 그렇게 해야겠다는 생각이 들었어요. |
| |
JMP Lives에서 작동하지 않는 문제를 발견한 실제 사용자가 있어야 합니다. 즉, 생각하는 대로 작동하지 않는 문제입니다. |
| |
이는 버그를 발견했거나 요청한 기능을 찾았다는 것을 멋지게 표현한 것입니다. |
| |
저희는 이러한 요청을 내부 시스템에서 추적합니다. 그래서 제가 가장 먼저 할 일은 해당 시스템에 접속하여 제 기술 수준에 맞는 우선순위가 높은 문제를 찾아 작업을 시작하는 것입니다. |
| |
다음으로는 필요성을 좀 더 이해해야 합니다. 사람들과 이야기를 나눠서 어떤 사용자가 이 기능을 원하는지, 어떻게 사용할지 파악해 보겠습니다. |
| |
그런 다음 내 컴퓨터에서 JMP Live를 실행하여 이 기능이 현재 JMP Live에 어떻게 적용될 수 있는지 살펴보겠습니다. |
| |
아니면 코드를 열어서 새로운 코드가 기존 코드베이스에 어떻게 들어맞는지 살펴볼 수도 있습니다. |
| |
무엇이 필요한지 충분히 이해했다고 생각되면 디자인 작업을 시작할 겁니다. 다시 한번 사람들과 이야기를 나눠요. 팀원들에게 "이런 비슷한 기능을 작업해 보신 적 있으신가요? 이 코드 부분을 작업해 보신 적 있으신가요?"라고 물어볼 거예요. |
| |
그리고 JMP에 있는 사용자 경험 전문가들과 이야기를 나눠보겠습니다. |
| |
바퀴를 다시 만들지 않도록 노력하겠습니다. 예를 들어, JMP Live에만 국한되지 않고 매우 일반적인 기능 측면이 있다면, 예를 들어 파일에 정보를 기록하는 것과 같은 기능입니다. |
| |
해결된 문제입니다. 과거에 천 명이나 되는 사람들이 그런 문제를 겪었으니까요. 좋은 오픈소스 솔루션이 있을지도 모릅니다. |
| |
그렇다면, 사용하기에 안전한지 신중하게 검토한 후 사용할 수도 있을 것 같습니다. |
| |
아직 다루어야 할 부분이 많고, JMP Live 관련 코드도 많이 작성해야 합니다. 그래서 기사와 다이어그램을 작성하고 |
| |
제가 제안하는 내용을 설명하고 팀원 모두가 제가 디자인하는 방향에 동의하는지 확인합니다. 그런 다음, 실제로 앉아서 코드를 작성합니다. |
| |
이를 위해 통합 개발 환경을 사용하겠습니다. 통합 개발 환경은 다양한 기능을 갖춘 코드를 작성하여 업무 효율성을 높이는 데 도움이 되는 도구입니다. |
| |
이제 코드를 작성했습니다. 코드를 체크인하기 전에 방금 작성한 코드에 존재하는 문제점을 찾고 싶습니다. 저도 사람이기 때문에 첫 시도에서 100% 완벽한 코드를 작성할 가능성은 매우 낮습니다. |
| |
저는 매우 명백한 문제부터 찾아보고자 하는데, 그러기 위해 정적 분석을 사용합니다. |
| |
정적 분석은 코드가 실행 중인 상태가 아니라 마치 페이지에 적힌 것처럼 코드를 분석합니다. Microsoft Word의 맞춤법 검사기와 유사합니다. |
| |
맞춤법 검사기는 당신이 매력적인 소설을 썼다는 것을 알려줄 수는 없지만, 어딘가에 쉼표가 빠졌는지는 알려줄 수 있습니다. 정적 분석은 코드에 대해 바로 그 역할을 합니다. |
| |
그런 명백한 문제들을 찾아서 해결하고 나면, 덜 명백한 문제들을 찾는 단계로 넘어갈 겁니다. 이를 위해 자동화된 테스트 스위트를 활용합니다. |
| |
정적 분석과는 달리, 실제로 코드를 실행합니다. 특정 입력값으로 코드의 일부를 실행하고 특정 출력을 기대합니다. 저희는 코드에 대한 다양한 테스트를 작성했습니다. |
| |
그리고 저는 앉아서 제가 작업하고 있는 기능에 대한 테스트를 작성하겠습니다. |
| |
테스트를 작성하기 위해 자리에 앉으면 코드가 정확히 어떻게 작동해야 하는지에 대한 생각을 명확하게 정리할 수 있어서 정말 유용합니다. 또한, 나중에 다른 사람이 실수로 기능을 손상시키는 것을 방지할 수 있습니다. 문제를 조기에 발견하는 좋은 방법이기도 합니다. |
| |
이제 수동 테스트로 넘어가겠습니다. 제 컴퓨터에서 JMP Live를 실행해서 새 기능을 시험해 보고, 예상대로 작동하는지 확인하겠습니다. |
| |
JMP Live 뒤에 있는 데이터베이스를 살펴보고 기록, 게시물, 그룹, 사용자, 댓글을 추적하여 모든 기록이 제가 생각하는 대로 작성되었는지 확인할 수도 있습니다. |
| |
이제 좋은 코드를 작성했다는 점에 대해 조심스럽게 낙관하고 있습니다. 다음 단계는 동료 검토입니다. 동료들이 코드를 검토하고 제가 놓친 부분을 찾아주셨으면 합니다. |
| |
제가 뭔가에 대해 너무 과하게 집중했거나, 팀원 중 누군가가 제가 모르는 지식을 가지고 있어서 뭔가를 놓쳤을 수도 있습니다. 이 단계는 검토자에게도 종종 큰 도움이 됩니다. 새로운 기술을 배울 수 있기 때문이죠. |
| |
동료 검토를 거친 후 실제로 코드를 커밋하거나 소스 코드 저장소에 체크인할 준비가 됩니다. |
| |
저희 서버에는 코드를 체크인할 때까지 지켜보는 지속적인 빌드 시스템이 있습니다. 그리고 체크인이 완료되면 해당 코드로 여러 가지 작업을 수행합니다. |
| |
예를 들어, 올바른 파일이 올바른 위치에 있는지, 이름이 올바른지 등을 확인합니다. 또한 스택 분석을 다시 실행하고 전체 자동화 테스트 모음을 다시 실행합니다. |
| |
이게 유용한 이유는 결국 우리는 인간일 뿐이니까요. 누군가 이 과정을 진행하는 과정에서 이 작업을 깜빡했을 수도 있고, 마지막으로 작업한 이후 무언가가 바뀌었을 수도 있습니다. |
| |
코드가 연속 빌드를 통과하면 이제 개발팀 외부의 사람들도 사용할 수 있습니다. 이 점을 가장 먼저 파악한 사람은 JMP 내 테스트 전문가들입니다. |
| |
그들은 검토를 거쳐서 자동화된 테스트 모음에 추가할 수도 있고, 수동 테스트도 실행할 수도 있습니다. |
| |
그들은 소프트웨어가 다양한 운영 체제, 브라우저 등에서 어떻게 작동하는지 살펴볼 수도 있습니다. 사용자가 할 법한 엉뚱한 행동을 상상하고, 무슨 일이 일어나고 소프트웨어가 어떻게 반응하는지 살펴볼 것입니다. |
| |
그들은 우리 프로세스에서 정말 중요한 역할을 합니다. 그들은 우리 제품의 문제점을 찾기 위해 정말 창의적으로 생각합니다. |
| |
승인이 완료되면 이제 다음 소프트웨어 릴리스에서 소프트웨어를 사용할 수 있습니다. 이제 화면을 확대하여 제품... 전체적인 프로세스를 보여드리겠습니다. |
| |
단계가 정말 많고, 할 일도 정말 많은데, 정말 모든 코드에 이 모든 과정을 다 해야 할까요? |
| |
믿거나 말거나, 이 과정은 엄청나게 확장 가능합니다. 그래서 아주 간단하고 명백한 버그에 대해서는 이 과정을 아주 빠르게 단계별로 살펴보겠습니다. |
| |
하지만 이 과정의 각 단계에 매우 복잡한 새로운 기능이 추가되면 우리는 속도를 늦추고, 시간을 들여 많은 주의를 기울여 정말로 올바르게 구현할 것입니다. |
| |
시간이 걸리는 일은 무엇이든 기업에 비용이 듭니다. 그렇다면 JMP는 왜 소프트웨어 품질에 이렇게 많은 비용을 투자할까요? |
| |
한 가지 이유는 아주 간단합니다. 우리는 우리 일에 자부심을 가지고 있으며 좋은 제품을 만들고 싶어하기 때문입니다. |
| |
두 번째 이유는 좀 덜 이상적입니다. 제품에 문제가 있는데 우리가 그 문제를 발견하지 못하면 고객들이 문제를 발견하게 되고, 이는 사업에 좋지 않다는 것을 알고 있습니다. 그래서 우리는 그 문제를 최소화하고 싶습니다. |
| |
JMP가 소프트웨어 품질에 시간과 비용을 투자한다는 점을 지적해야 합니다. |
| |
우리는 NASA 같은 기관이 투자하는 만큼의 자금을 투자하지 않기 때문에 완벽을 약속할 수 없습니다. 시중에 나와 있는 다른 소프트웨어와 마찬가지로, |
| |
JMP Live에서 예상대로 작동하지 않는 부분이 있을 수 있습니다. 혹시라도... 제안 사항이 있으시면, |
| |
www.jmp.com/support 로 가셔서 다르게 작동해야 한다고 생각되는 부분이나 앞으로 추가되었으면 하는 기능이 있는지 알려주시기 바랍니다. |
| |
실제 사용자들의 이런 생생한 피드백은 저희에게 정말 소중하고, 정말 환영합니다. 오늘은 여기까지만 알려드리고, Discovery의 나머지 부분도 즐겁게 봐주시기 바랍니다. 감사합니다. |
