2008-11-12 2 views
3

방금 ​​프로젝트의 1 단계에서 2 단계로 이동했습니다. 이 전환 과정에서 우리는 봄과 struts2에 대한 XML 구성을 모두 없애고 완전히 주석 처리 된 체제로 전환했습니다.자바 프로젝트에서 XML을 제거하여 효율성을 어떻게 높습니까?

참가자 모두가 개발 속도에 미치는 실제 효과에 놀라움을 금치 못합니다. 이유가 이것에 대한 있습니다

  • 역할이 다른 모든 런타임 모델을 용이하게하기 위해 우리가 @StubRepository, @TestService 및 @NotTestService 주석을 필요로 이해를 취소 리드를 필요로하는 생각 구조화 우리의 프로젝트
  • 이러한 주석은 개의 중복 된 xml 정의를 대체했습니다. (런타임, 단위 테스트, 통합 테스트, 셀렌 테스트)
  • ide에서 모든 종속성을 완벽하게 추적 할 수 있습니다. 의존성이 이익 중 일부는 아마뿐만 아니라 재 구조화하여 XML을 실현 될 수 있었다

분명하기 때문에

  • 간단한 코드와 함께 작동합니다,하지만 그건 사소한 작업하지 않았을 것이다.

    솔직히 말해서 20,000 시간 분량의 프로젝트에서 생산성이 약 10 % 향상되었습니다. 나는 믿기가 거의 힘듭니다.

    이 경험을 공유하는 다른 사용자는 누구입니까? 당신의 이득은 무엇이며 어떻게 설명합니까?

  • +0

    신비한 시간 ... :) –

    +0

    나는 복잡성 (그리고 그 양)을 반영하기 때문에 프로젝트의 전체 크기가 적절하다고 생각한다. 어쨌든 예산 수치 임) – krosenvold

    답변

    2

    기본적으로 설정 파일과 주석에 대한 질문으로 볼 수 있습니다.

    일부 데이터를 주석으로 넣을 때 생산성 향상을 경험 한 경우, 처음에는 구성 데이터가 아니라는 것을 의미합니다.

    둘 사이의 차이 :

    • 주석 : 모든 것을 한 곳에서하고 구성 정보 Java 구성 요소와 직접 관련이있다. 소스 코드의 많은 유형의 리팩터링은 이러한 이유 때문에 주석에 투명합니다. 주석은 해당 요소가 이동되거나 이름이 바뀌어도 첨부 된 구성 요소에 항상 적용됩니다. 신규 또는 수정 된 주석이 필요한 다른 리팩토링의 경우 모든 것이 같은 위치에 있으므로 주석이 개발자에게 표시되고 필요한 변경을 수행하는 것을 잊지 않을 가능성이 높아집니다.

    • 구성 파일은 응용 프로그램의 여러 구성 요소에 걸쳐있는 관계 웹의 조직보기를 제공 할 수 있습니다. 그것들은 실제 소스 코드와 별개이기 때문에 Java 소스 코드의 가독성을 저해하지 않습니다.

    당신이 경험 한 것은 설정 파일을 응용 프로그램의 소스 코드와 병행하여 유지해야한다는 것입니다. 두 파일 사이에 명백한 연결은 없습니다.

    그러나 주석에는 단점이 있습니다. 소스 코드는 실제 프로그램 논리와 관련이없는 모든 종류의 주석으로 어지럽게 정리되어 코드의 가독성을 저해 할 수 있습니다. 또한 주석은 특정 구성 요소와 관련된 메타 데이터에 이상적이지만 교차 구성 요소 응용 프로그램이있는 메타 데이터에는 적합하지 않습니다. ...

    +0

    점심 시간에 대한 토론은 최근 중앙 집중식 구성 파일에 실제 이점이있는 경우였습니다. 그들은 "Pet Shop"레벨에서 좋은 생각 인 것 같지만 프로젝트가 일정한 크기에 도달하면 쓸모가 없습니다. – krosenvold

    +0

    Nice lunch;) 설정 파일은 값을 수정해도 코드를 업데이트/다시 컴파일 할 필요가없는 대형 프로젝트에 매우 유용합니다! 하지만 잘못 사용하면 구성 파일이 끌릴 수 있습니다. – VonC

    0

    나는 당신 같은 생산성 수치가 없지만 xml 구성에서 주석으로 이동할 때 상당한 개선을 보았습니다. 나는 그 구성 정보가 코드와 같은 장소에 있기 때문에 그것을 생각한다.

    구성을 찾기 위해 별도의 파일을보아야하기 때문에 속도가 느려집니다.

    +0

    우리의 스크럼 번호가 30 % 개선되었음을 나타내지 만, 나는이 모든 변화를 모두 반영 할 수는 없습니다. 그것은 단지 훨씬 더 단순하게 느껴지며 복잡성은 내가 아는 것보다 더 큰 살인자입니다. – krosenvold

    2

    가 (정말 진부한의 가방으로 응답하는 말은하지 않았지만, XML이 속담 모음을 가져올 것으로 보인다 ;-) 나는 일반적으로 XML 구성 (및 설정 파일을 발견

    , 그러나 그것은 질문의 여러 단계를 소개하는 또 다른 질문입니다. 왜냐하면 "망치가있는 작은 소년에게는 모든 것이 손톱처럼 보입니다." 도구 (예 : XML)에 열정을 느끼고 XML을 사용하는 것보다 훨씬 더 많이 사용하거나 결과가 너무 다루기 힘들 때까지 "한 번만 더"기능을 계속 추가하는 것은 쉽습니다.

    또한 오래된 구절은 "프로그래밍의 모든 요소는 절충점"이라고 말합니다.

    그래서 악마의 옹호자 역할을하려면 실행중인 시스템의 유지 보수 또는 조정이 필요한 시점에 도달 했습니까? 새로운 삶의 방식에서는 설정 파일을 조정할 수있는 대신 시스템 전체 또는 일부를 다시 빌드하여 얼마나 자주 조정해야합니까?

    마지막으로, "Hawthorne 효과"(아래 참조)와 대략 동일합니다. 가끔 팀은 약간의 사소한 문제를 해결할 때 흥분을 터트 리며 오랜 시간 성가신 성가신 문제를 해결할 때 도움이되는 실제 개선에 비례하여 생산성이 급격히 떨어지는 경우가 있습니다.

    각주 :

    Hawthorne effect는 조명의 변화에 ​​관한 공장 노동자의 생산성에 대한 연구의 이름을 따서 명명된다. 연구진은 증가 된 빛이 생산성의 증가에 뒤 따른다는 것을 발견했다. 그러나 그 다음 그들은 발견했다 빛은 또한 생산성의 증가가 뒤 따른다. (두 가지 모두 증가는 일반적으로 단기적이었습니다.) 마지막 결론은 누군가가 그들에게 관심을 기울이기 때문에 노동자가 더 생산적이었습니다.

    때때로 사소한 변경으로 인해 성능이 향상되는 사기 (empowerment 등의 감각)가 향상됩니다.

    한 가지 요인은 거의 없습니다.

    +0

    엔터프라이즈 시스템의 현실은 이러한 구성이 어쨌든 재구성 및 테스트하지 않고도 변경되지 않는다는 것입니다. 나는 실제로 xml의 유연성을 실제로 사용하는 사람은 본 적이 없다. 자동화 된 빌드 및 자동화 된 테스트를 통해 이러한 변경 사항을 다시 빌드 할 수 있습니다. – krosenvold

    관련 문제