대기업에서 대규모 코드몽키 군단을 돌리기 위해 OOP를 접목한 이유와 자신의 회사에서 이런 코드몽키 군단의 습격을 막기 위해 할 수 있는 것들... 올바른 OOP가 궁금하시다면 #POCU 아카데미의 '개체지향 프로그래밍 및 설계' 과목을 강추합니다. pocu.academy/k...
영상 잘 보고 있습니다. 아직 대학에서 CS를 배우고 있는 중이라 실전 프로젝트 경험은 적어 포프님의 이야기를 온전히 공감하고 이해하기엔 부족합니다. 하지만 지금 배우고 있는 CS 지식을 제대로 익혀야겠다는 생각이 들어요. 졸업할 때 쯤에는 포프님처럼 훌륭한 프로그래머가 될 수 있도록 끊임없이 노력하겠습니다. 좋은 영상 항상 감사합니다.
자바에서 getter/setter를 쓰는 이유가 이거였군요. getter/setter를 쓰는 이유를 아무리 찾아도 이유가 아닌걸 이유라고 설명해서 찾는거 포기하고, 자바는 변수 단위가 아니라 메소드 단위로 호출하는게 규칙인가보다 했었는데 그 메소드 단위로 호출하는 이유가 이거였군요
오 이걸. 뉴 타입 패턴이라고 하는군요.. 하고 검색해보니 Rust쪽에서만 이걸 디자인 패컨으로 다루고 타 언어에서는 new type idiom이라고 하는 것 같더라구요. 그래서 좀더 생각해보니 사실 이건 주류 OOP의 근본개념인 ADT(Abstract Data Type)에 불과한 것 같습니다. 그리고 OOP의 언어 중에 주류는 아니지만 다이나믹 타입 시스템인 언어도 좀 있고 FP 언어는 오히려 주류가 다이나믹 타입 인거 같아서 요 패러다임들이 딱히 타입을 중요시 여긴다기 보다는 결국 스태틱 타이핑을 지원하는 언어냐 아니냐의 문제인 것도 같고요...
Haskell에서는 아예 keyword로써 존재하며 Rust에서 이를 벤치마킹한 것이 new type 패턴입니다. FP언어의 가장 프로덕션에서 자주쓰이는 언어가 Scala와 Haskell과 정도로 볼 수 있는데 두 언어 모두 정적/강타입 언어에 속합니다. 다만 Erlang/Elixir는 동적 타입이긴 합니다. 나머지 언어는 프로덕션에서 사실상 안 씁니다. 주류가 다이나믹이라고 하기는 무리가 있어보여요 ADT도 OOP만의 개념이라고 부르기엔 FP에서도 굉장히 중요한 개념입니다. (당장 FP에서 가장 자주 쓰이는 List 타입이 ADT이고 ADT이기에 재귀적일 수 있으니까요) 다만 여기서 ADT는 OOP와 FP가 서로 정의하는 바가 조금 다릅니다. ADT에 대한 위키피디아 문서를 보면 절차적 방식과 함수적 방식 둘 다 나눠져있죠 en.wikipedia.org/wiki/Abstract_data_type 말하신대로 결국 패러다임 문제라기보다 정적 타입이냐 더 주요 요점이긴 하죠
Oop에는 전통적으로 두가지 분파가 있습니다. ADT(abstract data type)에 근본을 둔 학파와 메시지를 통한 추상화에 근본을 둔 학파입니다. 현재의 OOP는 둘이 다 포함되어있지만 ADT쪽이 다수설입니다. OOP의 특징을 논할때 4대 원칙(pillar)은 언제나 들어갑니다(확장하면 7개 까지 들어갈 수 있습니다. ) 그 중의 하나가 추상화로.. 다수설은 이 추상화를 ADT의 추상화와 다형성의 추상화를 다 포함합니다. 극 소수설은 다형성에서 오는 추상화만 포함하고요. (따라서 OOP에서 추상화를 어떤 원칙으로 삼지 않는다는 말씀은 매우 이해하기 힘듭니다) 따라서 내부 멤버가 뭔지 알 필요없이 문맥에 맞는 타입만을 사용하는 방법은 OOP의 4대 원칙 중에 하나인 (데이터) 추상화의 일부입니다.
아. 이제서야 키키키님이 무슨 이야길 하시는지 이해했습니다. 키키니는 OOP를 통해 이루려는 '목적'을 말씀하시는 것 같습니다. 전 어떤 프로그래밍 언어 혹은 방법론이 OO라고 불리려면 갖춰야 하는 기능들이 뭐인지를 말한 거고요. 그걸 OO의 4대 '원칙'(pillar) 라고 합니다.
재미있는 주제네요. 솔직히 primitive type이면 그것 그대로 쓰는 게 직관적이라고 봅니다만 인간이라는 게 실수를 항상 안한다는 보장도 없으니 레이어를 하나 더 깔아서 강타입으로 표현하는 것도 이해는 됩니다. 딱 정해진 답은 없는 주제이긴 하네요. OOP의 배경도 잘 들었습니다!
"프로그램의 곳곳에서 백여 번에 걸쳐서 주의력을 소진하는 것보다는 당연히 단 한 번만 주의를 기울이는 편이 훨씬 행복한 경우일 것입니다." - Modern C++ Design 처음 작성할 때 올바로 작성하면 이후 수정하거나 사용할 때 불필요한 주의력을 소진할 필요가 없습니다.
마치 볼드모트같은 핵심적인 이유이군요 ㅋㅋㅋㅋㅋ최근에 이 부분에 대해 다른 개발자와 대화한적 있는데 왜 은닉을 해야하는가에 대해 "그냥 의식적으로 좋은 구조라 해서 하고 있다" 라고 하더라구요ㅋㅋㅋㅋㅋㅋㅋ점점 내려오면서 실제 이유를 "응 니가 내 코드를 망칠까봐야"라고 말은 못하고...그렇게 전승되어 내려온거죠
부족하지만 이해한 바를 정리해보면.. 1.실수할 여지를 없애기 위한 타입규정 2.그 과정에서 성능적 손해발생 3. 2가 없으면서도 1을 충족할만한 cSharp에서 활용할만한 방식 처음부터 탑 프로그래머일순 없고 그럼에도 생산성을 발휘해야하다보니 이런저런 고민을 하게되네요. 현 시점에서는 성능적 부분을 손해보는 한이 있더라도 로직이 안정적으로 작동하게 짜고 공부하면서 최적화하는 연습을 해야할지.. 좋은 영상 감사합니다.
현재 자마린으로 Android 랑 IOS에서 돌아가는 웹 어플리케이션을 제작하고 있는데. 이 비디오에서 말씀하신 구조화 클래스 만드는것에 대해서 이야기하신것에 동의가 가는 것이 제가 C#언어을 많이 해본적이 없다보니 많이 망가뜨릴 수 있는 행동을 하는 사람이라는 생각이 들기도 하고 구현하는 단계에서 메개변수 전달하면서 아 지금 이렇게 하면 좀 이상하게 작동할 우려가 좀 있을 것 같다는 생각이 드는 부분이 좀 많았어요. 오늘 비디오 보고 이 부분의 해결방법에 대해서 좀 막을 수 있는 방법을 이해할 수 있었네요 :)
CS. 시스템 프로그램 언어인 C에도 객체지향이 적용되며 사용자가 늘어난거 보면 사용하기 쉬운 언어가 흥하는거 같음. 저 때만 해도 C보단 비쥬얼 베이직이랑 닷넷 썼습니다. 개발 언어 배우기 쉬우고 쓰기 편했으니까. 게임 만들기도 쉬웠고. 자바도 프레임워크 만들어지면서 쓰는 개발자들이 늘어났고. 배우기 쉽고 쓰기 편하니. 비쥬얼 베이직이랑 닷넷으로 API개발하는 법을 배웠습니다. 컴포넌트 함수 만드는 법이랑. 데이터 입출력은 구조체 만들어서 써서 디버깅도 편해서 개발하기 정말 편했던 비쥬얼 베이직과 닷넷. 프로그램 개발이 재밌던 시절이였죠.
유니티 C#으로 게임개발 중에 있습니다. 최근 영상이 회사에서 하는 내용이랑 계속 겹쳐서 놀랍습니다.(아마도 포프님도 프레임워크 재설계작업을 하고계신게...) 저희도 최근까지 struct 타입을 설계에 포함시켜 써봤는데, 중요 field들을 자체개발한 필드컨테이너로 못쓴다는 점에서 포기하게 되었습니다. 이 영상을 보면서 최근 도전적이었던 기술들이 영 틀린방향은 아니라는 확신이 들었습니다. 올바른 방향으로 가는 지 확인할 수단이 마땅치 않았는데 정말 큰 도움이 되었습니다. 감사합니다. 영상수준이 너무 높네요.
@@포프티비 음.. 맨땅 해딩중이라 정확히 설명하기 힘드네요. 개념적 설명을 하는 점 유의해주세요. 기본적으로 Component(설계적 의미)의 재사용성을 보장하면서도 자유로운 도메인을 구현하기 위해 Field 중 일부를 자체개발한 필드컨테이너로 다루고있습니다. 이런 필드컨테이너는 타입별로 구현했습니다. XString, XInt, 이런식입니다. 이런 이유는 Event와 Field Relation(Object Relation의 Field급)을 구현하기 위해서인데 게임의 핵심 Field를 이 자체개발 필드컨테이너로 선언하면 확장성을 확보할 수 있을꺼란 개념입니다. 현재 저희 회사에선 압도적 개발용이성이라 판단하고 있으나 과연 다른 사람(신입)도 사용할 수 있을지 의문을 갖고있는 상태입니다. Struct를 안쓰게 된 것은 기술적 제한이 아니라 최적화가 잘되면 이 Field가 기획적으로 중요한지 안중요한지 미리 따지지말고 다 XField형태로 쓰자고 최근에 결론내렸기 때문입니다.
건 일해봐야 아는 거죠. 세상 모든 프로그래머는 장단점이 있다봅니다. 전 자신의 단점을 인정하고 그걸 보완해서 큰 문제만 안생기게 한다면 자신의 장점을 잘 살려서 서로 공생하는 관계가 가능하다고 봐요. 근데 단점을 어느정도까지만이라도 고치는 걸 못하는 사람들이 있어서 그 사람들과는 일을 못할 정도까지 가는 거죠
(어그로 떡밥) 이 XX 보유한 마소주식 세금조사 해야됨. (욕설 죄송합니다. 갓포프 만세~~) 재밌다. 마치 창과 방패의 힘을 겨루는 전쟁 영화처럼 전개가 되다가.. (보안 vs 편의성) 편의성과 효율성의 가치를 고민하는 철학적인 내용도 있고.. 마소 앞광고 타임도 있고.. (갓 C#) 대기업과 소기업의 시스템을 비교하며 마지막 결말은 시청자의 생각에 질문을 던지는 듯한 한편의 영화를 본 듯 하다. 무야아아호.....
안본사이에 언니가 되어있어..?
ㅋㅋㅋㅋㅋㅋㅋㅋㅋ
단발좌?
"퀄리티 안나오는 사람들의 특징" 이 비디오랑 같은걸 말하네요.
실수가 나왔을 때 이를 재발하지 않도록 하는 노력을 하냐 안하냐.
영상 잘 보고 있습니다. 아직 대학에서 CS를 배우고 있는 중이라 실전 프로젝트 경험은 적어 포프님의 이야기를 온전히 공감하고 이해하기엔 부족합니다. 하지만 지금 배우고 있는 CS 지식을 제대로 익혀야겠다는 생각이 들어요. 졸업할 때 쯤에는 포프님처럼 훌륭한 프로그래머가 될 수 있도록 끊임없이 노력하겠습니다. 좋은 영상 항상 감사합니다.
확실히 협업을 많이 해봐야 이해되는 이야기들이죠. 더 나아지겠다는 목표와 꾸준한 호기심만 있다면 계속 발전하겠죠 :)
자바에서 getter/setter를 쓰는 이유가 이거였군요. getter/setter를 쓰는 이유를 아무리 찾아도 이유가 아닌걸 이유라고 설명해서 찾는거 포기하고, 자바는 변수 단위가 아니라 메소드 단위로 호출하는게 규칙인가보다 했었는데 그 메소드 단위로 호출하는 이유가 이거였군요
예고를 하셔서 그렇다 햇는데.. 좀 쎄긴하네요 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
좋은영상 감사합니다
포프언니는 언제 봐도 좋아..
엄훠
이래서 약타입언어들 실무에서 안쓰는게 좋다고 하셨군요 ㄷ
id 래핑하는 클래스에 대한 예시는 사실 newtype 패턴이죠.
newtype이라는 이름은 하스켈에서 처음 제시되었으며, OOP에 한정된 패턴이 아닙니다.
OOP랑 FP 둘 다 타입 중요하게 여기는 건 비슷하긴 한 것 같네요
오 이걸. 뉴 타입 패턴이라고 하는군요.. 하고 검색해보니 Rust쪽에서만 이걸 디자인 패컨으로 다루고 타 언어에서는 new type idiom이라고 하는 것 같더라구요.
그래서 좀더 생각해보니 사실 이건 주류 OOP의 근본개념인 ADT(Abstract Data Type)에 불과한 것 같습니다.
그리고 OOP의 언어 중에 주류는 아니지만 다이나믹 타입 시스템인 언어도 좀 있고 FP 언어는 오히려 주류가 다이나믹 타입 인거 같아서 요 패러다임들이 딱히 타입을 중요시 여긴다기 보다는 결국 스태틱 타이핑을 지원하는 언어냐 아니냐의 문제인 것도 같고요...
Haskell에서는 아예 keyword로써 존재하며 Rust에서 이를 벤치마킹한 것이 new type 패턴입니다.
FP언어의 가장 프로덕션에서 자주쓰이는 언어가 Scala와 Haskell과 정도로 볼 수 있는데 두 언어 모두 정적/강타입 언어에 속합니다.
다만 Erlang/Elixir는 동적 타입이긴 합니다. 나머지 언어는 프로덕션에서 사실상 안 씁니다. 주류가 다이나믹이라고 하기는 무리가 있어보여요
ADT도 OOP만의 개념이라고 부르기엔 FP에서도 굉장히 중요한 개념입니다. (당장 FP에서 가장 자주 쓰이는 List 타입이 ADT이고 ADT이기에 재귀적일 수 있으니까요)
다만 여기서 ADT는 OOP와 FP가 서로 정의하는 바가 조금 다릅니다.
ADT에 대한 위키피디아 문서를 보면 절차적 방식과 함수적 방식 둘 다 나눠져있죠 en.wikipedia.org/wiki/Abstract_data_type
말하신대로 결국 패러다임 문제라기보다 정적 타입이냐 더 주요 요점이긴 하죠
진주 귀고리를 한 포프님...?
뿌잉?
역시 C샵이다 가즈아
가즈아~
기승전 type safety네요. oop얘기는 아닌듯?
Oop 이야기입니다. Oop의 4대원칙중 하나인 (데이터) 추상화 이야기거든요.
Oop에는 전통적으로 두가지 분파가 있습니다. ADT(abstract data type)에 근본을 둔 학파와 메시지를 통한 추상화에 근본을 둔 학파입니다. 현재의 OOP는 둘이 다 포함되어있지만 ADT쪽이 다수설입니다.
OOP의 특징을 논할때 4대 원칙(pillar)은 언제나 들어갑니다(확장하면 7개 까지 들어갈 수 있습니다. ) 그 중의 하나가 추상화로.. 다수설은 이 추상화를 ADT의 추상화와 다형성의 추상화를 다 포함합니다. 극 소수설은 다형성에서 오는 추상화만 포함하고요. (따라서 OOP에서 추상화를 어떤 원칙으로 삼지 않는다는 말씀은 매우 이해하기 힘듭니다)
따라서 내부 멤버가 뭔지 알 필요없이 문맥에 맞는 타입만을 사용하는 방법은 OOP의 4대 원칙 중에 하나인 (데이터) 추상화의 일부입니다.
참고로 솔리드 원칙은 모두가 동의하는 OOP의 원칙이 아니라... (대다수가 동의하는 원칙은 OOP의 4대 pillars임) 소수학파에서 주장한 내용으로 실제로는 '솔리드 정신'이라 불리는 게 맞다고 생각합니다.
아. 이제서야 키키키님이 무슨 이야길 하시는지 이해했습니다. 키키니는 OOP를 통해 이루려는 '목적'을 말씀하시는 것 같습니다.
전 어떤 프로그래밍 언어 혹은 방법론이 OO라고 불리려면 갖춰야 하는 기능들이 뭐인지를 말한 거고요. 그걸 OO의 4대 '원칙'(pillar) 라고 합니다.
아 밸류타입 마렵다
'사용자의 입장을 고려하며'라는 말은 도덕책같은 말이라 지나치기 쉬운데
'망칠 기회를 주지않는다'라는 말은 보다 깊게 와닿네요
재미있는 주제네요. 솔직히 primitive type이면 그것 그대로 쓰는 게 직관적이라고 봅니다만 인간이라는 게 실수를 항상 안한다는 보장도 없으니 레이어를 하나 더 깔아서 강타입으로 표현하는 것도 이해는 됩니다. 딱 정해진 답은 없는 주제이긴 하네요. OOP의 배경도 잘 들었습니다!
이번 영상은 많은걸 깨닫게 되는 영상이었습니다
아직 학생의 입장이라서 객체지향이 뭔지만 알고
왜 사용할까 했는데 이런 숨겨진 기능이 있었네요..
코드 원숭이 군단에 소속되지 않도록 공부 열심히 해야겠습니다
항상 좋은 영상 감사합니다
"프로그램의 곳곳에서 백여 번에 걸쳐서 주의력을 소진하는 것보다는 당연히 단 한 번만 주의를 기울이는 편이 훨씬 행복한 경우일 것입니다." - Modern C++ Design
처음 작성할 때 올바로 작성하면 이후 수정하거나 사용할 때 불필요한 주의력을 소진할 필요가 없습니다.
끝까지 들으니 씨샵 영업이였네요 ㅋㅋ 많은부분 공감합니다.
마치 볼드모트같은 핵심적인 이유이군요 ㅋㅋㅋㅋㅋ최근에 이 부분에 대해 다른 개발자와 대화한적 있는데 왜 은닉을 해야하는가에 대해 "그냥 의식적으로 좋은 구조라 해서 하고 있다" 라고 하더라구요ㅋㅋㅋㅋㅋㅋㅋ점점 내려오면서 실제 이유를 "응 니가 내 코드를 망칠까봐야"라고 말은 못하고...그렇게 전승되어 내려온거죠
크 볼드모트
예전엔 '난 코드몽키가 절대 안 되겠지 후후..' 라고 생각했는데, 진짜 의식적인 빡센 노력이 없으면 나도 자연스레 코드몽키가 될 것 같다는 생각이 점점 드네요... 탑 프로그래머의 길은 멀고도 험하다..
시작은 누구나 코드몽키입니다. 거기서 벗어나려고 하려는 의지가 있느냐의 문제일뿐
생각해보니 옜날에 교수님이 oop는 건들여선 안될사람이 못건들이게 하는게 어쩌구 했던거 같은데 그게 옆에있는 개발자도 포함이였군요
옆에 있는 개발자가 세계 최악의 개발자일수도 있으니까요...
부족하지만 이해한 바를 정리해보면..
1.실수할 여지를 없애기 위한 타입규정
2.그 과정에서 성능적 손해발생
3. 2가 없으면서도 1을 충족할만한 cSharp에서 활용할만한 방식
처음부터 탑 프로그래머일순 없고 그럼에도 생산성을 발휘해야하다보니 이런저런 고민을 하게되네요.
현 시점에서는 성능적 부분을 손해보는 한이 있더라도 로직이 안정적으로 작동하게 짜고 공부하면서 최적화하는 연습을 해야할지..
좋은 영상 감사합니다.
C#, struct, ref, 다 오늘 어제, 저번 주에 사용했던 내용이군요. ㅎㅎ.. 그러나 만약 코드를 볼 줄 아는 사람이 조그마한 회사에 주니어인 저 혼자라면 어떻게 해야 하나요? 그것이 궁금합니다.
독고다이. 천상천하 유아독존..!!!
이 아니라 약간 성장하기에는 아쉬운 환경이죠 ㅜ.ㅡ
현재 자마린으로 Android 랑 IOS에서 돌아가는 웹 어플리케이션을 제작하고 있는데. 이 비디오에서 말씀하신 구조화 클래스 만드는것에 대해서 이야기하신것에 동의가 가는 것이 제가 C#언어을 많이 해본적이 없다보니 많이 망가뜨릴 수 있는 행동을 하는 사람이라는 생각이 들기도 하고 구현하는 단계에서 메개변수 전달하면서 아 지금 이렇게 하면 좀 이상하게 작동할 우려가 좀 있을 것 같다는 생각이 드는 부분이 좀 많았어요.
오늘 비디오 보고 이 부분의 해결방법에 대해서 좀 막을 수 있는 방법을 이해할 수 있었네요 :)
잘하는 개발자 수는 한정적이고 (키우기에도 비용이 어마어마)
소프트웨어 시장은 비대해지다보니
관리 측면 + 진입장벽을 낮추기 위해 + 인간처럼 생각하기 위해(?)
CS. 시스템 프로그램 언어인 C에도 객체지향이 적용되며 사용자가 늘어난거 보면 사용하기 쉬운 언어가 흥하는거 같음. 저 때만 해도 C보단 비쥬얼 베이직이랑 닷넷 썼습니다. 개발 언어 배우기 쉬우고 쓰기 편했으니까. 게임 만들기도 쉬웠고. 자바도 프레임워크 만들어지면서 쓰는 개발자들이 늘어났고. 배우기 쉽고 쓰기 편하니. 비쥬얼 베이직이랑 닷넷으로 API개발하는 법을 배웠습니다. 컴포넌트 함수 만드는 법이랑. 데이터 입출력은 구조체 만들어서 써서 디버깅도 편해서 개발하기 정말 편했던 비쥬얼 베이직과 닷넷. 프로그램 개발이 재밌던 시절이였죠.
내용 참 좋네요 주변 지인들에게 추천해주었습니다.
아직 많이 부족해서 C# 구조체 관련 활용 의의는 차마 생각 못했던 접근이네요
공부를 더 해야함을 느끼고 갑니다.
문제가 생겨야 고칠 생각을 하면서 이것저것 고민하는 거죠. 뭐 공부가 대단한 건가요...
공유 감사감사합니다. 🙏
항상 배운건 잊지 않으려고 노력합니다 그러다보면 늘겠죠
포프님 최근 사이퍼펑크 버그사태에 대해서 해주실 말씀은 없나요? 궁금합니다 ㅋㅋㅋㅋㅋ
뭔지도 모릅니다 호호호호호호
@@포프티비 으아 안돼 ㅠㅠㅠㅠㅠ 답변감사합니다!
@@Syj-krm 일부 비디오카드에서 렌더링이 좀 이상하게 깨져 나오고 느린거 말씀이죠?
@@imays76 그것만 있는게 아니고 그냥 별에별 해괴한 버그가 잔뜩 뿜어져나오는 게임
사이버펑크 개발진이 OOP를 안 도입했다면 버그가 더 많았을걸요? 그나마 OOP라도 도입해서 버그가 덜 산더미가 된걸지도요? 추측이에요.
경계를 작성하는게 무조건 좋을 줄 알았는데 이런 방식으로 발전했을 줄은 몰랐네요. 스스로를 돌아보게 되는 영상이였습니다. 감사합니다.
대기업에서 서둘러 접목 > 사용자가 많아짐 > 시장이 커짐 > 발전...
이라 표현한거지. .기술적인 발전 배경을 설명한 건 아닙니다.
(시장의 원리 .. 크흠 -_-)
@@포프티비 핵심은 코드몽키들에 의해 발생될 똥의 규모를 최대한 줄이기 위한 것으로..
Swift 언어는 함수가 인자를 받을 때 라벨을 붙일 수 있어서 좋네요. 언어 자체가 말씀 하신 사고를 피할 수 있게 해줍니당...
swift 좋네요
대규모 코드몽키 군단 ㅋㅋㅋㅋ
모든 개발자는 실력과 금액이 모두 다르기에 최소한의 안정장치죠.... 안정장치를 어느정도로 세울까 하는게 코어개발자가 늘 하는 고민중 하나..
다른 이야기지만 편집 하신거 오디오만 놓고 봤을 때 이야기가 끊기지 않아서 좋긴 하지만 영상까지 놓고 봤을 때 너무 타이트하게 끊고 붙이셔서 약간 어지러움을 느끼네요, 말 늘어짐이 너무 심하지 않은 거는 편집없이 가셔도 좋을 것 같습니다
명심하겠습니다 ㅠㅅㅠ
@@GongDolHoon 감사합니다
입사 5일차 쥬니어 입니다 ㅠ 에티튜드 잘 배워 갑니다 포프님
포프 언니 새해 복 많이 받으세요
넹
언매니지드 언어를 배워야하는 이유
유니티 C#으로 게임개발 중에 있습니다. 최근 영상이 회사에서 하는 내용이랑 계속 겹쳐서 놀랍습니다.(아마도 포프님도 프레임워크 재설계작업을 하고계신게...) 저희도 최근까지 struct 타입을 설계에 포함시켜 써봤는데, 중요 field들을 자체개발한 필드컨테이너로 못쓴다는 점에서 포기하게 되었습니다. 이 영상을 보면서 최근 도전적이었던 기술들이 영 틀린방향은 아니라는 확신이 들었습니다. 올바른 방향으로 가는 지 확인할 수단이 마땅치 않았는데 정말 큰 도움이 되었습니다. 감사합니다. 영상수준이 너무 높네요.
필드컨테이너 이야기좀 좀더 자세히 해주실래요? 저도 조심해야할 게 아닌가 걱정돼서.. 아니면 그냥 유니티 에디터에만 적용되는 이야긴가요? (아닐 거 같은데...)
@@포프티비 음.. 맨땅 해딩중이라 정확히 설명하기 힘드네요. 개념적 설명을 하는 점 유의해주세요. 기본적으로 Component(설계적 의미)의 재사용성을 보장하면서도 자유로운 도메인을 구현하기 위해 Field 중 일부를 자체개발한 필드컨테이너로 다루고있습니다. 이런 필드컨테이너는 타입별로 구현했습니다. XString, XInt, 이런식입니다. 이런 이유는 Event와 Field Relation(Object Relation의 Field급)을 구현하기 위해서인데 게임의 핵심 Field를 이 자체개발 필드컨테이너로 선언하면 확장성을 확보할 수 있을꺼란 개념입니다. 현재 저희 회사에선 압도적 개발용이성이라 판단하고 있으나 과연 다른 사람(신입)도 사용할 수 있을지 의문을 갖고있는 상태입니다. Struct를 안쓰게 된 것은 기술적 제한이 아니라 최적화가 잘되면 이 Field가 기획적으로 중요한지 안중요한지 미리 따지지말고 다 XField형태로 쓰자고 최근에 결론내렸기 때문입니다.
@@포프티비 목표하는 바가 기술적 향상이 아니라 기획적 대응이라 포프님이 걱정하시는 방향은 아니라고 추측하고 있습니다.
흥미로운 주제라 시간가는 줄 모르고 들었습니다ㅎㅎ
우가우가! OOP! OOP! 우가우가!
와 자바는 어떻게어떻게 해서 따라갔는데 그게결국 코드몽키를 위해서 나온부분도잇어서 상대적으로 메모리보는c에비해 그런부분은 단순한거군요..
C는 메모리 힙관련 부분 들어갈때부터 도저히 뭔소린지 모르겠더군요.
메모리 할당은 운영체제와 컴구조를 공부하면 좀더 이해가 쉽죠
들으면서 참…..공감되는 부분이 많네요
영상에 나온 시나리오에 고려해 볼 수 있는 record라는 유용한 기능이 추가됐네요
실수한 직원분도 이 영상 볼텐데 괜찮은가요~~
이미 직원에게도 다 한 이야기라 큰 문제가 될 거 같진 않습니다. 뒷다마를 깔때가 문제겠죠 :)
오랜만에 눈에 띄는 제목이 들어와서 무심코 클릭했는데... 무릎을 탁 치고 갑니다....ㄷㄷㄷ
oop듣고있는데 일단은 내용을 이해할수있게되어서 기쁘네요..
주니어와 시니어의 협업 방법 : 경계를 정해서 경계의 안쪽과 경계를 시니어가 담당
readonly sturct가 있는데, 최근에 나온 data struct, data class는 어디다 써야하나요?
저도 고민중.... 사실 Readonly struct와 같은데 참조형이고 싶을때 정도가 아닐까 생각해요.
함수형 프로그래밍에서 보장하는 Immutable type이 되는 장점도 있죠.
멀티 스레딩 앱에 최고
배우고갑니다
와...진짜 C를 메인으로 사용하는데 굳이? 코드를 보면 알 수 있지않나 굳이 왜이러지 라는 생각을 많이 했었는데 그런 이유였군요ㅋㅋㅋ
'세상 프로그래머가 다 나같은 건 아니다'라는 말을 계속 되내겨야 하죠. 사람은 자꾸만 자신의 기준으로 다른 사람을 생각하니까요 ㅜ.ㅡ
우끼끼 ㅠㅠ
왜케 감미롭게 끝내세요
설레게시리
와 ㅁㅊ 개재밌네 ㄹㅇ ㄷㄷ
포프님은 OOP를 사용하 이유가 재밌는다고 하시는데.... 사실은 끔찍하게 들리네요.
재밌잖아요. 프로그래밍에 국한된 게 아니라 리소스(인력) 관리 영역과 섞여버리는게.. ^^
(전 긍정적입니다!)
C#이 되게 좋네요
좋죠
핑크머리 티셔츠 굿즈 사고싶습니다
준비하겠습니다.
준비해 왔습니다.
marpple.shop/kr/popetv/products/7032449
@@포프티비 대박 졸귀
궁금합니다. 제가 포프님이랑 같이 일하면 어떤 평가를 받는 프로그래머일지...
건 일해봐야 아는 거죠. 세상 모든 프로그래머는 장단점이 있다봅니다. 전 자신의 단점을 인정하고 그걸 보완해서 큰 문제만 안생기게 한다면 자신의 장점을 잘 살려서 서로 공생하는 관계가 가능하다고 봐요.
근데 단점을 어느정도까지만이라도 고치는 걸 못하는 사람들이 있어서 그 사람들과는 일을 못할 정도까지 가는 거죠
혹시 코로나로 인해 그 방에 갇혀 계시는 거라면 당근을 흔들어 주세요
🥕
🐒.....
포프님 클하는 안하시나요??
제가 안드로이드 유저라죠...
ㅠㅜ 언젠가 포프님의 클하 세미나 기대하고 있겠습니다 ㅎㅎㅎ
그냥 채팅하고 놀겠죠 무슨 세미나는...
혼자 속으로 갖고 있던 의문인데 포프님이 확인해 주시니 속이 시원하네요
저에게 선물이라도...
포프님 외국 ea 나 캡콤 같은데 가려면 그나라 대학 졸업이 필수인가요?
아뇨
@@포프티비 그냥 코딩 잘 하면 뽑아주나요?
Lisp 에 대해서 영상 만들어 주세요
안한지 오래되고 깊이 안했어서...
포프 언니 새해 복 많이 받으세요
포큐.. 대학생이 보기에는 비싼감이... 없지않아 있는것같아요...
그런 면도 있죠. 하지만 저렴한 가격에 맞춰 강의 퀄리티를 낮출 순 없어서요.
대규모 코드몽키들이 떼지어 유튜버로 흘러들어 너도나도 개발자 코스프레중인 작금의 현실
몽키놈들 여기오면 먼소린지 1/10 이나 알아처먹으려나 모르겠네요 ㅋㅋㅋㅋㅋ
오랜만에 들러서 개꿀잼토킹에 탁!치고 갑니다 ㅎㅎ
개발자 코스프레라뇨... 다들 개발자입니다. 자 우린 열린 마음으로.. (응?)
즐겁게 보셨다니 다행입니다 :)
👍👍
누가 밥 줄 끊기는 소리를 내었는가....
소프트웨어 위기론 등등 이유로 진입장벽 날이 갈 수록 낮춘게 이 결과죠. 결국 트레이드오프 ㅠ
인과응보...
진짜개발자들은 다 여기 있었군요 ㅎㅎ 진입장벽 너무 낮아진게 슬픕니다.
포큐아카데미에서 코드리뷰나 포폴리뷰같은거 해주는건 없나요?
포폴리뷰 없습니다. 코드리뷰는 학생끼리 자발적으로 합니다
좋은 설명 감사합니다.
항상 주옥같은 말만 하십니다 ㅎㅎ
명언제조기가 되보고 싶긴 한데... 잘 안되네요..
(어그로 떡밥)
이 XX 보유한 마소주식 세금조사 해야됨. (욕설 죄송합니다. 갓포프 만세~~)
재밌다.
마치 창과 방패의 힘을 겨루는 전쟁 영화처럼 전개가 되다가.. (보안 vs 편의성)
편의성과 효율성의 가치를 고민하는 철학적인 내용도 있고..
마소 앞광고 타임도 있고.. (갓 C#)
대기업과 소기업의 시스템을 비교하며 마지막 결말은 시청자의 생각에 질문을 던지는 듯한 한편의 영화를 본 듯 하다.
무야아아호.....
2010년에 다 팔았습니다...ㅡ
@@포프티비 죄송합니다.. POCU IPO 언제 하시나요?? 기다리고 있습니다..
님아 이미 있는데요..
오 유어 갓!! 받을걸..