솔로 프로그래머를위한 소프트웨어 개발에서 가장 잘 알려진 모범 사례의 최소 하위 집합은 무엇입니까? [닫은]

나는 오랫동안 내 일에서 외로운 프로그래머였습니다. 일반적으로 나는 기사와 게시물을 읽었습니다.

• 버전 관리 시스템
• 지속적인 통합 / 배달
• 개발 방법론 : Scrum, Waterfall, V-Model, Agile, XP 등
• 소프트웨어 프로젝트 관리

그러나 거의 모든 팀이 TEAMS에 중점을 둔 것으로 보입니다. 저는 팀이 아니므로 한 명의 프로그래머에게 절대적으로 필요한 최소한의 관행은 무엇입니까? 다음 조건을 고려하십시오.

• 다른 사람의 코드와 충돌하지 않습니다.
• 파일 / 디렉토리 트리를 유지 관리 할 필요가 없으며 개발 환경은 자체적으로 버전 관리 (이미지 기반 개발)에 관심이 있습니다.
• 공식적인 요구 사항은 없으며, 내 사용자는 자신이 원하는 것을 알지 못하고 괜찮습니다.
• 릴리스 또는 문서를 제공하는 데 관심을 가질 수있는 유일한 방법은 기본적으로 고객이 결과를 원하고 소프트웨어 방법론에 관심이없는 것입니다.

제 생각에는 고객 요구 사항과 직접 관련이없는 어떤 것에도 너무 많은 시간과 에너지를 소비하고 싶지 않다는 것입니다. 어떤 추천?

더 없다 권리 는 각 사람에 의존하기 때문에이 질문에 대한 대답은. iPad를 사용하여 모든 개발 작업을 수행하고 고객이 만족한다면 전혀 바꿀 이유가 없습니다.

그러나 내가 당신의 입장에 있다면, 나는 다음을 강력하게 시행 할 것입니다.

• 버전 제어 시스템 -이미지 기반 개발 시스템이 정기적 인 백업과 관련하여 작업을 수행한다고 생각할 수 있지만 일반적으로 브랜치를 사용하는 실험 기능을위한 리글 공간이 없습니다 . 또한 중요한 버전의 프로젝트를 유지할 방법이 없습니다 ( 태그 지정 ). 자신을 넘어서서 확장한다면, 참여하는 개발자들은 그들이 지옥에 있다고 생각할 것입니다.
• 민첩성 -이 방법은 원하는 것을 모르는 고객에게 매우 적합합니다. 조만간, 그들은 꼬리를 쫓기 위해 돈을 쓰고 싶지 않다는 것을 알게 될 것 입니다. 그들은 진보 를 보고 싶어 할 것 입니다.
• 프로젝트 관리 도구 -필수입니다. 머리 속에 모든 것을 담을 수 있다는 것은 매우 강력한 일이지만 반드시 그럴 필요는 없습니다. 훈련을 받고 프로젝트 관리 도구 (예 : Redmine )를 사용하면 작업을 분리하고 탐색하기 쉬운 작업 기록을 제공 할 수 있습니다. 시간당 충전을 시작할 때 매우 중요합니다.

버전 제어는 프로그래머라도 고독한 것이어야합니다. 즉, 삭제 된 파일과 복잡한 변경 사항을 간단하고 신속하게 복구 할 수 있습니다.

기본적으로 그것은 당신이 매달린 일을 할 때 멍청한 똥에서 당신을 저장합니다.

다른 사람들이 말했듯이 버전 관리 또는 소스 코드 관리는 매우 중요합니다. DVCS를 사용하고 그것에 대해 모든 것을 배우십시오. git 또는 mercurial과 같이 인기있는 것을 선택하면 도움이 될 수 있지만 실제로는 중요하지 않습니다.

내가 언급하지 않은 또 다른 것은 한 단계 빌드 스크립트 입니다. 이것은 곧바로 연속 통합이 아니며 (그 말은 BS에 경향이 있습니다) 매우 유용한 도구입니다. 긴급 업데이트가 필요할 때마다 스크립트를 실행하고 완료하면됩니다. 프로젝트가 끝날 때마다 하루에 여러 번 빌드해야합니다. 내 경험은 빌드 프로세스가 너무 복잡하지 않더라도 크게 보상한다는 것입니다. ftp 업로드 기능, 전자 메일 보고서, 단위 테스트 실행, 설치 프로그램 빌드, 서명 등을 추가 할 수도 있습니다. 처음부터 스크립트를 작성하면 프로젝트가 진행됨에 따라 더 많은 단계로 유지 관리 및 확장이 쉽습니다.

한 가지만 대답하겠습니다. 팀 제어가 아닌 모든 프로젝트에서 버전 관리가 매우 중요합니다. 사용하는 데 약간의 추가 시간이 걸리지 만 다시 넘어 질 수있는 풍부한 역사를 제공합니다. 실버 탄환은 아니지만 실제로 실제 사본으로 되돌릴 수있는 것이 좋습니다. 실험적인 특징으로 인해 대부분의 응용 프로그램이 손상되었습니다.

버전 관리는 절대적으로 필요합니다. 출처를 잘 지키는 것뿐만 아니라 출처 고고학 때문에. 이상한 코드 조각을 "수정"하려고하면 클래스 나 프로 시저가 어떻게 발전했는지 확인할 수있는 1 년이 지나면 많은 고통을 덜 수 있습니다.

방법론- 프로그래머 선언문을 강력히 추천 합니다 . 일반적으로 J2EE 포틀릿 가능 JSR 호환 MVC 역할 기반 CMS 웹 서비스 응용 프로그램 컨테이너 프레임 워크의 작동 방식 을 오버 헤드없이 유지하면서 소규모 팀에서도 훌륭한 결과를 얻을 수 있습니다 .