저도 저 나름대로의 코딩 스탠다드가 있습니다 (회사 일 말고 개인 프로젝트할 때) - 어떻게 생각하시는지 궁금하네요. 1. 함수 이름에 get/set을 쓰려면 time complexity가 O(1)이어야만 함. 만약 O(1) 이상이면 `find...`나 `load...`이런식으로 다른 단어를 써서 작성 2. 함수 parameter는 Object를 pass하지 않음. 항상 field여야함 (functional programming처럼). 이렇게 되면 parameter가 많아질 수도 있는데 크게 신경 안씀 3. 포프님의 설명에서 정말 긴 코드는 함수를 나눠서 한다고 하셨는데 전 함수를 나누긴 나누는데 이렇게 긴 코드가 되면 하나의 클래스를 따로 만들어버립니다. 예를 들어 `StudentLoader` 이런식으로 말이죠 전 이런 규칙을 개인 프로젝트할 때 (github) 지키고 있는데 어떻게 생각하시는지 궁금합니다 ㅋㅋ
성급한 추상화의 관점에서 너무 지나친 함수 작성을 지양해야 한다고 동감합니다. 초기 탐색 구현 이후에 함수로 모듈화하면 쓸데없는 함수 작성을 피할 수 있었습니다. (보통 초기 탐색 구현물은 버립니다. 저 같은 보통의 프로그래머는 한번 짜봐야 그나마 나은 구현이 보이더라구요.) 내용 중에 일부 다른 의견을 보탭니다. 함수에서 입력에 따른 결과가 달라지지 않는다면, 함수의 수정이 다른 곳에 영향을 미치지 않습니다. (물론, 혹시 부작용이 있다면, 그 부작용까지 동일해야겠죠.) 이러한 경우, 동일한 이름을 그대로 사용해도 무방합니다. 입력에 따른 결과가 달라지면, 당연히 다른 이름으로 바꾸는 것이 맞습니다. 동작이 다르니 다른 함수로 봐야겠죠.
안녕하세요 포프님! 현재 프론트엔드 개발자로 일하고 있습니다. 이 영상을 보고, 또 리펙토링 2 라는 책을 읽으면서 어떻게 해야할지 혼란스럽네요. (아직 다 읽진 않았습니다만..) 책에서는 함수로 잘게 나눴을때 장점이 코드를 이해하기 쉽다. 테스트 코드를 작성하기 좋다. 유지보수 하기 좋다가 있는것 같은데. 아무래도 제가 일하는 곳에서는 모든걸 함수! 까진 아니더라도 코드를 더 읽기 쉽게 만들 수 있다면 한번 쓰이더라도 나누자. 쪽인것 같습니다. 성능적인 관점에서는 많이 우려하지않고, 유지보수 측면에서 강하게 이쪽을 선호하는 듯 해요. 포프님은 위와같이 작성하는게 오히려 유지보수를 어렵게 한다고 했는데. 저는 그게 잘 상상이 안갑니다. 함수를 나누면 왜 유지보수가 더 어려워지는 건가용? 영상에서는 쓰이는 곳에 모두 고쳐야한다. 라고 해주셨는데 만약 한곳에만 쓰이는 함수를 분리한 경우에는 어떤 면에서 불편해지는지 궁금합니다. :) 더 디테일한 영상 만들어주시면 넘넘 더 좋구요 ㅎㅎㅎ
어떤 함수가 있습니다. 그 함수를 변경 하려고 합니다. (이유는 리팩토링일 수도 버그 수정일 수도 있음) 변경하다가 함수 시그니처가 바뀌거나, 매개변수로 들어오는 데이터에 대한 가정이 바뀝니다. (꼬꼬마들은 이런 일이 있으면 제대로된 변경이나 리팩토링이 아니라고 하지만 실무하다보면 이런 일은 빈번하죠) 그러면 이 함수를 호출하는 곳을 모두 찾아 코드를 고쳐야합니다. 그 함수가 라이브러리화 되어있거나, 그 함수가 있는 Git리포를 참조하는 다른 여러 git리포가 있다면 과연 이 함수가 어디서 호출되는지 쉽게 알 수 있을까요? ('한 곳에서만 사용하는 함수'라는 건 이미 함수들을 이 찾는 과정을 거쳤기에 아는 결과일 뿐이며, 방대한 코드베이스에서 거기에 들어가는 노력과 시간, 따라서 그걸 제대로 안 하는 80%의 개발자들을 간과하지 마세요) 따라서 웬만하면 안고치거나 확인조차 안하고 고쳐서 다른 곳이 깨지곤 합니다. 둘다 유지보수 적인 측면에서는 별로죠. 마찬가지 이유로 실제 제대로 유지보수 잘 되고 있는 프래임워크(좋은 예. .net core)를 보시면 함수가 재활용성 기준으로 나뉩니다. 함수로 잘게 나누면 유닛 테스트에 도움은 됩니다.(그리고 보통 TDD를 하죠) 하지만 TDD에서 사용하는 유닛테스트는 테스트 중에 가장 버그찾는 효율이 적은 테스트며, 더 중요하고 효율좋은 다른 테스트에서는 불필요한 함수분할을 요하지 않습니다.
@@포프티비 답변 주셔서 너무 감사합니다! 예시 들어주신 것들로 더 많이 이해가 되었습니다. 조금 더 질문드려도 괜찮을까요? 만약 회사의 개발 문화가 개인이 추구하는 것과 다른 상황에서 어떻게 효과적으로 더 나은 프로그래머로 성장 할 수 있을까요? 현재 떠오르는 방법은 회사 일은 회사에 맞춰서 하고, 혼자 공부할때 추구하는 것을 익힌다. 일것 같은데요. 가장 좋은건 회사 일을 하면서 성장하는 것이라고 생각하고 있어서요. 포프님은 혹시 어떤 생각을 갖고 계시는지 궁금합니다.
혼자서 C# 개발을 하다보니, 일반적인 상황에서 모두가 공유하는 좋은 방법을 배울 방법이 없었습니다. 이번에 Null 관련된 부분도 배우면서, 생각이 많아졌고, 더 나은 코드를 쓸수 있을 것 같습니다. 지금까지 Null 관련 처리를 할때 Null이 들어온다면? 라고 생각을 해서, If문으로 먼저 Null 체크부터 하곤 했거든요. 그냥 Null이 안들어 온다고 생각해버리면 If 한번을 줄일 수 있으니 더 간결하고 좋은 코드가 된다는 말씀에 공감이 됩니다. 내부함수에 대해서는 어떻게 생각하시는지 여쭈어도 될까요? 일단 기본 전제로, 함수를 쓸때에 읽기 편하면 최고(무조건은 아니지만)라고 생각합니다. 수도코드를 작성하고 기능들을 구현하기 시작하면, 주석 밑에 기능, 주석 밑에 기능 형태로 코드구조가 생기고는 합니다. 이럴때에 차라리 내부함수로 구현해서 주석대신에 함수이름으로 씁니다. 이런 형태가 저는 가독성이 좋던데, 혹시 이 방법이 다른 분들이 읽으시기에 편할지 늘 궁금합니다. 내부함수 또한 반복해서 사용해야 하는게 아니라면, 아에 안쓰는게 나은지요? 아니면, 주석 대신에 사용하는 방법으로도 괜찮은지요?
저도 분명 그런식으로 내부 함수를 작성하는 경우가 있는데 여전히 함수를 만들기보다는 스코프를 만들고 그 위에 주석을 다는 편입니다. 아무래도 함수호출에 수반되는 오버헤드와 유지보수성에 신경이 쓰여서요. 함수가 나오면 그 함수를 사용하는 코드들이 여럿일수 있어서 뭐하나 고쳐도 확인해야할 게 많아지더라구요
보통 가독성 관련 책들 코딩의 기술, 클린코드, 코드컴플릿트 등등 보면한번 쓰더라도 복잡한 조건식이나 한 눈에 파악이 안되는 한 부분 로직들을 함수화 해서 네이밍으로 우선 이게 뭘 하는 건지 파악하게해서 흐름을 빠르게 이해하고 필요하면 세부 구현을 가서 확인하게 하는 방식을 쓰라고 하는데 좀 더 오버해서 한 눈에 파악 가능한 형태라도 다 함수화 하는 성향의 프로그래머들도 있는데요이런 후자 케이스를 말씀하시는건가요? 아님 무조건 한번만 쓰는 코드는 왠만해서 함수화 하지 말자는 말씀이신가요?
김포프님! 저는 C#,Vision SDK로 프로그램을 만드는 FA산업계열에서 일하는 초년생인데요 이번 동영상에서 많은걸 공감하면서 찔렸어요ㅠ (,try catch도배..,함수선언 등등) 저는 소기업에 다니다보니 코치해주는 사람이 없어요 ㅠ 이번에 C#책 만드시는걸로 아는데 코딩스탠다드 같은 내용도 포함되어있는건가요?? 동영상 내용이 너무 좋네요!
C#의 공식 컨벤션에서였나 C# 공식 문서 어딘가에서 최적화된 함수의 라인수는 17줄이었나 하고 정의했던걸 본적이 있었는데 사실 요새 PC수준에서 극한의 퍼포먼스를 내야하는 프로그램이 아닌 이상 불필요한 분기를 줄이고 가독성을 높이는 게 더 좋은 판단이라고 생각하네요. 처음 코드를 (자바에서) 배울 때 객체지향의 3대 요소였나?? 에서 캡슐화(encapsulation)를 잘못 이해하거나 오해해서 무작위로 함수를 나누도록 만든 교육시스템의 문제라고 생각합니다. -_-a
언클밥의 클린 코드 책을 보면서 포프님 영상과 계속 비교해보고 있는데요. 클린 코드에서는 함수는 무조건 작게, 함수는 추상화 수준에서 무조건 한 가지 일을 해야함. 그러므로 한 가지 일을 하는 함수를 함수 안에 계속 호출하여(내려가기 규칙) 코드의 가독성을 높이자. 라고 설명하여 포프님과는 조금 반대 의견으로 설명하고 있습니다. 하지만 추상화 관점에서 한 가지 일을 해야 한다는 개념도 책에선 설명이 부족하고, 좋다고 생각하는 코드는 계속 변하기 때문에 무조건 책에 있는 말이 정답이라 생각하지 않습니다. 포프님 의견처럼 정말 간단한 코드, 한 번만 쓰이는 코드이거나 앞으로도 한 번만 쓰일 것 같은 코드는 함수로 만들지 안되, 함수는 한 가지 일을 할 수 있도록 가독성 높은 코드를 작성해야겠습니다.
엉클밥의 클린코드는 실무에서 많은 논란이 있는 책입니다. 특히 자바 진영을 벗어나면 배척하는 분위기도 매우 강하고요. 물론 그 책이 한명이 쓴 책이 아니라 누가 썼냐에 따라 헛소리도 좋은 조언도 있는 거 같습니다. 제대로 실무하신 분들이 쓴 글일수록 괜찮고요. 참고로 엉클밥 본인은 자기회사 운영외에 검증 가능한 실무 경험은 거의 없으신 분입니다. (그리고 그 회사에는 현재 그분의 아들이 일하고 있고요)
역시 게임과 같이 성능 문제가 중요한 위치에 있는 포프님의 생각은 불필요한 함수 호출을 줄이자는 거군요. 말씀하신 한 줄 코드도 함수로 구현하는 사람들은 주로 'Clean Code'를 지향하는 사람들이더군요. 주석 첨가나 한 함수 내에 코드를 여러 줄 작성하는 것을 일종의 금기로 여기고 함수 이름을 주석화해서 코드 자체가 읽기 쉬운 문서가 되게 하자는 게 목표더라구요. 글쎄요... 간단한 텍스트 출력 프로그램 만들면서도 지나치게 클래스 나누고 메소드 구현하는 것에서 희열을 느끼는 사람들이 주로 이런 '계통'이 아닌가 싶어요. 그 사람들도 게임과 같이 퍼포먼스를 극한으로 끌어내야 할 때는 포프님과 같은 결정을 하게 되지 않을까요?^^ 그나저나 표정이 많이 편해지신 것 같아요. 무슨 좋은 일 있으신가요~~?? ^o^
3:59 💊코드 짤때 주의하겠습니다 내가 볼려고 정리 코딩 스탠다드와 코딩 컨벤션 요약 불필요한 함수 작성 금지 짧은 코드도 굳이 함수로 만들지 말라. 예를 들어, 단어 하나를 읽어 변수에 저장하는 코드도 굳이 함수로 만들 필요가 없다. 함수는 약속이다 함수는 인터페이스와 같다. 함수 이름과 매개변수는 그 함수가 무엇을 할지 약속한다. 함수 수정의 어려움 함수를 수정하면 그 함수를 호출하는 모든 코드를 확인해야 한다. 함수가 여러 곳에서 호출된다면, 모든 호출 코드를 검토해야 한다. 간단한 함수는 코드로 직접 작성 한 번만 호출되는 간단한 코드는 함수로 만들지 않고, 직접 작성하는 것이 좋다. 코드 리뷰의 중요성 코드 리뷰는 코드의 실수를 잡아주는 과정이다. 코드가 변경될 때, 변경된 코드가 다른 곳에 영향을 미치는지 확인해야 한다. 코드 리뷰의 어려움 코드를 리뷰하려면 직접 컴퓨터에서 코드를 확인해야 하는 번거로움이 있다. 재사용 가능한 함수 작성 함수는 여러 번 호출되거나 논리적으로 여러 번 호출될 필요가 있는 경우에 작성한다. 반복되는 코드는 함수로 만들어 유지보수를 쉽게 한다. 중복 코드 제거 동일한 코드가 여러 번 등장하면 함수로 작성하여 유지보수를 단순화한다. 긴 코드의 문제 코드가 너무 길어지면 함수로 분리하여 가독성을 높인다. 단, 너무 잦은 함수 호출로 성능 저하가 발생할 수 있다는 점을 유의한다. 코드 스코프 관리 코드 블록을 중괄호로 구분하여 변수가 섞이는 것을 방지한다. C#의 #region 등을 사용하여 코드 블록을 시각적으로 구분한다. 널(Null) 처리 함수의 매개변수에 널이 들어올 수 있으면 변수 이름에 'Nullable'을 명시한다. 반환값도 널이 들어올 수 있으면 변수 이름에 'Nullable'을 명시한다. 함수 내부에서는 널이 아닌 값을 가정하고 코딩하며, 널 체크는 바운더리에서만 수행한다. C++의 널 레퍼런스 문제 해결 C++는 널이 될 수 없는 레퍼런스를 도입하여 이 문제를 해결했다. 다른 언어들도 이 문제를 해결하려고 노력하고 있다. 모던 프로그래밍 언어의 한계 많은 모던 프로그래밍 언어들이 널 포인터와 널 레퍼런스 문제를 완전히 해결하지 못했다. 코딩 스탠다드에 의존하여 이 문제를 해결하는 것이 필요하다. 상세 설명 불필요한 함수 작성 금지: 모든 코드를 함수로 작성하면 코드가 지나치게 복잡해지고 유지보수가 어려워집니다. 특히 간단한 작업은 함수로 만들지 않고 직접 코드를 작성하는 것이 효율적입니다. 예를 들어, 단어 하나를 읽어오는 간단한 작업을 함수로 만들지 않고 한 줄로 작성하는 것이 더 나을 수 있습니다. 함수는 약속이다: 함수는 특정 작업을 수행하는 약속입니다. 함수 이름과 매개변수를 통해 함수가 어떤 작업을 할지 명확히 알 수 있어야 합니다. 이렇게 하면 코드를 읽는 사람들이 함수가 무엇을 하는지 쉽게 이해할 수 있습니다. 함수 수정의 어려움: 함수를 수정하면 그 함수를 호출하는 모든 코드를 확인해야 하는 부담이 생깁니다. 특히, 함수가 여러 곳에서 호출된다면, 모든 호출 코드를 확인하고 수정해야 하는 어려움이 있습니다. 이는 함수가 제대로 동작하지 않을 경우, 전체 시스템에 영향을 미칠 수 있기 때문입니다. 간단한 함수는 코드로 직접 작성: 간단한 작업을 위해 함수를 만들기보다는, 그 작업을 직접 코드로 작성하는 것이 유지보수와 이해에 더 용이합니다. 예를 들어, 단 한 번만 호출되는 작업이라면 굳이 함수를 만들지 않고 코드로 직접 작성하는 것이 더 효율적입니다. 코드 리뷰의 중요성: 코드 리뷰는 코드가 올바르게 작성되었는지, 실수가 없는지 확인하는 중요한 과정입니다. 코드가 변경될 때, 그 변경이 다른 부분에 영향을 미칠 수 있으므로, 코드 리뷰를 통해 이러한 영향을 최소화해야 합니다. 또한, 코드 리뷰를 통해 코드의 질을 향상시키고, 팀원 간의 지식 공유도 가능합니다. 코드 리뷰의 어려움: 코드 리뷰를 할 때, 모든 코드를 직접 컴퓨터에서 찾아보고 확인하는 과정은 번거롭고 시간이 많이 걸릴 수 있습니다. 특히, 함수가 여러 곳에서 호출된다면 모든 호출 지점을 일일이 검토해야 하므로 더욱 어렵습니다. 재사용 가능한 함수 작성: 함수는 재사용 가능해야 하며, 여러 번 호출되거나 반복적으로 사용될 가능성이 있는 경우에 작성합니다. 이를 통해 코드의 중복을 줄이고, 유지보수를 쉽게 할 수 있습니다. 중복 코드 제거: 동일한 코드가 여러 번 등장하면 함수로 작성하여, 한 군데만 수정하면 되는 구조로 만드는 것이 좋습니다. 이는 코드의 일관성을 유지하고, 수정 시 실수를 줄이는 데 도움이 됩니다. 긴 코드의 문제: 코드가 너무 길어지면 가독성이 떨어지고, 유지보수가 어려워집니다. 이러한 경우, 코드를 적절히 함수로 분리하여 가독성을 높이는 것이 좋습니다. 다만, 너무 잦은 함수 호출로 인한 성능 저하도 고려해야 합니다. 코드 스코프 관리: 코드 블록을 중괄호로 구분하여 변수가 섞이는 문제를 방지합니다. 또한, C#의 #region 등을 사용하여 코드 블록을 시각적으로 구분하면, 코드의 가독성을 높일 수 있습니다. 널(Null) 처리: 함수의 매개변수에 널이 들어올 수 있으면 변수 이름에 'Nullable'을 명시합니다. 반환값도 마찬가지로 'Nullable'을 명시합니다. 함수 내부에서는 널이 아닌 값을 가정하고 코딩하며, 널 체크는 바운더리에서만 수행합니다. 이를 통해 코드의 가독성을 높이고 오류를 줄일 수 있습니다. C++의 널 레퍼런스 문제 해결: C++는 널이 될 수 없는 레퍼런스를 도입하여 이 문제를 해결했습니다. 이는 널 포인터로 인한 오류를 줄이고, 코드의 안정성을 높이는 데 도움이 됩니다. 모던 프로그래밍 언어의 한계: 많은 모던 프로그래밍 언어들이 아직 널 포인터와 널 레퍼런스 문제를 완전히 해결하지 못했습니다. 이로 인해 프로그래머는 코딩 스탠다드에 의존하여 이러한 문제를 해결해야 합니다. 코딩 스탠다드의 중요성: 프로그래머가 널 포인터와 같은 문제를 효과적으로 처리하기 위해서는 코딩 스탠다드를 잘 준수해야 합니다. 이는 특히 웹 개발보다는 게임 개발이나 시스템 프로그래밍 같은 분야에서 더 중요합니다. 이러한 분야에서는 널 포인터로 인한 오류가 시스템 전체에 큰 영향을 미칠 수 있기 때문입니다.
코딩 스탠다드 문서와 영상을 이제서야 제대로 봤네요... 그동안 스탠다드 조차 인지 못하고 방황하던 시간이 너무나 아깝네요 ㅠ
확실한 방향성을 주셔서 감사합니다.
로직을 함수로 분리한다는게 단순히 보기 좋기 위해서만을 목적으로 두기엔 이 함수의 변경전파에 의해 유지보수성이 낮아질 수 있어 이런 점을 고려야해야한다라고도 들리네요.
저도 저 나름대로의 코딩 스탠다드가 있습니다 (회사 일 말고 개인 프로젝트할 때) - 어떻게 생각하시는지 궁금하네요.
1. 함수 이름에 get/set을 쓰려면 time complexity가 O(1)이어야만 함. 만약 O(1) 이상이면 `find...`나 `load...`이런식으로 다른 단어를 써서 작성
2. 함수 parameter는 Object를 pass하지 않음. 항상 field여야함 (functional programming처럼). 이렇게 되면 parameter가 많아질 수도 있는데 크게 신경 안씀
3. 포프님의 설명에서 정말 긴 코드는 함수를 나눠서 한다고 하셨는데 전 함수를 나누긴 나누는데 이렇게 긴 코드가 되면 하나의 클래스를 따로 만들어버립니다. 예를 들어 `StudentLoader` 이런식으로 말이죠
전 이런 규칙을 개인 프로젝트할 때 (github) 지키고 있는데 어떻게 생각하시는지 궁금합니다 ㅋㅋ
+KimchiMan 1. 좋네요. 2.이건 성능때문에 전 노노. 몇개이상이면 오브젝트 넣고 컨스트화시키는게 맞다고 생각. 3. 그것까진 크게 생각안해봐서 무의견 :)
get/set, find/load으로 작성하는거 굉장히 좋은 것 같네요!
제가 얘기할 짬은 아니지만 1번은 좋다는데 한표 던지고 갑니다
1번 진짜 기발한 것 같네요 정말 좋은 생각인것 같습니다.
1은 확실히 샣각해보니 다르긴하눙
성급한 추상화의 관점에서 너무 지나친 함수 작성을 지양해야 한다고 동감합니다.
초기 탐색 구현 이후에 함수로 모듈화하면 쓸데없는 함수 작성을 피할 수 있었습니다.
(보통 초기 탐색 구현물은 버립니다. 저 같은 보통의 프로그래머는 한번 짜봐야 그나마 나은 구현이 보이더라구요.)
내용 중에 일부 다른 의견을 보탭니다.
함수에서 입력에 따른 결과가 달라지지 않는다면, 함수의 수정이 다른 곳에 영향을 미치지 않습니다.
(물론, 혹시 부작용이 있다면, 그 부작용까지 동일해야겠죠.)
이러한 경우, 동일한 이름을 그대로 사용해도 무방합니다.
입력에 따른 결과가 달라지면, 당연히 다른 이름으로 바꾸는 것이 맞습니다.
동작이 다르니 다른 함수로 봐야겠죠.
안녕하세요 포프님! 현재 프론트엔드 개발자로 일하고 있습니다. 이 영상을 보고, 또 리펙토링 2 라는 책을 읽으면서 어떻게 해야할지 혼란스럽네요. (아직 다 읽진 않았습니다만..)
책에서는 함수로 잘게 나눴을때 장점이 코드를 이해하기 쉽다. 테스트 코드를 작성하기 좋다. 유지보수 하기 좋다가 있는것 같은데.
아무래도 제가 일하는 곳에서는 모든걸 함수! 까진 아니더라도 코드를 더 읽기 쉽게 만들 수 있다면 한번 쓰이더라도 나누자. 쪽인것 같습니다.
성능적인 관점에서는 많이 우려하지않고, 유지보수 측면에서 강하게 이쪽을 선호하는 듯 해요.
포프님은 위와같이 작성하는게 오히려 유지보수를 어렵게 한다고 했는데. 저는 그게 잘 상상이 안갑니다. 함수를 나누면 왜 유지보수가 더 어려워지는 건가용? 영상에서는 쓰이는 곳에 모두 고쳐야한다. 라고 해주셨는데 만약 한곳에만 쓰이는 함수를 분리한 경우에는 어떤 면에서 불편해지는지 궁금합니다. :) 더 디테일한 영상 만들어주시면 넘넘 더 좋구요 ㅎㅎㅎ
어떤 함수가 있습니다. 그 함수를 변경 하려고 합니다. (이유는 리팩토링일 수도 버그 수정일 수도 있음) 변경하다가 함수 시그니처가 바뀌거나, 매개변수로 들어오는 데이터에 대한 가정이 바뀝니다. (꼬꼬마들은 이런 일이 있으면 제대로된 변경이나 리팩토링이 아니라고 하지만 실무하다보면 이런 일은 빈번하죠)
그러면 이 함수를 호출하는 곳을 모두 찾아 코드를 고쳐야합니다. 그 함수가 라이브러리화 되어있거나, 그 함수가 있는 Git리포를 참조하는 다른 여러 git리포가 있다면 과연 이 함수가 어디서 호출되는지 쉽게 알 수 있을까요? ('한 곳에서만 사용하는 함수'라는 건 이미 함수들을 이 찾는 과정을 거쳤기에 아는 결과일 뿐이며, 방대한 코드베이스에서 거기에 들어가는 노력과 시간, 따라서 그걸 제대로 안 하는 80%의 개발자들을 간과하지 마세요)
따라서 웬만하면 안고치거나 확인조차 안하고 고쳐서 다른 곳이 깨지곤 합니다. 둘다 유지보수 적인 측면에서는 별로죠.
마찬가지 이유로 실제 제대로 유지보수 잘 되고 있는 프래임워크(좋은 예. .net core)를 보시면 함수가 재활용성 기준으로 나뉩니다.
함수로 잘게 나누면 유닛 테스트에 도움은 됩니다.(그리고 보통 TDD를 하죠) 하지만 TDD에서 사용하는 유닛테스트는 테스트 중에 가장 버그찾는 효율이 적은 테스트며, 더 중요하고 효율좋은 다른 테스트에서는 불필요한 함수분할을 요하지 않습니다.
@@포프티비 답변 주셔서 너무 감사합니다! 예시 들어주신 것들로 더 많이 이해가 되었습니다.
조금 더 질문드려도 괜찮을까요?
만약 회사의 개발 문화가 개인이 추구하는 것과 다른 상황에서 어떻게 효과적으로 더 나은 프로그래머로 성장 할 수 있을까요?
현재 떠오르는 방법은 회사 일은 회사에 맞춰서 하고, 혼자 공부할때 추구하는 것을 익힌다. 일것 같은데요.
가장 좋은건 회사 일을 하면서 성장하는 것이라고 생각하고 있어서요. 포프님은 혹시 어떤 생각을 갖고 계시는지 궁금합니다.
본인이 추구하는 게 맞다고 생각하고 책임질.자신 있으면 이직하세요. 아니면 지금 회사에서 먼저 인정 받으시고요.
@@포프티비 답변 감사합니다. 답변 주신내용 읽으면서 또 혼자 고민해보면서 어느정도 방향이 잡히는것 같아요. 일단 경험 더 쌓아보겠습니다. 감사합니다 포프님!
좋은 정보 감사합니다. 개발 10년해도 늘 고민되는 게 함수...그놈의 타이밍 등등
역시 코딩에서는 개인의 개성이 드러나는 듯 합니다. ㅎㅎ
저는 깃 에서 긁어온 함수 덕지덕지 + 쓸모없는 함수 + 주석없음 의 아름다운 삼박자를 맞추어서 짜죠. ㅎㅎ
좋은 방법을 배워갑니다 감사해요~
혼자서 C# 개발을 하다보니, 일반적인 상황에서 모두가 공유하는 좋은 방법을 배울 방법이 없었습니다.
이번에 Null 관련된 부분도 배우면서, 생각이 많아졌고, 더 나은 코드를 쓸수 있을 것 같습니다.
지금까지 Null 관련 처리를 할때 Null이 들어온다면? 라고 생각을 해서, If문으로 먼저 Null 체크부터 하곤 했거든요.
그냥 Null이 안들어 온다고 생각해버리면 If 한번을 줄일 수 있으니 더 간결하고 좋은 코드가 된다는 말씀에 공감이 됩니다.
내부함수에 대해서는 어떻게 생각하시는지 여쭈어도 될까요?
일단 기본 전제로, 함수를 쓸때에 읽기 편하면 최고(무조건은 아니지만)라고 생각합니다.
수도코드를 작성하고 기능들을 구현하기 시작하면, 주석 밑에 기능, 주석 밑에 기능 형태로 코드구조가 생기고는 합니다.
이럴때에 차라리 내부함수로 구현해서 주석대신에 함수이름으로 씁니다. 이런 형태가 저는 가독성이 좋던데, 혹시 이 방법이 다른 분들이 읽으시기에 편할지 늘 궁금합니다.
내부함수 또한 반복해서 사용해야 하는게 아니라면, 아에 안쓰는게 나은지요? 아니면, 주석 대신에 사용하는 방법으로도 괜찮은지요?
저도 분명 그런식으로 내부 함수를 작성하는 경우가 있는데 여전히 함수를 만들기보다는 스코프를 만들고 그 위에 주석을 다는 편입니다. 아무래도 함수호출에 수반되는 오버헤드와 유지보수성에 신경이 쓰여서요. 함수가 나오면 그 함수를 사용하는 코드들이 여럿일수 있어서 뭐하나 고쳐도 확인해야할 게 많아지더라구요
@@포프티비 바쁘신 와중에도 댓글 읽어주시고, 답변 달아주셔서 감사합니다!
포프님께서 답글 주신대로 코딩 스타일을 바꾸어 나가보도록 하겠습니다.
보통 가독성 관련 책들 코딩의 기술, 클린코드, 코드컴플릿트 등등 보면한번 쓰더라도 복잡한 조건식이나 한 눈에 파악이 안되는 한 부분 로직들을 함수화 해서 네이밍으로 우선 이게 뭘 하는 건지 파악하게해서 흐름을 빠르게 이해하고 필요하면 세부 구현을 가서 확인하게 하는 방식을 쓰라고 하는데 좀 더 오버해서 한 눈에 파악 가능한 형태라도 다 함수화 하는 성향의 프로그래머들도 있는데요이런 후자 케이스를 말씀하시는건가요? 아님 무조건 한번만 쓰는 코드는 왠만해서 함수화 하지 말자는 말씀이신가요?
+n 한번만 쓰는 코드는 왠만해서 함수화하지 말자는 주의에요. 함수는 만드는 순간 책임을 져야한다는 주의. 나중에 버그찾아 고치거나 함수내용 추가하는순간 확인할게 많아지니까요.
+n 참고로 클린코드는 예전에 익셉션 부분만 잠깐 봤는데 에러코드가 문제라면서 든 예제가 익셉션써도 그대로 문제인데... 전혀 다른 예제를 보여주면서 문제가 해결되었단 식으로 설명하는거 보고... 그냥 내다버린 책 ㅡ.ㅡ
ㅋㅋ 읽기 좋은 코드가 좋은 코드다 읽은 뒤에 클린코드 2장인가 까지 보다가 말았었는데 이셉션 부분에 그런게 있었군요
언젠가 읽어야지 생각하고 있었는데 안 읽어야겠네요 ㅎ
회사에서 cto님이 읽어보라고 권한 책인데... 왜 권한 걸까요? 전 책이 넘 두꺼워 좀 보다 포기했죠....
좋은 영상 감사합니다.
캬 null 관련 부분에서 부랄을 탁 쳤습니다
+KimchiMan 터져요 조심하세요 ㅋㅋㅋ
포프TV ㅋㅋㅋ 유머 감각
부랄탁
김포프님! 저는 C#,Vision SDK로 프로그램을 만드는 FA산업계열에서 일하는 초년생인데요 이번 동영상에서 많은걸 공감하면서 찔렸어요ㅠ (,try catch도배..,함수선언 등등) 저는 소기업에 다니다보니 코치해주는 사람이 없어요 ㅠ 이번에 C#책 만드시는걸로 아는데 코딩스탠다드 같은 내용도 포함되어있는건가요?? 동영상 내용이 너무 좋네요!
+Y 완전 초짜용 책입니다 . 코당 스탠다드 이야기는 앞으로 비디오로 좀더 만들께요
헛 1빠다! 오늘은 운이 좋을것이야!
+한동준 로또 1등 당첨...
혹시 코드가 길어지는 케이스에서 블록 스코프로 나누는 방법 이외에 람다함수+IIFE로 처리하는 방법에 대해서는 어떻게 생각하시나요..? 한번만 쓰인다는 보장이 있을 때는 괜찮은 방법이려나요?
블록 스코프보다 람다함수가 가지는 장점이 존재해야 하는데.... 그게 제 눈에는 딱히 보이지 않아서 일단은 전 안 쓸 거 같은데... 장점을 알고 계시면 좀 알려주소서 센세~
@@포프티비 변수 선언 및 할당이 한번에(초기화) 이뤄져도 되는 상황에서는 전자가 깔끔해보인다는 제 선호도가 들어가있어서 질문 드려봤습니다.
이런데 정말 금같은 영상.. 돈주고도 못살 영상
돈주세요
@@포프티비 드.. 드리겠습니다
오오 BCIT를 안가도 이정도 강의는 들을수있다니 감사합니당😆
+장유진 비씨아이티에선 안하는 강의... 그냥 문서던져주고 알아서 하라 그래요 ㅋㅋㅋㅋ
포프TV 읭..?😅 자기학교 학생들보다 포프티비 시청자들을 애정하는 포프교슈님....?!!?!?! 구독자로서는 좋지만 의외(?)군요ㅋㅋ 아니면 그곳학생들은 굳이 이런거까지 강의안해도 알아서잘하는건감..
+장유진 저만의 것을 좋아합니다. 제가 학교를 차린다면 비씨아이티의 80프로는 뜯어고칠거 같아요...
포프TV 내 강의 이지만 내맘대로 할 수 없는 부분이 많으신건가욥?😰 그런 고충이 있으실줄은 몰랐네요 커리큘럼은 좋지만 교수님들 재량이 너무 없는 곳인걸까요 실력 제대로 길러주는 학교로 추천하셔서 긍정적으로만 생각했는데
+장유진 제 강의은 제맘대로 되죠. 전체 과정을 뜯어고치고 싶은거지 ㅎㅎㅎ
새로운거 배워갑니다 항상 고마워요!
C#의 공식 컨벤션에서였나 C# 공식 문서 어딘가에서 최적화된 함수의 라인수는 17줄이었나 하고 정의했던걸 본적이 있었는데 사실 요새 PC수준에서 극한의 퍼포먼스를 내야하는 프로그램이 아닌 이상 불필요한 분기를 줄이고 가독성을 높이는 게 더 좋은 판단이라고 생각하네요. 처음 코드를 (자바에서) 배울 때 객체지향의 3대 요소였나?? 에서 캡슐화(encapsulation)를 잘못 이해하거나 오해해서 무작위로 함수를 나누도록 만든 교육시스템의 문제라고 생각합니다. -_-a
또 최근에는 함수 내부에 익명함수나 내부함수를 구현할 수 있도록 해줌으로써 그런 가독성 부분의 향상을 위한 Featrue들이 추가되는 것을 보면 언어를 작성함에 어떤 부분에 초점을 가지는지 알 수 있는 것도 같아요.
+윤지완 캡슐화 추상화쪽은 저도 그리 생각해요 제대로 써보고 이해도 안한 분들이 선생하신 경우가 많아서... ㅡ.ㅡ
+윤지완 익명함수는 가독성을 더 떨어뜨린다 생각합니다 특히 ... 디버깅 또는 크래스 덤프 중에 콜스택에 함수이름이 제대로 안보여서... ㅡ.ㅡ
아 그렇네요. ㅋㅋㅋ 혹시나 저 때문에 오해하시는 분들이 안계셨으면 좋겠습니다 ~~
소리 크기 좀만 키워주세요 X _ x
+hj lee 마이크가 후져서 그러면 윗부분 소리가 너무 깨져요 ㅡ.ㅡ
하하하 최종적으로 AoP 패러다임의 승리로구나!
언클밥의 클린 코드 책을 보면서 포프님 영상과 계속 비교해보고 있는데요.
클린 코드에서는 함수는 무조건 작게, 함수는 추상화 수준에서 무조건 한 가지 일을 해야함. 그러므로 한 가지 일을 하는 함수를 함수 안에 계속 호출하여(내려가기 규칙) 코드의 가독성을 높이자.
라고 설명하여 포프님과는 조금 반대 의견으로 설명하고 있습니다. 하지만 추상화 관점에서 한 가지 일을 해야 한다는 개념도 책에선 설명이 부족하고, 좋다고 생각하는 코드는 계속 변하기 때문에 무조건 책에 있는 말이 정답이라 생각하지 않습니다.
포프님 의견처럼 정말 간단한 코드, 한 번만 쓰이는 코드이거나 앞으로도 한 번만 쓰일 것 같은 코드는 함수로 만들지 안되, 함수는 한 가지 일을 할 수 있도록 가독성 높은 코드를 작성해야겠습니다.
엉클밥의 클린코드는 실무에서 많은 논란이 있는 책입니다. 특히 자바 진영을 벗어나면 배척하는 분위기도 매우 강하고요.
물론 그 책이 한명이 쓴 책이 아니라 누가 썼냐에 따라 헛소리도 좋은 조언도 있는 거 같습니다. 제대로 실무하신 분들이 쓴 글일수록 괜찮고요.
참고로 엉클밥 본인은 자기회사 운영외에 검증 가능한 실무 경험은 거의 없으신 분입니다. (그리고 그 회사에는 현재 그분의 아들이 일하고 있고요)
@@포프티비 답변 감사합니다. 포프님ㅎㅎ
try catch 예외처리는 진짜 써본적이 없네...
인라인 함수를 활용하는 것은 어떤가요?
+유재영 인라인 함수는 인라인 된단 보장이 없습니다 :)
포프TV 아 그렇구나 감사합니다 ㅎ
역시 게임과 같이 성능 문제가 중요한 위치에 있는 포프님의 생각은 불필요한 함수 호출을 줄이자는 거군요.
말씀하신 한 줄 코드도 함수로 구현하는 사람들은 주로 'Clean Code'를 지향하는 사람들이더군요.
주석 첨가나 한 함수 내에 코드를 여러 줄 작성하는 것을 일종의 금기로 여기고
함수 이름을 주석화해서 코드 자체가 읽기 쉬운 문서가 되게 하자는 게 목표더라구요.
글쎄요... 간단한 텍스트 출력 프로그램 만들면서도 지나치게 클래스 나누고 메소드 구현하는 것에서
희열을 느끼는 사람들이 주로 이런 '계통'이 아닌가 싶어요.
그 사람들도 게임과 같이 퍼포먼스를 극한으로 끌어내야 할 때는 포프님과 같은 결정을 하게 되지 않을까요?^^
그나저나 표정이 많이 편해지신 것 같아요. 무슨 좋은 일 있으신가요~~?? ^o^
+밤밤밤 결국 여러명이 코드 짜기 시작하면 성능외에도 유지보수측면에서 한번만 사용되는 함수가 피곤해집니다.. :)
@user-vb7kx7hj5r 중괄호로 스코프를 나눠주고 스코프마다 주석을 달아주면
함수로 가독성을 높이는것과 동일한효과를 줄수있습니다
문송합니다~:) 포프님에 대한 제 마음도 코딩할 수만 있다면... 그거슨 무한루프...
❤️
3:59 💊코드 짤때 주의하겠습니다
내가 볼려고 정리
코딩 스탠다드와 코딩 컨벤션
요약
불필요한 함수 작성 금지
짧은 코드도 굳이 함수로 만들지 말라.
예를 들어, 단어 하나를 읽어 변수에 저장하는 코드도 굳이 함수로 만들 필요가 없다.
함수는 약속이다
함수는 인터페이스와 같다.
함수 이름과 매개변수는 그 함수가 무엇을 할지 약속한다.
함수 수정의 어려움
함수를 수정하면 그 함수를 호출하는 모든 코드를 확인해야 한다.
함수가 여러 곳에서 호출된다면, 모든 호출 코드를 검토해야 한다.
간단한 함수는 코드로 직접 작성
한 번만 호출되는 간단한 코드는 함수로 만들지 않고, 직접 작성하는 것이 좋다.
코드 리뷰의 중요성
코드 리뷰는 코드의 실수를 잡아주는 과정이다.
코드가 변경될 때, 변경된 코드가 다른 곳에 영향을 미치는지 확인해야 한다.
코드 리뷰의 어려움
코드를 리뷰하려면 직접 컴퓨터에서 코드를 확인해야 하는 번거로움이 있다.
재사용 가능한 함수 작성
함수는 여러 번 호출되거나 논리적으로 여러 번 호출될 필요가 있는 경우에 작성한다.
반복되는 코드는 함수로 만들어 유지보수를 쉽게 한다.
중복 코드 제거
동일한 코드가 여러 번 등장하면 함수로 작성하여 유지보수를 단순화한다.
긴 코드의 문제
코드가 너무 길어지면 함수로 분리하여 가독성을 높인다.
단, 너무 잦은 함수 호출로 성능 저하가 발생할 수 있다는 점을 유의한다.
코드 스코프 관리
코드 블록을 중괄호로 구분하여 변수가 섞이는 것을 방지한다.
C#의 #region 등을 사용하여 코드 블록을 시각적으로 구분한다.
널(Null) 처리
함수의 매개변수에 널이 들어올 수 있으면 변수 이름에 'Nullable'을 명시한다.
반환값도 널이 들어올 수 있으면 변수 이름에 'Nullable'을 명시한다.
함수 내부에서는 널이 아닌 값을 가정하고 코딩하며, 널 체크는 바운더리에서만 수행한다.
C++의 널 레퍼런스 문제 해결
C++는 널이 될 수 없는 레퍼런스를 도입하여 이 문제를 해결했다.
다른 언어들도 이 문제를 해결하려고 노력하고 있다.
모던 프로그래밍 언어의 한계
많은 모던 프로그래밍 언어들이 널 포인터와 널 레퍼런스 문제를 완전히 해결하지 못했다.
코딩 스탠다드에 의존하여 이 문제를 해결하는 것이 필요하다.
상세 설명
불필요한 함수 작성 금지: 모든 코드를 함수로 작성하면 코드가 지나치게 복잡해지고 유지보수가 어려워집니다. 특히 간단한 작업은 함수로 만들지 않고 직접 코드를 작성하는 것이 효율적입니다. 예를 들어, 단어 하나를 읽어오는 간단한 작업을 함수로 만들지 않고 한 줄로 작성하는 것이 더 나을 수 있습니다.
함수는 약속이다: 함수는 특정 작업을 수행하는 약속입니다. 함수 이름과 매개변수를 통해 함수가 어떤 작업을 할지 명확히 알 수 있어야 합니다. 이렇게 하면 코드를 읽는 사람들이 함수가 무엇을 하는지 쉽게 이해할 수 있습니다.
함수 수정의 어려움: 함수를 수정하면 그 함수를 호출하는 모든 코드를 확인해야 하는 부담이 생깁니다. 특히, 함수가 여러 곳에서 호출된다면, 모든 호출 코드를 확인하고 수정해야 하는 어려움이 있습니다. 이는 함수가 제대로 동작하지 않을 경우, 전체 시스템에 영향을 미칠 수 있기 때문입니다.
간단한 함수는 코드로 직접 작성: 간단한 작업을 위해 함수를 만들기보다는, 그 작업을 직접 코드로 작성하는 것이 유지보수와 이해에 더 용이합니다. 예를 들어, 단 한 번만 호출되는 작업이라면 굳이 함수를 만들지 않고 코드로 직접 작성하는 것이 더 효율적입니다.
코드 리뷰의 중요성: 코드 리뷰는 코드가 올바르게 작성되었는지, 실수가 없는지 확인하는 중요한 과정입니다. 코드가 변경될 때, 그 변경이 다른 부분에 영향을 미칠 수 있으므로, 코드 리뷰를 통해 이러한 영향을 최소화해야 합니다. 또한, 코드 리뷰를 통해 코드의 질을 향상시키고, 팀원 간의 지식 공유도 가능합니다.
코드 리뷰의 어려움: 코드 리뷰를 할 때, 모든 코드를 직접 컴퓨터에서 찾아보고 확인하는 과정은 번거롭고 시간이 많이 걸릴 수 있습니다. 특히, 함수가 여러 곳에서 호출된다면 모든 호출 지점을 일일이 검토해야 하므로 더욱 어렵습니다.
재사용 가능한 함수 작성: 함수는 재사용 가능해야 하며, 여러 번 호출되거나 반복적으로 사용될 가능성이 있는 경우에 작성합니다. 이를 통해 코드의 중복을 줄이고, 유지보수를 쉽게 할 수 있습니다.
중복 코드 제거: 동일한 코드가 여러 번 등장하면 함수로 작성하여, 한 군데만 수정하면 되는 구조로 만드는 것이 좋습니다. 이는 코드의 일관성을 유지하고, 수정 시 실수를 줄이는 데 도움이 됩니다.
긴 코드의 문제: 코드가 너무 길어지면 가독성이 떨어지고, 유지보수가 어려워집니다. 이러한 경우, 코드를 적절히 함수로 분리하여 가독성을 높이는 것이 좋습니다. 다만, 너무 잦은 함수 호출로 인한 성능 저하도 고려해야 합니다.
코드 스코프 관리: 코드 블록을 중괄호로 구분하여 변수가 섞이는 문제를 방지합니다. 또한, C#의 #region 등을 사용하여 코드 블록을 시각적으로 구분하면, 코드의 가독성을 높일 수 있습니다.
널(Null) 처리: 함수의 매개변수에 널이 들어올 수 있으면 변수 이름에 'Nullable'을 명시합니다. 반환값도 마찬가지로 'Nullable'을 명시합니다. 함수 내부에서는 널이 아닌 값을 가정하고 코딩하며, 널 체크는 바운더리에서만 수행합니다. 이를 통해 코드의 가독성을 높이고 오류를 줄일 수 있습니다.
C++의 널 레퍼런스 문제 해결: C++는 널이 될 수 없는 레퍼런스를 도입하여 이 문제를 해결했습니다. 이는 널 포인터로 인한 오류를 줄이고, 코드의 안정성을 높이는 데 도움이 됩니다.
모던 프로그래밍 언어의 한계: 많은 모던 프로그래밍 언어들이 아직 널 포인터와 널 레퍼런스 문제를 완전히 해결하지 못했습니다. 이로 인해 프로그래머는 코딩 스탠다드에 의존하여 이러한 문제를 해결해야 합니다.
코딩 스탠다드의 중요성: 프로그래머가 널 포인터와 같은 문제를 효과적으로 처리하기 위해서는 코딩 스탠다드를 잘 준수해야 합니다. 이는 특히 웹 개발보다는 게임 개발이나 시스템 프로그래밍 같은 분야에서 더 중요합니다. 이러한 분야에서는 널 포인터로 인한 오류가 시스템 전체에 큰 영향을 미칠 수 있기 때문입니다.
책이 언제나올까요...ㅎㅎ
1월전엔 반드시 나온다더군요 -_-a
오늘도 이해가 안되네 ㅋㅋ
요약 : 중복이나 호출빈도 높은 코드만 함수로 작성하라
함수형에 대해 보다가 영상 보고 살짝혼란이 왔네요 말씀하시는건 메서드라고 말씀하시는게 더 맞지않나 싶네요
+hoy hoyhoy 메서드도 함수의 일부입니다. 오브젝트 소유의 함수가 메서드죠. 한 20년전쯤엔 메서드라 굳이 구분해 말하는 게 일반적이었으니 개체지향 언어가 흔해진 지금은 그냥 혼용해서 쓰는듯 합니다. 멤버함수라고도 많이 하고요.
중가로 센스 꿀팁이네요 감사합니다~