자바에서 메서드나 클래스의 네이밍도 문서화, 주석작업의 일환으로 보는 분들도 계시더라고요. 확실히 길어서 갑갑하기는 한데. 그래도 시간이 지나서보면 해당 클래스나 메서드의 성격은 명확히 파악이 되는 것 같애요. 재사용성이라는 객체지향언어의 장점을 다시한번 생각하게 되는 것 같애요. 영상 감사합니다.
이 영상이 올라왔을 때, 신입사원이었던 때라 잘 이해하지 못했던 내용이 많았는데 관련 업무를 수행하다 우연히 다시 영상을 보게 되었습니다. 대략 4년이 흘러 이제서야 많은 공감을 할 수가 있게 된 것 같습니다. 이런 영상이 많을 것 같다 느껴서 틈틈이 옛날 영상을 되새김질하자 마음먹었습니다. 영상 감사합니다.
1. 펌웨어 분야가 딱 말씀하신 특수 분야 같네요. 약자 많이 쓰고, 성능 때문에 이상한 코드 나오는 경우 많고, 어셈 섞여있고... 그래서 safety 같은 곳은 변수명, 함수명의 본래 풀명칭을 문서화 시키고 그게 뭐하는 건지 한번 더 쓰게 만들죠;;; 2. 프로세스 문서의 경우 제조업에서 그 문서의 수정권한은 보통 QA가 가지고 있기 때문에 1년에 한번에 몰아서 수정하더라고요. 저희회사도 레거시 시스템들은 계속 개선되고 있는데, 프로세스 문서는 항상 2~3개월씩 늦게 나오더라고요. 3. 언어 능력.. 공감합니다. 그래서 제가 프로그래밍 못하는 듯... ㅠㅠ
실리콘밸리에 있다가 휴스턴에서 시니어 엔지니어로 일하고 있는중입다. 요새 전임자가 문서도 없이 어렵게 짜놓은 코드 보느라 아주 괴로워하고 있는데 조금은 위로가 되네요. 그 전임자도 자존심은 강하지만 남을 이해시키는 커뮤니케이션 능력을 떨어졌었는데 코드에도 그런 성격들이 그대로 반영되는 것 같습니다.
1. 코드는 문서화를 최대한 하지 않는게 좋다. -> 차후 코드수정에 의해 문서와의 디싱크가 우려되기에. +코드자체가 직관적 정보로써 받아들일 수 있게 작성할것 2. 프로세스는 문서화가 되어있는게 좋으며 개개인이 필요에따라 업데이트를 하도록 권고 3. API나 라이브러리 같은 묶음은 어느정도 문서화가 되어있어야 외부에서 쓰기 용이하다.?
학원에서 배우는 도중에 강사 선생님께서 처음 배울 때는 주석으로 설명이나 문법을 자주 다는게 차후에 도움이 많이 될거라는 얘기를 해주셨는데 왜 그런지 뭔가 이해가 확 되네요 다만 코드할 때는 주의해야할 것 같다는 생각도 같이 드네요 ㅎㅎ 처음엔 내용이같았을지라도 코드는 업데이트하면서 주석은 업데이트하지 않는다면 혼란이 엄청 오겠군요!
아... 오랜만에 채널 들어왔습니다. 이전에는 영상을 보면서 포프님이 하소연하는 것 처럼만 들렸습니다만, 이번에는 영상을 접하면서 공감이 많이 되네요. 그리고 말투가 차분해 지신 것 같아요! ㅎㅎ 이번영상을 보니, 문뜩 신입때 들은 말도 떠오릅니다. 제가 선임 개발자에게 "주석이 중요한거라고 들었다" 라고 말을 하니, "코드 보면 아는데 뭐하러 주석 넣냐. 코드 못 짜는 사람들이 주석 다는 것이다" 라고 말을 했지요. 저는 주석도 문서처럼 개발자가 싫어하지만 작품(결과물, 코드)을 만드는데 중요한 것 중 하나라고 생각하거든요. 내가 만든 코드의 최대 유저는 이걸 사용하는 동료 개발자이기 때문이지요. 리뷰도 해주고 피드백도 주는데, 설명서가 필요하지 않겠어요? 하하하... 아무튼! 꾸준히 영상 올려주셔서 감사합니다. ^^
마지막에 정리하실 때, “코드를 잘 짜면 문서화도 잘 한다.”라는 말씀에 굉장히 공감되면서, 동시에 뭔가 위로 받은 기분입니다.ㅎㅎ 저는 주석을 웬만해서는 달아두지 않는 편인데, 그래도 변수명과 구조 정도만으로도 무슨 작업을 어떻게 하기 위한 스크립트인지 알 수 있도록 작성하려고 애쓰는 편이라고는 말할 수 있습니다. 하지만 이제는 더 이상 일정 수준 이상의 정리작업이 없으면 발전이 없을 것만 같은 위기감이 들기 시작해서, 그간 작성해둔 스크립트들의 기능과 구조를 검토해서 정리해두려는 계획을 세워둔 차에 제목이 눈에 확 들어왔고 아주 재미있게 잘 들었습니다. 고맙습니다!
학생때 잠깐 스타트업에 인턴으로 참여했었는데.. 대표님이 문서화를 참 좋아하던 곳이었어요. 필요해서 문서화를 하는 것인지 그냥하는 것인지 모를정도로요ㅋㅋ 이전 메뉴얼의 수 자체는 무척이나 많은데 추가 수정도 전혀없고 틀린 정보도 많았죠. 결국 이런 점을 보고하면 최대한 수정하라는 추가 업무가 떨어지고.. 어릴때라 유연하게 대처 못하고 본업무와 본업무 문서화와 이전 메뉴얼 수정.. 전부 해보려고 갈팡질팡하며... 힘들어하던 기억이 생각나네요ㅜㅋㅋ 이 영상을 그때 봤다면 좀 더 유연하게 행동할 수 있었을 것 같네요... 피드백자체는 잘되는 편이었거든요ㅜㅜ 암튼 저에게 먼가 깨달음을 주는 영상이었네요
문서화를 시키기위한 잔소리 스킬을 익히러왔습니다 포프님 4:40
아 잔소리맨이 되다니. 🤭
@@포프티비😄😄 오늘도 좋은하루 보내셔요 포프님
1. 코드 자체의 문서화
2. 프로세스 문서화 3:25
3. 라이브러리, API 문서화 6:45
자바에서 메서드나 클래스의 네이밍도 문서화, 주석작업의 일환으로 보는 분들도 계시더라고요. 확실히 길어서 갑갑하기는 한데. 그래도 시간이 지나서보면 해당 클래스나 메서드의 성격은 명확히 파악이 되는 것 같애요. 재사용성이라는 객체지향언어의 장점을 다시한번 생각하게 되는 것 같애요. 영상 감사합니다.
이 영상이 올라왔을 때, 신입사원이었던 때라 잘 이해하지 못했던 내용이 많았는데 관련 업무를 수행하다 우연히 다시 영상을 보게 되었습니다. 대략 4년이 흘러 이제서야 많은 공감을 할 수가 있게 된 것 같습니다. 이런 영상이 많을 것 같다 느껴서 틈틈이 옛날 영상을 되새김질하자 마음먹었습니다. 영상 감사합니다.
전 아직 신입사원조차 아닌데 4년전 영상을 보고있네요..
물론 20년 전 임베디드 책을 보면서 공부하는 중인지라 전혀 낡았다는 생각은 들지 않고요 ㅋㅋ
1. 펌웨어 분야가 딱 말씀하신 특수 분야 같네요. 약자 많이 쓰고, 성능 때문에 이상한 코드 나오는 경우 많고, 어셈 섞여있고... 그래서 safety 같은 곳은 변수명, 함수명의 본래 풀명칭을 문서화 시키고 그게 뭐하는 건지 한번 더 쓰게 만들죠;;;
2. 프로세스 문서의 경우 제조업에서 그 문서의 수정권한은 보통 QA가 가지고 있기 때문에 1년에 한번에 몰아서 수정하더라고요. 저희회사도 레거시 시스템들은 계속 개선되고 있는데, 프로세스 문서는 항상 2~3개월씩 늦게 나오더라고요.
3. 언어 능력.. 공감합니다. 그래서 제가 프로그래밍 못하는 듯... ㅠㅠ
크 코드 자체가 문서가 되어야 된다는 말에 박수치고 갑니다ㅠㅠ
실리콘밸리에 있다가 휴스턴에서 시니어 엔지니어로 일하고 있는중입다. 요새 전임자가 문서도 없이 어렵게 짜놓은 코드 보느라 아주 괴로워하고 있는데 조금은 위로가 되네요. 그 전임자도 자존심은 강하지만 남을 이해시키는 커뮤니케이션 능력을 떨어졌었는데 코드에도 그런 성격들이 그대로 반영되는 것 같습니다.
프로그램 하면서
수학이 중요할 것 같지만
실무에서는 국어가 제일 중요했다.
수학도 엄밀하게 보면, 언어죠.
ㅋㅋ
수학은 자연과의 소통
수학은 보편적 언어고 국어는 구체적 소통어죠ㅎㅎ 본인이 수학적 발견을 하면 250년 뒤에도 같은 발견이 가능하겠죠.. 그렇지만 눈앞에 사람과는 국어로 소통이 가능하죠
영상에서도 나오지만 순수 언어 능력이 딸려서 그럴 수도 있지만 습관이나 습성적이나 배려심 같은 문제인 경우도 있죠
다른곳에서 듣기힘든 좋은 내용이네요 특히 프로세스문서화 관련하여 틀린부분 발견한 사람이 바로 고쳐놓을 수 있어야 한다는 부분에 핵공감합니다^^
이거 진짜 공감합니다
1. 코드는 문서화를 최대한 하지 않는게 좋다. -> 차후 코드수정에 의해 문서와의 디싱크가 우려되기에.
+코드자체가 직관적 정보로써 받아들일 수 있게 작성할것
2. 프로세스는 문서화가 되어있는게 좋으며 개개인이 필요에따라 업데이트를 하도록 권고
3. API나 라이브러리 같은 묶음은 어느정도 문서화가 되어있어야 외부에서 쓰기 용이하다.?
학원에서 배우는 도중에 강사 선생님께서 처음 배울 때는 주석으로 설명이나 문법을 자주 다는게 차후에 도움이 많이 될거라는 얘기를 해주셨는데 왜 그런지 뭔가 이해가 확 되네요
다만 코드할 때는 주의해야할 것 같다는 생각도 같이 드네요 ㅎㅎ
처음엔 내용이같았을지라도 코드는 업데이트하면서 주석은 업데이트하지 않는다면
혼란이 엄청 오겠군요!
국어는 기본인거 같습니다!
소통을 해야 하므로....
정말 실력있는 프로그래머 2분이 블로그 운영할 거라고 얘기하고 소식이 없더니...
결국 글재주가 없어서 내용을 못 적겠다고 하더군요! 기대가 컸다가 좀 실망이 되었던 추억이 생각나네요!
음 아마 그분은 정말 실력있는 프로그래머가 아닐거 같은데요. 글재주 없는 정말 실력있는 프로그래머를 아직 못봄
sk에서 프로젝트 할 당시 '프로그램 개발'이 아닌 '프로그램 작성'이라고 표현하더군요.
포프언니, 월요일 출근시간 조금은 잡생각 없이 출근하게 해주셔서 감사해요!
맞아요. 개인적으로는 주석이 최소한이어도 되는 코드가 최고고, 그 다음으로는 문서가 없어도 되는 코드가 좋으며, 마지막이 문서가 잘 되어 있는 코드 같습니다. 항상 신경 쓰면서 짜긴 하는데, 그래도 어렵네요.
프로그램은 흐름입니다
흐름만 알면 코드는 방법론라서요
많이 고민을 한 부분인데요. 내가 너의 이름을 불러줄때..너는 나에게 와서 꽃이 되었다. 의미 있게 만들려면 작명을 잘해야 하는데요. 힘들죠.. 이런 작명 기술을 좀 더 구체적이고 체계화 하는 것을 알고 싶네요. 작명만 잘해도 문서화를 줄일 수 있다고 생각합니다.
격하게 공감합니다. 제가 요즘 후배들한테 가장 많이 하는 말이 국어공부좀 하자는 겁니다.
문서화는 항상 필요하다고 머리는 인지하고 있지만, 안하고 있는데 반성하고 갑니다. 항상 좋은 영상 감사드립니다
아... 오랜만에 채널 들어왔습니다.
이전에는 영상을 보면서 포프님이 하소연하는 것 처럼만 들렸습니다만, 이번에는 영상을 접하면서 공감이 많이 되네요. 그리고 말투가 차분해 지신 것 같아요! ㅎㅎ
이번영상을 보니, 문뜩 신입때 들은 말도 떠오릅니다. 제가 선임 개발자에게 "주석이 중요한거라고 들었다" 라고 말을 하니, "코드 보면 아는데 뭐하러 주석 넣냐. 코드 못 짜는 사람들이 주석 다는 것이다" 라고 말을 했지요.
저는 주석도 문서처럼 개발자가 싫어하지만 작품(결과물, 코드)을 만드는데 중요한 것 중 하나라고 생각하거든요. 내가 만든 코드의 최대 유저는 이걸 사용하는 동료 개발자이기 때문이지요. 리뷰도 해주고 피드백도 주는데, 설명서가 필요하지 않겠어요? 하하하...
아무튼! 꾸준히 영상 올려주셔서 감사합니다. ^^
그 설명서랑 코드가 자꾸 달라지는 경우가 있어 혼란을 초래...
마지막에 정리하실 때, “코드를 잘 짜면 문서화도 잘 한다.”라는 말씀에 굉장히 공감되면서, 동시에 뭔가 위로 받은 기분입니다.ㅎㅎ
저는 주석을 웬만해서는 달아두지 않는 편인데, 그래도 변수명과 구조 정도만으로도 무슨 작업을 어떻게 하기 위한 스크립트인지 알 수 있도록 작성하려고 애쓰는 편이라고는 말할 수 있습니다.
하지만 이제는 더 이상 일정 수준 이상의 정리작업이 없으면 발전이 없을 것만 같은 위기감이 들기 시작해서, 그간 작성해둔 스크립트들의 기능과 구조를 검토해서 정리해두려는 계획을 세워둔 차에 제목이 눈에 확 들어왔고 아주 재미있게 잘 들었습니다. 고맙습니다!
주석보단 코드가독성으로 알아볼수 있게 짜는게 베스트죠👍👍
학생때 잠깐 스타트업에 인턴으로 참여했었는데.. 대표님이 문서화를 참 좋아하던 곳이었어요. 필요해서 문서화를 하는 것인지 그냥하는 것인지 모를정도로요ㅋㅋ 이전 메뉴얼의 수 자체는 무척이나 많은데 추가 수정도 전혀없고 틀린 정보도 많았죠. 결국 이런 점을 보고하면 최대한 수정하라는 추가 업무가 떨어지고.. 어릴때라 유연하게 대처 못하고 본업무와 본업무 문서화와 이전 메뉴얼 수정.. 전부 해보려고 갈팡질팡하며... 힘들어하던 기억이 생각나네요ㅜㅋㅋ 이 영상을 그때 봤다면 좀 더 유연하게 행동할 수 있었을 것 같네요... 피드백자체는 잘되는 편이었거든요ㅜㅜ 암튼 저에게 먼가 깨달음을 주는 영상이었네요
뒤늦게 현재 가장 필요한 영상을 보고 갑니다.
2020년 건강하세요 포프님 ㅎㅎ
문서화라는건 어디서 배우는 건가요? 인턴 들어가면 회사에서 배우고 그런 개념 인가요? 대학에선 안배울거 같은데.. 교육 체계가 따로 없고 그냥 프로젝트 참여하면서 어깨너머로 배우는 방식인가요
그런 것 같네요. 프로그래머 외 직업을 봐도 문서화는 회사가서 그 회사의 프로세스를 배우니까요.
단 프로그래밍은 최소한 오픈소스 프로젝트에서 문서화가 어떻게 되는지 미리 볼 수는 있어요
SAP나 은행은 변수명이 개똥같은데 도큐멘트도 없고... 정말 헬임ㅠㅡㅠ
왜?
문서화 넘나 귀찮은것... doxygen 이라도 쓰고 있는데 이것마저 귀찮 ㅋㅋㅋㅋ 근데 막상 써놓으면 나중에 읽으면 도움이 아주 약간 되도라구여 ㅋㅋ 코드 고칠 때 같이 고칠 수도 있고
저도 doxygen 써볼까 생각중인데 .. 개인 프로젝트 같은 작은 프로젝트에도 괜찮을까요?
@@khb8944 남들이 보지 않을 코드는 그냥 주석 없이 쓰는 걸 추천해여 보텅 개인 프로젝트는 코드가 훅훅 바뀌기 때문에 저는 주석 달 시간에 코딩하는게 더 낫다 라는 주의라. 그래도 그냥 연습을 한다는 의미에선 뭐든지 하면 나쁘지 않을 것 같아요.
@@kyusikshin4162 답변감사합니다!
지금 uml 때문에 고생하고 있는데.. 실무로 가면 이런 문서화 지옥에 깔리지 않겠죠...
아직도 실무에서 uml을 많이 사용하는 곳은 많지 않죠.
마지막 팩폭이지만 지당한 진실....
포프님 영상 보면서 에너지를 얻습니다... 프로그래머 공부 이제 막 시작 중인데 도움 많이 됩니다. 아직 제가 못 알아듣는 부분도 있지만... ㅎㅎ 직접 만나뵙고 싶네요. 늘 감사합니다^^
저는 구역별로 ~~일을 한다
라고 써놓는데 코드를 잘짜든 못짜든 남이짠코드, 내가 옜날에 짠 코드 보는게 그냥 말그대로 뵈기싫어서...ㅋㅋ 그렇게 하니까 나중에 보면 그래도 좀더 볼만 하더군요
나쁘지 않은 방법이죠
9:30 와 팩트로 후두려맞았네
와 진짜 공감되는 말씀을 많이 해주시네요...
저도 항상 신입에게 말하던 것 이었는데...
국영수과 중요하다고....
특히 국어는 회의때 니가한 일 잘 말할 수 있는(사기?) 밑거름이다 라고....
공감하는 이야기라 좋았습니다.
// 코드 문서화, 프로세스 문서화, api 문서화 + 멋있는 어른 되는법
키야~~ 요점을 이리도 깔끔하게 정리해서 콕 찝어 주시다니 역시~~
출근 하기 전 반성하고 갑니다. :)
오늘 의상컨셉은 황토방이신가요ㅋㅋㅋ
아 폽형 올만에 패셔너블한데 왜 재뿌리심
기 안죽는데 말이지요. 원래 그냥 있는 옷 입어요...
이렇게 하지 않으면 폽형이 댓글을 달아주시지 않는걸요...와 폽형 등판하셨어요 신난다!!!
Pro + grammer ^^?
프로그래머 수학 과학 국어 영어 핵심은
수학과 같이 언어를 사용하는 능력이 중심 논점이다
꿀팁 감사합니다
형 조명 어두우니 더 잘생겨보임. 뒤에 꾸밀 필요도 없고
형 사랑해요!
저는 문서화를 프로젝트 중간에 이직할때만 쓰는데...
매일 시작할 마음으로...
저는 코드로는 완벽한 문서화가 안되서 주석을 많이 답니다.
주석을 달아서 찾기도 더 편하기도하고.
구간 나누기도 편하기도 해서요.
오늘도 배우고 갑니다!
소설을 쓰는 게 프로그래밍에 도움이 되나요? 신인상 한 번 타고 싶어서 소설 쓰는 콘티나 e북 만드는 인강 들으려고 하거든요. 콘티는 수집해서 어떤 식으로 진행할 지는 아는데 어도비 다루는 건 좀 적응이 되야되겠더라고요.
세상에 프로그래밍에 도움이 안되는 건 없습니다. 얼마나 도움이 되느냐 차이겠죠 :) 저도 취미로 소설 썼던 사람인데.. 아주 조금 도움 되었 다 생각
0:26
1:27
2:36
5:07
6:45
12:43
123
얼굴이 너무 크게 나와서 부담스럽네요 ㅎ 안경을 쓰시면 더 좋을 거 같아요
Stan Kim 안경을 쓰든 안쓰든 그게 중요 한건 아닌거 같아요 ㅋㅋ 그냥 포프님이 전달하고자 하는 느낌을 눈빛 제스처 입모양 인상(미간 찌뿌리거나)강조 ,의미등을 더 확실하게 받는거같아요 크게나오면 목을 좀더 뒤로빼고 보시면 됩니다 ㅎㅎ
이리 좋아하시다니...