함수, 이렇게 만들면 넌 주니어

Рет қаралды 19,295

7 ай бұрын

오늘은 함수명을 어떻게 지어야 할지에 대한 중요한 포인트를 공유합니다. 단순히 함수의 내부 연산을 반영하는 이름이 아니라, 함수의 도메인과 목적을 명확히 반영하는 이름을 짓는 방법에 대해 설명합니다. '도메인 드리븐 디자인'의 원칙을 바탕으로, 우리는 함수의 사용자가 무엇을 기대할 수 있는지, 어떤 결과값을 받게 될지를 명확히 전달하는 이름을 선택해야 합니다. 이 영상을 통해 더 나은 코드 재활용성과 유지보수를 위한 함수명 짓기의 중요성을 이해하고, 여러분의 코드 작성 능력을 한 단계 업그레이드 해보세요!
00:00:00 함수명은 코드의 연산에 따라 짓는 것이 중요함
00:00:30 ️‍함수 이름, 내부 코드, 기능 영역의 일관성 있어야 함
00:02:59 ️함수 내부에서 유지되어야 하는 데이터의 의미, 함수 이름의 중요성
00:04:57 ️️함수명과 시그니처에 대한 중요성
00:06:07 ️ 좋지 않은 코딩 습관과 함수명작성에 있어서 중요한 점

Пікірлер: 120

@jyyyy1834 7 ай бұрын

주니어가 아니라 점점 신생아가 되어가는...ㅋㅋ

@Son-lm5mf 7 ай бұрын

응애

@enslow 7 ай бұрын

응…응애 ㅠ

@stddevv 7 ай бұрын

응애 😂

@김우성-u3c 7 ай бұрын

도메인 계층에 가까울 수록 동작의 과정(How)이 아닌, 결과(What)를 드러내는 함수명이 좋은 것 같습니다

@meinlet5103 7 ай бұрын

주니어 인플레이션의 시작이다

@jun-heechoi9382 7 ай бұрын

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

@이두희-z3w 7 ай бұрын

복잡해질수록 중요한 건 역시 기본이라는 것을 다시 한번 되새기고 갑니다! 언제나 뚝배기 깨주시는 포프님에게 감사드립니다.

@Kai-Shin 7 ай бұрын

당연한걸 못하는데도 주니어 대접을 해주는 친절한 포프씨.. :D

@초이진-t5c 7 ай бұрын

개발시작전에 개발 컨텐츠 명세를 보면서 항상 고민하다가 드는 생각이 컴퓨터는 0과 1로 알아듣는데 어떤식으로든 적절하게 작성만 되어있다면 구동에 문제가 없겠지만, 결국 사람과 사람간의 원활한 소통을 위해 여러 디자인 방법론이며 설계 원칙이며 등등 많은 이론 및 주장등이 있는것 같다고 생각이 듭니다. 역지사지라는 말에 참으로 공감이 많이 되네요. 같이 일하시는 분들과도 내가 혼자보는 것이 아닌 남이 내 코드를 본다고 생각하고 코드작성을 해야한다고 자주 얘기하는데, 역지사지의 마인드가 그 어떤 이론이며 방법론 보다 더 아래 기반에 깔려있어야 한다고 다시한번 확신을 하고 가게됩니다👍👍👍

@lucky.developer 7 ай бұрын

취준때부터 포프님 영상 많이 봤었습니다 이제 경력이 만3년이 됐네요 영상으로 나누어주시는 인사이트들이 하나둘 쌓여서 제 기준과 습관이 되고 있습니다 감사드립니다!!!

@김김-e2l 7 ай бұрын

주니어 시리즈 뜰 때마다 조마조마하면서 봅니다 ㅋㅋㅋ

@jun-heechoi9382 7 ай бұрын

ㄹㅇ

@hm-xh1ju 6 ай бұрын

와.. 전혀 생각하지 못했던 거라 듣고 굉장히 큰 배움을 얻었습니다. 이게 진정한 함수형 프로그래밍이군요. 함수형 프로그래밍은 함수명까지도 함수형이어야한다...

@jdh-diary 7 ай бұрын

좋은 얘기네요 ㅎㅎ 구현에 집중하다 보면 그 생각이 계속 멤돌다 그렇게 이름 자주 짓게 되더라구요. 감사합니다 ㅎㅎ

@정주영-e3l 7 ай бұрын

Caller의 계층에 따라서 함수명의 추상화 정도를 달리합니다. 상위 계층일 수록 도메인 논리를 드러낼 수 있을 정도로 추상적으로 짓는 반면 하위 세부 구현체와 가까워질수록 연산 논리를 드러내도록 짓습니다.

@jkkim6928 7 ай бұрын

오 명징한 원칙이다

@김지우-o5j 7 ай бұрын

이 영상보고 백수에서 주니어 됐슴니다. 감사합니다

@밤지-x2u 7 ай бұрын

가끔은 포프 아저씨의 옛날 핑크머리가 보고싶네요

@yoodan.6097 7 ай бұрын

정말 맞는말이네요 좀더 생각이 명확해지는 느낌이네요 😮

@j3ssu9 7 ай бұрын

신생아 질문있습니다! 흔히 사용하는 3계층 구조에서 repository 인터페이스를 구현하려고 할 때, 앱에서 사용하는 ORM 프레임워크 구현체(Data JPA나 TypeORM)의 함수명들은 최대한 건조하게 코드 동작 기반으로 메서드명을 사용하고 있습니다. 도메인 지식이 들어간 이름이 해당 ORM 구현체에 들어가면 서비스 계층에서 해야할 책임이 범람될 것 같다는 생각이 있는데요, 혹시 이 부분에 대해서는 어떻게 생각하시는지 궁금합니다..!

@asketeddy 7 ай бұрын

지나가던 ddd 유치원생입니다. repository 와 서비스 메소드명은 할 얘기가 정말 많은 주제인 것 같습니다. 간단하게 repository interface 는 SQL의 도메인 특화 언어(dsl)를 위한 레이어 정도로 바라보시는게 현명할 것 같습니다 저장 및 조회 행위가 필요한 도메인 지식이 들어간 이름으로 orm 메소드를 만듭니다. 예를 들어 CreateXXXX, UpdateXXXX, RetrieveXXXX : 저장소가 하는 행위와 서비스(비지니스 로직)가 1대1 대응하기 위함이고, repository 의 메소드 명에서 저장관련 행위와 도메인이 무엇을 하는지를 정의합니다(시스템의 저장소는 도메인 모델을 기록/조회/수정/삭제 한다) 서비스 계층에서 해야할 일 중, [저장소]와 관련된 일 + [도메인]이 할 일을 모두 수행하는 책임을 가지며 이는 유지보수에서 효율적인 패턴이 됩니다. (데이터 중심 설계) (서비스와 저장소의 의미가 1대1 대응됨, 대신 [빈약한 도메인 모델] 안티 패턴으로 보는 경우도 있습니다, 풍부한 도메인 모델에서 orm 을 쓰는 것 자체가 보편화된 설계 이론들과 부합해질 가능성이 높습니다, + sql transaction 은 도메인 지식이 아니에요 라는 주제도 있습니다) -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- *아래는 뇌절입니다, ddd 홍보와 함께 어떤 관점으로 보는지 예제와 함께 설명합니다, 생략한게 많습니다* :ddd 는 고도화의 필요성이 있는 회사 상황과, 경험이 많고 실력있는 도메인 전문가 및 개발자가 필요합니다. **ddd 는 msa 가 아니며 은총알은 더더욱 아닙니다** 1. ddd 의 aggregate/repository 패턴을 쓴다 (어렵습니다. 반버논/에릭에반스 의 ddd 책을 읽어보고, solid, msa 관련 책들을 읽어보는게 도움이 됬습니다) 2. 서비스 메소드는 상황만을 대변하는 '사건'의 이름을 사용한다 (이벤트 스토밍 워크숍을 진행하고 클린 아키텍처 처럼 uml(use case 다이어그램)을 그려보면 좋습니다) 3. 자연스럽게 repository 는 저장 관련 행위로만 만들어지며, 도메인 지식과 분리된다 (대부분이 비유이니 간단하게 보시면 됩니다) ddd 유치원에 오신다면, 서비스와 저장소의 의미를 분명하게 구분할 수 있습니다 여기서는 aggregate / repository pattern 을 사용합니다 aggregate: 아우(동생) 집계(집착체) - 도메인 지식의 모델을 하나의 트랜잭션으로 관리하기 위함 aggregate root: 형님 집계, 모든 아우 집계과 인맥(유의미한 연결)을 가짐(모든 아우와 형님의 트랜잭션 경계 혹은 경계의 범위), 반드시 한 개 repository: 하나 형님 집계(aggregate root) 만을 저장하고, 아우 집계나 큰형님 집계를 조회하는 저장소 위 방식을 따르면 repository 의 메소드명이 간단해집니다 (저장소는 말 그대로 '저장 된' 혹은 '저장할 데이터'에 대한 시스템으로 보면 좋을 것 같습니다) - 말 그대로 save(큰형님), load(형님_혹은_아우_집계_식별자) 같은 메소드만 쓰면 되며, 저장소가 하는 행위가 도메인 지식과 분리됩니다 여기서 서비스는 '무엇을 하는가?(what)' 보다는 '무슨 일이 일어나는가?(event)' 를 초점으로 둡니다 [무엇을 하는가]와 [무슨 일이 일어나는가] 는 의미상 다릅니다 (service vs event) 서버는 무엇을 하는가 단점: 우리는 서버의 행위를 조회/생성/수정/삭제로 볼 수 있기 때문에, 의미론 상 중복이 발생합니다 - 예시: 서버는 대상 모델과 행위를 기술합니다, 사용자_정보_수정, 사용자_프로필_수정, 관리자_정보_수정 -> ddd 에서 서비스가 [무엇을 무엇 한다]로 되어버리면 곤란합니다. (일어날 행위의 의미가 너무 많아집니다) : 이런 방식은 모델링 입장에서도 연관관계만 발생되기 때문에, 도메인 전문가과 협력 할 수 있는 멘탈 모델을 만들기 힘들어집니다 : 시스템에서 무슨 일이 일어났는가 단점: 개발자의 노력 만으로 이벤트의 기준을 만들기가 어렵습니다, 도메인 전문가와 다양한 협업이 필요합니다 - 예시: 일어난 사건을 기술합니다 (개인정보_변경(서비스) + 개인정보동의_변경(서비스) -> 고객_이용_정책_통과됨(이벤트)) -> 사건이 되면 범인(actor)과 일어난 일을 육하원칙으로 메소드명 만으로 대체(use-story) 가능해집니다 : 도메인 전문가와 깊은 협업이 가능해지며, 다른 이벤트들과 의미론 상 중복을 피합니다. 도메인 변경에 대한 개발 리스크가 적어집니다. 더욱 뇌절을 이어가겠습니다 아래 예제에서 서비스와 저장소 계층의 의미가 확연하게 분리됩니다. : 상품목록을 확인하던 고객A는 빠른 구매를 위해, 장바구니 서비스를 활용하고 싶다 : 1. 고객 A의 {찜 상품 목록} 조회 2. 고객 A의 {찜 상품 목록} 변경 *중괄호는 보편언어를 의미합니다 ------------------------------------------------이벤트명: {찜 상품 목록}이 조회됨---------------------------------------------------- 메소드명 : Viewed{찜 상품 목록} 코드: ``` {장바구니} = system.repository.load(userID) return {장바구니}.{찜 상품}().Selected_Items() ``` 1. 시스템은 [저장소]를 통해 주어진 고객A의 ID의 [장바구니 집계]를 조회한다 코드 - `{장바구니} = system.repository.load(userID)` : 여기서 load 라는 메소드 만으로 형님 집계인 {장바구니}를 조회합니다. 장바구니의 인맥인 아우들은 {찜 상품}, {관련 추천 상품}, {광고 우선순위 정책} 등 존재합니다 2. 시스템은 [장바구니 집계]를 통해 {찜 상품}의 {등록된 목록}를 반환한다 코드 - `return {장바구니}.{찜 상품}().Selected_Items()` => 여기서는 한번에 아우 집계(찜 상품)를 조회 할 수도 있습니다. 하지만 형님을 통해 아우를 알게 하는 것이 형님의 인맥(풍부한 도메인 모델)을 강화 할 수 있습니다 ------------------------------------------------이벤트명: {찜 상품 목록}이 변경됨---------------------------------------------------- 메소드명 : Changed{찜 상품 목록} 코드: ``` {장바구니} = system.repository.load(userID) {변경된 장바구니} = {장바구니}.{찜 상품}().Change({dto 로 받은 찜상품 목록}) system.repository.save({변경된 장바구니}) return ``` 1. 시스템은 [저장소]를 통해 사용자의 [장바구니 집계]를 조회한다 코드 - `{장바구니} = system.repository.load(userID)` : 위 1번과 같은 의도입니다 2. 시스템은 [장바구니 집계]와 사용자로부터 주어진 {찜 상품 제출 폼}(dto)을 통해 {찜 상품 목록}을 변경한다 코드 - `{변경된 장바구니} = {장바구니}.{찜 상품}().Change({dto 로 받은 찜상품 목록})` : 변경이 실패하는 예외처리를 통해 전파시킵니다 3. 시스템은 변경된 [장바구니 집계]를 저장한다 코드 - `system.repository.save({변경된 장바구니})` 4. 반환은 없어도 됩니다. 코드 - `return` : REST 와 http status 관련 rfc 를 찾아보시면, 굳이 PUT 행위를 가진 'document put' 이 반환을 가질 필요는 없습니다 hateoas 인 경우만 반환해줍니다 ---------------------------------------------------------------------------------------------------- feat. 여기서 system::repository::load 와 system::repository::save 메소드의 sql transaction 이나 always valid, specification, 결과적 일관성 등은 주제에 벗어나 제외했습니다. ddd bounded context, aggregate pattern 에 대해 보시면 좋습니다 읽어주셔서 감사합니다. 혹시 관련해서 틀리거나, 잘못된 표현들을 지적해주시면 정말 감사하겠습니다

@j3ssu9 7 ай бұрын

@@asketeddy 늦게 보아서 죄송하고 긴 답글 정말 감사드립니다!! 이전에 프로젝트에서 ddd 관련하여 학습 목표로 적용에 대해 논의도해보고 스터디도 했었지만 제 개인적인 생각으로는 서비스가 너무 작고 오히려 잘못된 지식이 공유될 것 같다는 생각(한참 진화한 객체지향인데 그 이전인 3계층도 제대로 고도화를 못해본 걸 같음)이 들었었거든요.. 또 바운디드 컨텍스트나 이벤트 스토밍, 도메인 언어 공유 등에 대한 사항을 보고 또 개발에 그것을 반영하는 부분을 생각했을 때에 동기부여가 잘 이뤄지고 필요성을 느낌과 동시에 서비스에 대한 이해도가 풍부해야하는 디자인이라고 느꼈습니다.. 그래서 동아리 레벨에서는 한계가 있다고 느끼기도 했었고 멘토도 없어서 뭔가 복싱장에서 뉴비들끼리 자세잡아보고 연습하는.. 그런 느낌도 들었었구요. 하지만 잠깐 보면서 애그리거트 루트와 도메인 모델들이 엮여있는 부분(말씀해주신 디자인 패턴) 등에 대해서 이렇게 할 수 있구나 등등을 보고 난 후에는 점점 공부할 때 어떻게 책임을 분리해야 하는지에 대해서 도움이 되었던 것 같습니다..! 아직 한참 부족하긴 하지만 이후에 더 공부해서 저도 ddd를 적용해보고 싶은 마음이 답글 말씀 보면서 다시금 들었습니다. 이 댓글 달고 이후에 고민 후 결정한 사항은 진짜 리포지터리 인터페이스(JPA 말고)에는 도메인 지식이 포함된 워딩으로 두되, 서비스 레이어가 할 비즈니스 로직까지는 넣지 않는다. 그리고 구현체에서 사용되는 직접적으로 ORM이든 매퍼든 때려박아쓴다. 정도로 정리했습니다..!

@j3ssu9 7 ай бұрын

말씀 초반부를 다시 보니 결국 너무 당연하지만 중요한건 해당 레이어가 어떠한 책임까지 가지는 지에 대한 팀원 간의 ‘명확한 공유’일 것 같다는 생각이 드네요..!

@aAgglkw221 7 ай бұрын

진짜 너무 좋은 말씀 감사합니다... 인터넷에는 각종 이상한 사람들이 많아서... 정상적인 사람들은 포프님의 조언에 많은 도움받고 새겨듣습니다.

@Parkseheon02 7 ай бұрын

chatgpt : 적절한 함수명을 만들어줘

@hawOff 7 ай бұрын

좋은 영상 감사합니다~!! (그나저나 포프님은 피부가 갈수록 좋아지시는 듯 하네요~ ㅎㅎ)

@amam-i2h Ай бұрын

포프님 이런 경우 함수를 만들어야되는지 궁금합니다. 공중에서 벽을 밟고 점프하는 코드를 작성한다고 할 때, 만약 플레이어만 이러한 행동을 한다면 재사용 가능성이 없는데 이런 경우면 WallJump라는 함수를 만들어서 작성하지 않고 그냥 필요한 부분에 코드를 작성하는게 맞는건가요? 항상 Jump Move Attack 등 단 한 번만 쓰이더라도 함수로 작성했어서 헷갈립니다.

@포프티비 Ай бұрын

저는 함수로 안 만들 것 같지만 정답은 없죠. 인라인 함수도 있고...

@이두희-z3w 7 ай бұрын

포프님, 정적타입언어에서 반환값 명시할때 일반 자료형이 아닌 값 객체를 활용하여 시그니처에 명시하는 것도 도움이 될까요? 아니면 애초에 값 객체를 리턴할 함수면 함수 자체에서 많은 일을 하고 있는 것이라고 봐야 할까요?

@Cso_ko Ай бұрын

포프님은 당장은 한번사용하지만 , 추후에 재사용가능성이 있어보이는 로직은 함수로 작성하는편이신가요?

@포프티비 Ай бұрын

단순 가능성으로는 안 그러고요. (그러면 거의 모든걸 함수로 만들어야하니까) 그럴 가능성이 높아보일때는 미리 만드는 경우가 있습니다

@디다도-l4w 7 ай бұрын

이런 사람이 내 상사 였으면 좋겠다 배울점이 많아…

@해시브라운 7 ай бұрын

역시 난 주니어야 ㅋㅋ 제 코드의 가독성이 왜 그모양인지 이제 알겠네요 감사합니다

@kihong67 7 ай бұрын

항상 재밌게 보고 있어요… 최근에 신입으로 입사했는데 선배가 코드가 정말 더럽고 멍청하게 짭니다… 특히 메서드가 딱 말씀하신 그 꼴이에요!!!! 포프님을 선배로 생각하고 성장하겠습니다

@포프티비 7 ай бұрын

오! 든든한 후배님이 생긴거 같아 기쁩니다!

@hyonjin1118 7 ай бұрын

포프님의 주니어 시리즈를 보며 난 주니어가 아니라며 부정하다 어느 순간부터 난 주니어구나 인정하고나서 가끔 주니어 시리즈중 난 이렇지 않아 싶은 주제가 나오면 조금씩 위안을 삼고 있습니다...

@sieunj358 7 ай бұрын

꾸준히 보고 나서 느낀게 기본..역시 기본이 중요하다고 생각이 듭니다 ㅎㅎ

@포프티비 7 ай бұрын

기본기가 좋아야 성장하죠 👍

@navidev2281 7 ай бұрын

주니어 시리즈 넘모 재밌어요 나를 돌아볼수 있기도 하고 ㅋㅋㅋㅋㅋ

@Par45711 7 ай бұрын

함수명은 함수의 기능이 아니라 목적을 요약하는거구나

@wy2337 Ай бұрын

개인적으로 함수는 동일한목적에 자주사용될 것들만 써야된다 생각합니다 예를들어 무언가를 허용할때 허용이란 기능같은걸 할수로 만든다거나 .. 개발자는아니지만 파워쉘을 자주 만져야해서 보통 전 이런경우에만 쓰게되네요 ㅜㅜ

@KarmaInterrupt 7 ай бұрын

ㅋㅋㅋㅋ 이번엔 주니어가 아니다 ㅋㅋㅋㅋㅋ 현재 내 상황(전임자에 의한) - MCU 컨트롤 중... 1. 이 함수 어따 쓰는거지? 왜 쓰는거지? 2. 함수이름은 비슷한데 왜 쓴게 다 다르지? 3. 기능은 비슷한데 왜 제품마다 함수 이름이 다 다르지? 4. MCU가 두개인데 같은 계열 MCU면 함수가 다 비슷하게 쓰이는걸텐데 왜 이러지? 5. if문이 왜 함수 하나에 8개나 있지? 6. 왜 주석이 없지?

@jude_6286 7 ай бұрын

도망가세요

@KarmaInterrupt 7 ай бұрын

@@jude_6286 맞서 싸우는 중입니다.. 거의다 왔어요...

@KarmaInterrupt 7 ай бұрын

@@jude_6286 맞서 싸우고 있는 중입니다...

@KarmaInterrupt 7 ай бұрын

@@jude_6286 혼자 개척중입니다 약간 변태같지만 나름 회로공부하고 소스코드도 이해하는게 재밌어요. 다만 회사가 재촉을 해서 문제인거죠 왜 댓글이 자꾸 지워지지

@nameanonymous5762 2 ай бұрын

별생각없이 보다가 처음 함수 이름 듣고 현웃이 터져버림 ㅋㅋㅋㅋㅋ

@ryokuman1916 7 ай бұрын

와 진짜 감탄하면서 봤습니다 포프님이 말씀하신 문제를 겪고도 아직도 네이밍 이상하게 하고 있었는데...

@포프티비 7 ай бұрын

화이팅!!

@chacha-d1u 7 ай бұрын

내일 출근해서 제가 만든 함수들 다시 살펴봐야겠네요

@chrisshim2488 7 ай бұрын

비즈니스 레벨에서는 도메인을 반영해 메소드를 만들어야 한다.

@정하은-h6s 2 ай бұрын

오잉 포프님 영상 설명에 DDD 언급이 있었군요. 포프님은 DDD에 대해 긍정적으로 보시는지 궁금합니당

@포프티비 2 ай бұрын

개체지향을 몰라서 자괴감 드는 데이터베이스 프로그래머에게 이름만 바꿔서 다시 되팔아먹은 방법론이죠. DDD 전문 컨설턴트 조차 DDD로 설계해봐야 한두번에 제대로 안나온다는 걸 인정하고 있어서.... 이미 허상인건 다 드러났지만 ubiquitous language인가? 그거 쓰자고 한 것은 매우 좋게 봅니다.

@정하은-h6s 2 ай бұрын

@@포프티비 감사합니다! 영상 설명란에 '도메인 드리븐 디자인' 원칙을 바탕으로 라고 되어 있어서 궁금했습니다 ㅎㅎ 감사합니다! 자동 생성일까요?

@TheWoseven 7 ай бұрын

함수이름을 비지니스로직이 아닌 구현로직에 대응해 정한다? 가능한 일인가요? 협업을 위한 공유가 필요없은 작은 규모의 개인 프로젝트는 분석/설계없이 바로 코딩부터 들어가는 경우도 있으니 상관없겠지만, 상용 서비스 개발할 때 이런 개발이 가능한 일인가요?

@포프티비 7 ай бұрын

실제 그러는 사람들이 있으니 가능한 일 같습니다. (불가능하면 그러는 사람들이 없었겠죠?)

@ifelseifelseif 7 ай бұрын

포프님 주니어 시리즈가 좀 전 이걸 보면 코드몽키 그 자체가 아닌지 보통 저런 함수엔 또 희한한 주석이 또 같이 함께 하죠..

@jkkim6928 7 ай бұрын

이분 처음 봤는데 눈썹이 무슨 자율적인 객체인 줄

@Kkkkkkk-ej2zo 7 ай бұрын

주니어로 새로태어난 기분 좋다!!

@오웰조지-p6q 3 ай бұрын

포프님 사랑해요

@greath2325 7 ай бұрын

좋은 인사이트 감사합니다

@two-jay3475 7 ай бұрын

드디어 주니어가 아니다..!

@호빵맨주인-j3j 7 ай бұрын

주니어 컨텐츠 재밌슴다

@조영민-v8r2u 7 ай бұрын

ㅋㅋㅋㅋㅋㅋ 사장님 요즘 XX 하면 주니어에 조회수좀 달달하게 뽑으셨나보네요

@포프티비 7 ай бұрын

사실 미리 찍어놓은거라 조회수가 달달하게 나올줄 몰랐습니다.....

@shin3692 7 ай бұрын

깊게 생각하지 않고 있었는데, 다행히 크게 엇나가고 있진 않았네요 ㅎㅎㅎ

@포프티비 7 ай бұрын

멋지십니다!!

@jong243 7 ай бұрын

감사합니다..👍

@zazak_namu 7 ай бұрын

주니어 양성하는 청년

@viator-z5j 7 ай бұрын

아악 또 내일 아침 조마조마하면서 봐야하네 이미 주니어긴하지만 ..

@권도훈-o1f 7 ай бұрын

근래 본 영상중에 제일 머리가 탁트이는 영상인듯 이런거 무더기로 찍어내주세요 ㅠㅠ

@포프티비 7 ай бұрын

열심히 찍고 있습니다. 노력하겠습니다!

@임채현-f5b 7 ай бұрын

실제 코드를 통해서 예시를 같이 보여주면 좋을텐데..ㅠㅠ

@jkkim6928 7 ай бұрын

2222

@_techfnb4441 7 ай бұрын

그러면 const xxx = isEmpty(arg) || isNil(arg) 이 함수 xxx의 이름을 뭐로 지어야 할까요? empty랑 nil은 다른 거라고 생각하는데, 항상 isEmptyOrNil 짖긴 함.

@아지-d3r 7 ай бұрын

IsValid?

@_techfnb4441 7 ай бұрын

@@아지-d3r 너무 광범위 한데?? 거꾸로 isValid라고 하면 isEmpty 같은 상황을 예측 할 수 있나요?

@심심하다능-r6w 7 ай бұрын

실제 C#에 IsNullOrEmpty(); 있습니다. 즉 IsNullOrEmpty방식이 틀린 것이 아닙니다. 왜냐하면 정확하게 함수의 역할(기능)을 "무엇을 하는지(What)"로 나타내고 있잖아요. 함수가 어떻게 구현되고 있는지가 아니라 정확하게 무엇을 목적으로 구현하고 리턴하는가를 생각하라는 거죠.

@조해성조해성 7 ай бұрын

정말 유용합니다

@kyounghwanyoun2916 7 ай бұрын

주니어 시리즈 재밋네요

@주정열-n4p 7 ай бұрын

오… 이번에는 주니어가 아니야…

@trynew2244 7 ай бұрын

좋은 영상 감사합니다

@뉴뉴-y9u 7 ай бұрын

감사합니다

@jh.h92 Ай бұрын

하나의 sp에서 파라메터 값에 따라 insert와 update가 둘다 되는경우 함수명을 예를들면 SaveOrUpdate(parameterName) 처럼 만들고 주석에 파라메터가 0이면 save 0이 아니면 update로 적고 만들면 이상한가요..?? 두개로 나누자니 코드길이도 그렇고 관리가 더 어렵다고 생각했는데 조언 부탁드려요

@포프티비 Ай бұрын

DB에 저장하는 코드인거죠? 특별히 command와 query를 분리하는 패턴이 아니라면 이런 함수명을 쓰는 것은 어느정도 예외로 허용하고 있습니다. 하지만 command와 query 를 확실히 분리한 상황에서는 write()로 이름을 짓습니다. (제가 그런다는 말) 하지만 여전히 or을 쓰는 경우는 캐시에 접근할때 사용하는 getOrCreate 같은 함수가 있네요

@jh.h92 Ай бұрын

넹 감사합니다