본문 바로가기

All

 (17)
[개발생각] 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) 정의에 대해서 웹서비스에서 회원구분코드의 정의에 대한 깊은 생각을 했다. 좀더 전문적인 웹서비스를 만들때, 회원이라는 정의는 엄청나게 중요하다. 회원 정의를 엉성하게 설계하면, 결국 회원중심으로 돌아가는 모든 기능과 연결등이 엉성하고 어설프게 설계된다. 개발자는 유연과 엉성의 차이를 명확히 인지하고 있어야 한다.유연한 설계는 수정에 닫혀있고, 확장에 열려있는 구조가 되지만, 엉성하고 어설픈 설계는 수정에 활짝 열려있고(도둑들아 모두들어오세요~), 확장에 닫혀있는(불났는데 문이 안열려..) 답답한 시스템이 되버린다.. 이런 유연한 설계를 지향해야하고, 이런 설계를 위한 첫걸음은 회원에 대한 테이블 설계라고 할수있다.개인적으로는 경력이 있다보니,많은 프로젝트 설계/개발 경험이 있었고, 매번 해왔던 회원설계/회원구분에 대..
[개발생각] 시니어 개발자와 주니어 개발자에 대한 생각 시니어 개발자와 주니어 개발자의 가장 큰 차이는 '관심' 같다. 요즘은 수평문화등의 이유로 개발자들간의 시니어, 주니어 개발자의 역할과 책임의 경계가 모호해진것같다.수평문화는 참 좋은 문화이지만, 역할과 책임에서도 수평이 되는것은 나는 좋게 보지않는다.직장,학교,군대등 사람들이 모여 생활하는 집단에서는 역할과 그에 대한 책임의 경계가 명확해야하기 때문이다.이 부분을 수평문화라는 놈이 경계를 모호하게 만드는것 같긴하다. 그렇다면, 개발에서 역할과 책임이라는 범위로 봤을때,시니어 개발자는 어떤 사람이고, 어떤 역할을 해야하는걸까? 다수의 경험을 바탕으로, 모든것들을 척척 해나가는 슈퍼맨같은 사람이라고 볼수도있다.하지만, 나는 다르게 생각한다. 시니어 개발자의 가장 큰 덕목은 '관심'이다. 내가 사용하는 기술..
[아이디어] 코틀린의 Delegate를 이용한 ReadableMap 구현에 대해서 가끔 Api의 RequestBody로 Map객체를 받아야할 필요가 있다. Api의 RequestBody의 필드값들이 가변적이거나, 요청에 따라 바뀌는경우등의 케이스에 유연하게 대응하기위해서,Map객체를 받게 구현을 할때가 있다. 이경우는 사실 코드상에서의 유려한 흐름으로 읽히는 코드는 포기해야한다.Map req 이런 객체에서 req.get("name"), req.get("age")등으로 꺼내써야 하고,값이 Any 타입으로 선언되어있기 때문에, 캐스팅도 해야하는 코드가 덕지덕지 붙게 됨에 따라,깔끔하지 못하고,개발자가 class로 구성된 DTO와 달리 필드를 바로 확인할수가 없고,문서나 주석등에 의존하거나 코드 전체를 훝어야 한다.... 이런 문제를 문득,코틀린의 Delegate를 사용하여, Map을 개발..
[아이디어] Actuator와 RateLimiter의 능동적 동작에 대해서 우리는 요청수를 제한하기위해 RateLimiter을 사용한다. 주로 많이 사용하는 라이브러리로는 Resilience4j인데, 사용법은 결국 초당 몇건(TPS)가 넘으면 요청을 막을래!로 설정을 셋팅하여 사용 한다.해당 max tps를 설정하기위해서는 성능테스트를 거쳐, 값을 측정하고, 예측에 의한 정적인 max tps를 설정하게 된다. 물론 이 정도의 기능도 상당히 프로덕션 서비스에서는 많이 유용하지만, 그 측정값이라는것이 정확하지 못하고, 여러 노드로 이뤄지거나, 환경이 다르거나에 따라 갭이 상당할수도있다. 이런 경우,프로덕션 환경에서는 시스템에 부하를 줄정도로 더 요청을 받거나,또는 시스템을 100% 사용하지 못하는 선에서 요청을 거부하게 RateLimiter가 동작하기도 한다. 이런 부분을 어떻게 ..
[개발생각] 코틀린에서 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에게 초벌 개발을 맡기고, 그 개발코드를 다듬어서 개발을 하는 방법을 쓰는 개발자들도 많이 있다. 나는 이런 방법을 경계해야한다고 생각한다.적어도 주니어 단계의 개발자라면 더더욱 경계해야한다고 생각한다. 개발자에게 초기 코딩 단계는 상당히 소중한 작업이고, 시간이다.초기에 코딩을 한다는것은 단순히 코딩을 한다는것을 넘어서,해당 기능을 만들기위해 설계와 요건,구조등을 생각하는 시간이 필요하기 때문이다.이부분들을 고민하고 설계하는 과정을 거쳐서개발자들은, 특히..
[자작] 전국 캠핑 추천 서비스 - HoHoCamping(호호캠핑) 크롤링의 정수를 맛보았다... 각잡고 만들었던 캠핑추천앱..지도를 곁들인.. 한창 캠핑에 빠져있을때,항상 좋은 캠핑장을 찾아서, 주말에 떠나는게 가장 큰 낙중에 하나였던때가 있다.주로 캠핑장을 물색할때는 블로그/카페를 많이 이용했는데,결국은 추천을 받더라도, 다시 그 캠핑장에 대한 정보를 얻기 위해서 검색의 바다에 허우적거려야 한다는건 정말 피곤한 일이었다. 어느날, 무심코 찾아보니,공공데이터포털에 전국 캠핑장에 대한 정보가 제공되고 있었고,여러 캠핑장 메타 사이트가 존재해서,이런 곳에서 캠핑장에 대한 정보를 모두 크롤링해서 거대한 캠핑정보를 만들어내고,그 정보를 바탕으로 호갱노노와 같이 사용자가 한눈에 볼수있는, 지도기반으로 정보를 잘 보여주면 편하겠다고 생각이 되어,호호캠핑이라는 앱을 만들게 되었다..

티스토리툴바