본문 바로가기

분류 전체보기

 (180)
애자일 디버깅 가장 재능 있는 애자일 프로젝트 팀에서도 일은 잘못될 수 있습니다. 언제 어느 상황에서든 버그, 에러, 결함, 실수가 나타납니다. 디버깅의 진짜 문제는 디버깅을 타임 박스에서 다룰 수가 없다는 사실인데, 그럼 이 문제를 어떻게 해야 할지 보도록 하겠습니다. - 해결책 로그를 기록하자 문제에 부딪치는 일, 그리고 문제를 해결하는 일은 개발자에게 흔히 일어나는 일입니다. 개발자들은 문제가 생겼을 때, 문제를 재빨리 해결하길 원하고 비슷한 문제가 다시 생긴다면 처음에 무엇을 했는지 기억해서 다음에는 문제를 더 빨리 해결하길 바랍니다. 하지만 오롯이 개인의 기억에만 의존한다면, 다음에 수정 방법을 기억해 내기란 꽤나 어렵습니다. • 두 번 불에 데지 말자 인터넷 검색보다는 더 생산적으로 해야합니다. 항상 접했던..
애자일 코딩 새로운 프로젝트를 시작할 때, 코드는 이해하기 쉬우며 작업하기도 쉽습니다. 하지만 개발을 진행하면서 프로젝트륵 계속 수행하기 위해선 더 많은 개발자와 상당히 많은 작업량이 소요된다는 것을 느끼게 됩니다. 프로젝트 개발에서 평범한 압박이 나중에 스트레스로 오지 않게 하려면 가장 쉬운 방법은 코드를 잘 유지하는 것입니다. - 의도적이고 의미있게 프로그래밍 하라 이해하기 어렵고 유지보수하기도 힘들며 에러가 있는 코드를 어렵지 않게 볼 수 있습니다. 코드가 어떻게 작동하는지 아무도 이해할 수 없다면 그건 아무 소용없는 코드입니다. 코드를 개발할 때, 항상 편리함보다 읽기 쉬움을 선택해야 합니다. 코드는 작성하는 것보다 훨씬 더 많이 읽히기 때문에, 코드 작성 시 성능이 좋지 않더라도 읽기 쉽다면 더 가치 있는 ..
애자일 피드백 애자일 프로젝트에서 우리는 작고 많은 변경을 지속적으로 조정하기 위해 피드백을 항상 추구합니다. 지속적인 모니터링은 코드 베이스의 품질이 떨어지지 않았으며 나아지진 않았지만 적어도 코드 베이스가 어제 작동한 것처럼 돌아간다는 사실을 확인시켜주는 피드백입니다. 그 외의 피드백을 얻을 수 있는 부분에 대해 아래에서 살펴보도록 하겠습니다. - 단위테스트 애자일은 변화를 관리하는 것이고 아마 가장 많이 변하는 것은 코드일 것입니다. 코드 변화에 대처하려면, 코드의 건강함에 대해 지속적인 피드백이 필요하고 이는 곧 자동화된 단위테스트가 필요하다는 말과 같습니다. • 코딩 피드백 애자일 형식의 단위테스트에서는 스텁 코드를 치워버리지 않고 보존해서 계속해 스텁 코드를 자동적으로 실행합니다. (스텁 코드: 디버깅을 위..
애자일에서 고객과의 협력 소프트웨어를 개발하다보면 상황에 의해 그 전체가 완전히 바뀔 수 있습니다. 상황이 바뀌었음에도 어제의 계획에 집착하는 것은 큰 화를 불러올 수 있습니다. 애자일함, 나아가 성공적인 개발은 변화를 깨닫고 적응하는 능력입니다. 이렇게 적응한 후에야 사용자 필요를 진짜로 만족시키는 시스템을 만들면서도 여러 요구조건을 맞출 수 있습니다. - 고객이 결정하도록 하라 개발자는 설계에 관한 결정을 내릴 때 참여해야 하나, 프로젝트 및 비즈니스에 대한 결정을 모두 내려야 하는 건 아닙니다. 어떤 작업을 할 때, 한 방법은 빠르지만 사용자가 할 수 있는 기능을 제약하고 다른 방법은 구현하는데 시간이 더 걸리지만 사용자에게 더 많은 유연성을 준다고 예를 들어 보겠습니다. 만약 개발 관리자가 첫번째 옵션을 선택했다면, 여러..
애자일 기르기 애자일은 자신을 변화에 적응시켜 유지해나갈 것을 요구합니다. 이것은 계속해서 변화하고 진화하는 분야인 소프트웨어에서 특히 프로그래머에게 맞는 말입니다. 대부분의 신기술들은 기존의 기술이나 아이디어에 의존합니다. 새로운 내용을 다루는 일은 단지 점진적인 변화를 인지하느냐의 문제이지만, 계속 따라가지 못하면 기술 변화는 갑작스럽고 극복하기 힘들어 보입니다. 새로운 기술과 접근 방법을 배우는 일도 중요하지만, 때로는 오래된 구식의 접근 방법을 버리는 일도 필요합니다. 또한 잘 이해하지 못하는 사실들은 계속해서 알려고 하는 태도가 있어야 할 것입니다. - 변화에 뒤처지지 말라 기술의 발전 속도는 상당히 빠릅니다. Java 를 예로 든다면, Swing, servelts, JSP, struts, JSF, JDBC,..
애자일 시작하기 어떠한 방법론에선 하나의 프로젝트를 하기 위해 약 서른가지 이상의 구분된 역할을 수행하는게 필요하다고 제시합니다. 하지만 애자일에선 소프트웨어 개발자. 단 한 가지 역할만 합니다. (지나치게 '사람' 에 의존하는 것 같기도 합니다) 피드백은 애자일의 근간입니다. 일이 잘못된 방향으로 가고 있다는 것을 깨닫자마자 변화시켜야 하며, 때로는 과감히 비난하고 앞으로 나아갈 용기도 필요합니다. 애자일은 결국 소프트웨어 개발자가 프로다운 태도를 수용할 때만 작용합니다. - 결과를 위해 일하라 일을 함에 있어 범인을 찾는 것 보다는 문제를 고치는 일을 최우선으로 삼아야 합니다. (그러지 못하는 경우를 많이 봤습니다..) 비난을 하는 대신 문제를 해결하는데 집중해야 합니다. • 비난은 버그를 수정하지 못한다 감정적으로..
애자일 소프트웨어 개발 소프트웨어 개발 방법론에는 크게 정보공학 개발 방법론 / 객체지향 개발 방법론 / 컴포넌트 기반 개발 방법론 / 애자일 방법론 이렇게 4가지로 나눌 수 있습니다. 각각의 방법론에서 파생된 방법론도 있고, 그 외에 폭포수, 프로토타입 개발 방법론 등이 있습니다. 개발 방법론에 대해선 흔히 들어왔지만 추상적으로만 알고있던 "애자일 방법론" 이 무엇인지 책 내용을 중심으로 정리해보고자 합니다. - 애자일 개발 선언문 • '프로세스와 도구' 보다는 '개인과 상호작용' • '포괄적인 문서화' 보다는 '동작하는 소프트웨어' • '계약 협상' 보다는 '고객과의 협력' • '계획 준수' 보다는 '변화에 대응' 왼쪽도 가치가 있지만, 오른쪽에 있는 것들에 좀 더 많은 가치를 둔다는 것입니다. - 애자일 유래와 정신 20..
axios configs 정리 - 다양한 http 라이브러리 Node.Js 프로젝트를 진행하다보면 다른 서버와의 http 통신이 필요한 상황은 거의 무조건 오는데, 이때 사용 가능한 라이브러리는 axios, got, bent, node-fetch-npm 등 여러가지가 있습니다. 일전에 저도 이 다양한 라이브러리 중 어느것을 사용하는게 좋을지 확인하기 위해 비교 테스트를 진행해 포스팅한 적이 있습니다 (링크) 아무래도 가장 널리 쓰이던 라이브러리는 request 가 아니었을까 생각합니다. 해당 라이브러리에 베이스를 둔 request-promise 또한 많이 쓰였습니다. 하지만 작년 2월 request 라이브러리는 완전히 deprecated 되었고, 사내에서 관리중인 프로젝트에서도 조금씩 라이브러리 교체 작업을 진행해왔습니다. 여러 라이..

티스토리툴바