본문 바로가기

All

 (50)
[개발생각] 익숙치않은 개발(론)에 팀원들을 적응시키는 방법에 대해서 개발자라면, 같은 회사에서 오랜기간 개발하게 되면, 그 회사만의 방식/방법에 익숙해지게 마련이고, 마치 관습과도 같이 코드를 작성하게 된다.이런게 '콘웨이 법칙'의 예가 아닐까? ㅎㅎ 만약 위와 같은 상황에 지속적으로 노출된다면, 개발자는 점점 관습으로 개발을 하게 되고,(관습이 나쁘다는 이야기는 아니다. 다만, 필연적으로, 개발에 고민하는 시간이 줄어든다는 이야기이다)어느 순간 개발자가 아닌 코더로 전락하게 된다.그런데 정말 무서운것은 코더가 된것을 자신은 모른다는것이다... 정말 무섭다.. 나도 코더였던 경험이 있다. (지금은 당연히 코더가 아니라고 자신있게 말할수있다 ㅎ)대학 졸업후에, 작은 SI개발회사에서 몇년 일하게 됬는데, 어느 순간, 내가 일명 CCCV (컨트롤 C + 컨트롤 V)의 고수가 ..
[개발생각] SOLID원칙에서 I의 경험에 대해서 여러 같은 행위를 하는 Service 빈을 만들어야 할때가 있다. 이경우, 각각의 공통된 행위/과정을 인터페이스 스펙으로 설계하고,그 인터페이스 스펙을 구현하는 AService, BService, CService를 만든다.첫단계에서는 이런 스펙들이 하나의 인터페이스 클래스에 같이 존재하게 되는데,이 스펙들이 많아지고, 성격이 틀리게 되면, 적절하게 그룹핑을 하고, 나눠야 하는 시점이 오게된다. ASpec, BSpec, CSpec등으로 인터페이스 클래스로 나누고, 해당 스펙을 구현하는 구현체를 만든다.구현체는 한개의 클래스에서 모두 구현하는게 아닌, 각각의 스펙별로 별개의 역할을 하는 구현체로 별도로 만드는게 훨씬 깔끔해진다.(일정부분, 단일책임원칙과도 맞는 부분이다) 이 스펙 클래스를 구현한 구현체들은 ..
[개발생각] toString()과 toInt()의 비교 순서에 대해서 작은 차이가 명품을 만든다.. 어느 광고 카피가 생각난다. Int형 userId변수가 있고, string형 userIdStr변수가 존재하는데,이 두개의 값 자체는 정수값으로 같고, 타입만 틀린상태라고 해보자.이 두 변수를 비교해서 처리하는 로직이 아래와 같이 코딩되었다고 가정하면, if (userId.toString() == userIdStr) { //비즈니스 로직} else { //비즈니스 로직}이 코드가 잘 짜여진 코드일까? 생각해보자.. 단연코, 나는 아니라고 생각한다. 엄청 심플한 코드 같지만, 정말 세밀한 차이로 코드의 퀄리티가 달라질수있다.위의 코드는 아쉽지만, 잘못 짜여진 코드라고 생각한다.userIdStr은 String형 타입, 문자열이기에, userIdStr안의 값이 정수값인지, ..
[개발생각] 도메인VO를 컨트롤러의 입력파라미터로 써도될까?에 대한 고민 개발자의 욕심은 끝이 없으니, 재사용, 재사용이라는 프레임에 갇히고, 또 의미를 잃어버리고... 도메인VO를 정의할때, 대부분 그냥 Value Class (코틀린)로 정의해서 사용한다.즉, 대부분은 단순 Wrap 클래스로만 VO를 정의하고 사용한다. 타입 안정성과 명시적 의미부여에 큰 의미를 둘 수 있기에, Wrap 클래스 정도만이여도 상당히 강력하다고 생각하기 때문이다.하지만, 좀더 서비스가 복잡해지고 방대해 진다면, (즉, 다뤄야하는 도메인이 많아진다면)VO가 다양해지고, 해당 VO의 값에 대한 벨리데이션 검증 로직을 VO로 빼는 경우도 많게 된다. 예를 들면Value Class Email(value:String) { init { //value 검증 로직. (Email포멧 검증..
[개발생각] 동일한 역할의 API 인터페이스를 도메인에서 분리해야할때 다른 방식으로 동작하는 동일한 역할을 하는 API는 깔끔하게 도메인 레이어에서 제거하는게 더 깔끔해진다. 도메인 주도 설계 개발을 하게 되면, 아래와 같은 상황이 올때가 있다. 예를 들면, ci를 넘기면, 그 ci의 주민등록상의 주소를 리턴해주는 API를 연동한다고 해보자.그런데, 해당 API는 불안해서, 또는 다른 이유로 같은 기능을 제공하는 몇개의 다른 API를 보조로 사용하려고 한다.(A api 죽으면, B api 사용,)그런데 각각의 A, B API는 응답을 주는 방식이 틀리고, 요청파라미터도 다르다.하나는 요청하면 바로 응답값을 주는 동기방식이고, 하나는 요청하면, 콜백URL을 통해 나중에 전달해주는 콜백 비동기 방식이다. 이런경우, 도메인 서비스에서 비즈니스 로직을 구현할때,해당 api호출을 ..
[개발생각] 회원구분코드(UserDvcdCode) 정의에 대해서 웹서비스에서 회원구분코드의 정의에 대한 깊은 생각을 했다. 좀더 전문적인 웹서비스를 만들때, 회원이라는 정의는 엄청나게 중요하다. 회원 정의를 엉성하게 설계하면, 결국 회원중심으로 돌아가는 모든 기능과 연결등이 엉성하고 어설프게 설계된다. 개발자는 유연과 엉성의 차이를 명확히 인지하고 있어야 한다.유연한 설계는 수정에 닫혀있고, 확장에 열려있는 구조가 되지만, 엉성하고 어설픈 설계는 수정에 활짝 열려있고(도둑들아 모두들어오세요~), 확장에 닫혀있는(불났는데 문이 안열려..) 답답한 시스템이 되버린다.. 이런 유연한 설계를 지향해야하고, 이런 설계를 위한 첫걸음은 회원에 대한 테이블 설계라고 할수있다.개인적으로는 경력이 있다보니,많은 프로젝트 설계/개발 경험이 있었고, 매번 해왔던 회원설계/회원구분에 대..
[개발생각] 시니어 개발자와 주니어 개발자에 대한 생각 시니어 개발자와 주니어 개발자의 가장 큰 차이는 '관심' 같다. 요즘은 수평문화등의 이유로 개발자들간의 시니어, 주니어 개발자의 역할과 책임의 경계가 모호해진것같다.수평문화는 참 좋은 문화이지만, 역할과 책임에서도 수평이 되는것은 나는 좋게 보지않는다.직장,학교,군대등 사람들이 모여 생활하는 집단에서는 역할과 그에 대한 책임의 경계가 명확해야하기 때문이다.이 부분을 수평문화라는 놈이 경계를 모호하게 만드는것 같긴하다. 그렇다면, 개발에서 역할과 책임이라는 범위로 봤을때,시니어 개발자는 어떤 사람이고, 어떤 역할을 해야하는걸까? 다수의 경험을 바탕으로, 모든것들을 척척 해나가는 슈퍼맨같은 사람이라고 볼수도있다.하지만, 나는 다르게 생각한다. 시니어 개발자의 가장 큰 덕목은 '관심'이다. 내가 사용하는 기술..
[개발생각] 코틀린에서 Exception과 Transactional관계에 대해서 코틀린에서는 Checked Exception 개념이 존재하지 않는다. 그로인해 모든 Exception은 RuntimeException과 같이 동작하고,그 가장 큰 수혜라고 하면, 함수간에 Exception을 주고받을 명세 throws Exception 같은 코드들이 없어지는 깔끔함일것이다. 처음에 이 개념을 알고, 좀 혼란스러웠던 경험이 있다. 바로 스프링에서 사용하는 @Transactional의 사용에서 였다. java에서@Transactional(rollbackOn = [Exception::class, Throwable::class])이런식으로 정의해서,Checked Exception인경우도 롤백이 되도록 설정을 하여, 많이 사용했다.하지만, 코틀린에서는 Checked Exception개념이 존재하지..
[개발생각] AI를 개발에 활용하는 것에 대해서 대세는 AI, 이 사실은 거스를수없는 새로운 흐름임은 누구나 인지하는 시대가 되었다. 개발에서는 그럼 AI를 어떻게 활용을 해야할까? 생각해봤다.AI를 적극 활용하되, 그 사용의 범위를 잘 정해서 절제하며 사용을 해야할것같다. 특히 요즘 개발자들은,AI에게 초벌 개발을 맡기고, 그 개발코드를 다듬어서 개발을 하는 방법을 쓰는 개발자들도 많이 있다. 나는 이런 방법을 경계해야한다고 생각한다.적어도 주니어 단계의 개발자라면 더더욱 경계해야한다고 생각한다. 개발자에게 초기 코딩 단계는 상당히 소중한 작업이고, 시간이다.초기에 코딩을 한다는것은 단순히 코딩을 한다는것을 넘어서,해당 기능을 만들기위해 설계와 요건,구조등을 생각하는 시간이 필요하기 때문이다.이부분들을 고민하고 설계하는 과정을 거쳐서개발자들은, 특히..
[개발생각] '개발 문화'라는 달콤한 열매 '개발 문화'라는건 지층이나 퇴적물과 생성과정이 사뭇 비슷하지 않을까? 생각한다. 오랜세월 차곡차곡 퇴적물이 쌓이고, 비,바람,압력등으로 견고하게 한층한층이 단단해지듯이, 꽤 오랜 세월이 필요하고,오랜 노력과 역경이 필요한 것! 이 결과물이 '개발문화'라고 생각한다. 결국, 우당탕탕 싸우고, 의견을 나누고, 협의하고, 공감하고 등의 역경/시련이 반드시 필요하다는것이다.그중, 가장 중요한것은 다수의 공감, 그리고 그에 따른 다수의 노력/실행이다. 공감은 개발자의 모두가 해당 문화에 대해 공감을 이뤄야하는 시간과 실질적으로 공감을 하는 자리가 마련되어야 한다는 필요 충분조건이 필요하며, 지속적이고, 집요하리만큼...꾸준함으로 술이 익기를 기다리는것과 같이, \그 여유를 견디고 즐기며,기다릴줄 알아야 하는 시..

티스토리툴바