|
Take My Heart Back - Jennifer Love Hewitt
Love Will Show You Everything
개발자들에게는 개발자 나름대로 "선견지명" 이 필요하다.
물론 그렇지 못하더라도 낙심하지는 말자. 시행착오는 더나은 미래를 위한 발걸음일 것이다. 먼저 한가지의 언어나 방법론, 툴에 연연하지 말자 EditPlus로 개발을 시작했고 UltraEditor를 후에 접했을때 그 툴의 단점만 눈에 보였다. 그후에 IDE툴을 써보게됬고 역시나 무겁다는 이유로 외면을 했던적이 있었다. 하지만 일단 손에 익숙해질 정도까지만 써보자. 익숙해지는데 한달도 안걸릴것이다. 그후에 재평가를 내려보자. 언어 역시 마찬가지다. 한때 자바를 "맹신" 했었지만 PHP의 단순함에 매력을 느꼈다. 또한 자바에서 복잡하게 풀었던 방식을 PHP에서 쉽게 풀어보면서 각각 언어별 장단점을 느낄수 있었다. 이렇게 새로운것에 도전을 하게되면 스스로 자신이 한단계도약하는걸 느낄 수 있을것이다. 하지만 주의해야할 점도 있다. 어설프게 아는건 오히려 스스로를 도태시킬 수도 있다. 자신이 사용하는 언어나 툴, 방법론의 철학을 엿볼수 있을정도는 되야 스스로에게 도움이 될것이다. 온라인 스터디 그룹이나 비전공 분야에 소속되어 보는것도 스스로에게 많은 도움이 될것이다. 하나에 매달려 있다보면 자칫 편협한 사고주의에 빠져들기 쉽다.
밑에서 언급했던 지저분한 코드를 적당히 넘어가자는건 아니다.
혼자서 취미로 하는 개발이 아니라면 개발도 "약속" 이다. 요구사항, 일정 등 지켜야할 약속들이 있다. 최고 품질의 코드를 만들기 위해 위의 사항들을 무시할수는 없다. 완료기한은 내일인데 1달을 더 기다려서 최고 품질의 제품을 납품할것인가? 아니면 내일당장 그런대로 쓸만한 제품을 납품 할것인가. 개발자의 자존심이라면 전자를 택하는 우려를 범할지도 모른다. 하지만 버그없는 프로그램이 없듯이 완벽한 제품 역시 없다. 오히려 완벽한 제품을 추구하려다 개발자 스스로 자괴감에 빠질지도 모른다. 최고의 품질을 위해 노력을 해야하지만 요구사항, 일정과의 적당한 타협이 필요하다.
프로젝트가 중간에 다다르고 프레임워크는(공통모듈 및 개발패턴)은 설계가 이미 된 상태이다.
작업을 하다보니 기본 설계의 의도와는 다르게 복잡하고 지저분한 메서드가 나왔다. 일회성 코드라 생각하고 반영을 할것인가? 그건 분명히 후회할만한 일이다. 복잡한 로직일수록 나중에 재사용될 확률이 높다. 그시점에서 복잡하고 지저분한 메서드를 재사용할것인가? 처음에 그 메서드를 버리거나 재설계하지 못했으므로 "이번 한번만더" 라는 마음으로 그 더렵혀진 코드를 재사용할 확률이 높다. 일회성 코드라고 생각될지라도 설계가 잘못됬다면 당장 고쳐야한다.
프로젝트가 지연되거나 개발에 문제가 발생시 먼저 변명거리를 찾지 말자.
변명거리는 굳이 찾을려고 하지않아도 문제가되는 현상을 돌이켜보면 자연스레 나오지 않을까? 현 시점을 파악해보면 이미 프로젝트 지연은 돌이킬수 없고 개발의 문제를 해결하기위해서는 시간 또는 자원이 필요하다. 그부분에대한 대안을 고민하자. 대안은 좀더 구체적이고 실용적일 필요가 있다. 지연이되고 문제가 발생되는 이유를 살펴보면 구체적이지않고 실용적이지 않아서일 확률이 높다. CEO는 decision making을 하는 사람이 아니라 decision을 집행하는 사람이라는 뜻. 권력 자체는 구성원 모두에게 분배되고 경영진은 그 권력에 의한 결정을 집행하는 것. CEO의 개념을 제대로 가지고 있는 회사 오너들은 많이 있을까?
NonEJB와 EJB의 중간단계
특징) 각계층별 (presentation layer, business layer, persistence layer, domain layer)의 인터페이스구현하는 POJO(개발자가 구현한 모든 POJO빈을 지칭하지는 않는다. 각계층의 인터페이스를 담당하는 클래스를 관리한다고 보면된다.) 빈들을 관리해주는 컨테이너를 포함하고있다. 즉 POJO빈들의 life cycle, transaction 들을 EJB에서 관리하는방식과 유사하게 관리할수 있다. EJB처럼 복잡한 구조를 가지지 않으면서도 NonEJB에서 부족한 부분들을 만족시켜줄수 있는 구조다. 특히나 EJB의 큰문제점이었던 속도나, 테스트의어려움(개발후 EJB컨테이너에 배포후 테스트)을 극복할수 있다. *) POJO : 특정인터페이스에 종속되지않는 자바빈과같은 모든클래스를 지칭.
제어권의 역전
객체의 생성에서 부터 생명주기 관리를 개발자가 하는게 아니라 웹컨테이너의 서블릿이나 EJB스팩이 관리하는 것 생성 -> 초기화 -> 서비스 -> 소멸 -> 생성...
|
