日本語에서 번역 • 원문 보기 소개
안녕하세요. 저는 TORII입니다. Colorkrew(이하 CK)에서 일했던 옛 프로그래머입니다.
오늘은 Colorkrew 프로그래밍 노인협회에서 상위 3위 안에 드는 제가 프로그래밍과 관련된 과거와 현재에 대해 이야기하고자 합니다. (정확히는 모르겠지만)
사실 저는 여전히 세계 프로그래밍 노인 협회에서 젊은이들에게 좋은 자리입니다. 하지만 최근 우리 회사에 젊고 신선하며 에너지 넘치는 엔지니어들이 하나둘 늘어나는 반면, 노인들은 정신을 잃었고, 어느새 그런 상태가 되었습니다. 제가 방금 앉았을 때도 그랬습니다. 정말 이상한 일들이 있습니다.
시작하자.
에피소드 1 엔지니어와 프로그래머들
인류가 시작된 이래로 상위 프로세스를 다루는 시스템 엔지니어라는 사람들이 많았지만, 지난 10년 정도 동안 프로그램을 작성하며 생계를 유지하는 엔지니어라고 부르는 사람들의 수가 크게 늘었습니다.
아니요, 오래전부터 그랬을지 모르지만, 솔직히 언제부터 늘어나기 시작했는지는 모르겠습니다. 주관적인 인상으로는 갑자기 커졌다는 인상입니다. 그것만으로도 이미 벽입니다.
엔지니어와 프로그래머의 차이점은 무엇인가요?
저는 2010년대 초반에 스스로를 엔지니어라고 부르기 시작했지만, 그 전에는 프로그래머라고 생각했습니다.
변경의 이유는 명함에 직책을 적었을 때 회사 규정에 따라 '프로듀서'라고 쓰라는 지시를 받았고, 항의와 조정 끝에 항의하고 조정했으며, 상사와 상의한 후 결정을 내렸을 때 처음에는 '프로그래머'가 되고 싶다고 했지만 거절당해 마지못해 '소프트웨어 엔지니어'라고 썼기 때문입니다.
프로그래머는 일반적으로 누군가가 만든 설계 문서를 기반으로 코딩하고 수정하는 사람으로 불리는 것 같습니다. 또는 관리하지 않는 사람으로도 불립니다.
엔지니어가 공학 학위를 가진 사람들이라는 인기 있는 이론이 있는 것 같고, 실제로 해외 일부 국가에서는 학위 없이는 IT 분야에서 일자리를 구하기 어려운 경우가 있는 것 같습니다. 물론 일본에서는 그런 학위가 필수는 아닙니다. 초등학생도 스스로를 엔지니어라고 부를 수 있습니다.
산업, 상황, 맥락에 따라 정말 달라지며, 요령 IT 직업 중에는 프로그램을 작성하지 않는 경우가 많고, 이들을 엔지니어라고도 부르기 때문에 프로그램을 작성하는 사람들은 기본적으로 기분 차이입니다(프로그래머보다 엔지니어라고 부르는 게 더 멋지게 들릴 수 있습니다). 그리고 다양한 IT 직종을 포함하는 일반적인 용어로 생각하는 것이 좋습니다.
그래서 지금 저는 스스로를 엔지니어라고 부릅니다. 하지만 본질적으로는 영원한 프로그래머입니다.
에피소드 2 탭, 공백, 대괄호
이 이야기는 소스 코드의 들여쓰기에서 탭을 사용할지 공백을 사용할지에 관한 것입니다. 예전에는 탭이 많았던 줄 알았는데, 지금은 대부분이 공백이 되었습니다. 모르는 사이에 결정된 거죠. 아니요, 놀랍습니다.
탭의 문제는 구조 이외의 용도로 사용하면 레이아웃이 무너진다는 점인 걸 알고 있습니다.
하지만 공간은 공간이고, 스페이스/백스페이스를 N번 누르는 게 번거롭고, 몇 번 누르면 들여쓰기가 어긋나게 됩니다. 복사 및 붙여넣기 시 커서 위치가 어긋날 수 있습니다.
응? 그냥 탭 키를 누르면 돼? 그게 바로 에디터(소프트 탭)의 힘이야.
좋은 프로그래밍 편집기를 사용하면 거의 문제가 없습니다. 일반 프로그래밍 편집기의 경우, 공간 중앙에서 실수로 복사하면 한 글자가 초과되거나 부족한 들여쓰기 줄이 생깁니다. 한 글자가 어긋나면 눈에 띄지 않습니다.
가장 최악인 점은 소프트 탭이 없는 저렴한 편집기만 사용할 수 있고, 공백을 N번 반복해서 눌러야 해서 너무 고통스러워서 욕하고 싶을 정도라는 점입니다. "여딛음 사용하라고 지시한 사람이 뭐지?"
하지만 지금은 그런 환경이 드물기 때문에 공간에 전혀 문제가 없습니다.
일 년에 여러 번 가끔 한 글자가 부분적으로 과잉이거나 부족한 부분이 생기는 홈이 되기도 하지만, 저는 그걸 보고 고치고 존재 자체에 크게 신경 쓰지 않습니다(아, 보시면 꼭 풀 리퀘스트를 해주세요).
비슷한 이야기로, if와 for와 같은 제어 문장의 괄호 어디부터 시작할지에 관한 이야기도 있습니다. 이 문장은 통제와 같은 줄 끝이나 다음 줄에 적혀 있습니다.
요즘은 C#과 같은 일부 언어를 제외하고, 통제문과 같은 줄에 글을 쓰는 것이 주류인 것 같습니다.
프로그램을 처음 쓸 때는 컨트롤 문과 같은 줄에 썼지만, 처음에 했던 프로젝트에서는 괄호의 시작과 끝이 분리되어 있는 오류가 잦았습니다. 이런 글쓰기 방식에서는 한눈에 괄호가 빠졌거나, 과도하게 쓰여 있거나, 들여쓰기인지 알 수 없습니다.
음, 제가 말하는 건 통제 진술을 쓰지 않는 것이지만, 지금은 젊음의 절정기입니다.
스위치 문장에 라벨이 1000개 정도 있었는데, 너무 어리석어서 초과해서 이상한 오류가 발생했습니다.
그래서 다음 줄에 괄호 시작을 쓰도록 스타일을 바꿨습니다. 그러면 그런 어리석은 오류가 더 이상 발생하지 않았습니다. 다음 줄에 괄호 시작이 없으면 들여쓰기가 되지 않아서 문제의 위치를 보기만 해도 알 수 있습니다. 이게 가장 좋습니다.
그 이후로 저는 개인적으로 글을 쓸 때 그렇게 쓰고 있습니다.
하지만 오늘날 세상은 그렇게 최선의 방식으로 글을 쓰지 않는 것 같습니다. 가장 큰 요인은 아마도 한 줄만 괄호로 사용하는 것이 허용되지 않는다는 점일 것입니다. 하지만 괄호를 다루기 어려운 경우는 점점 줄어들고 있습니다(편집자의 힘 등으로 인해).
탭 공간이나 괄호에 대해 어떻게 쓰든, 저장 즉시 프로젝트가 설정한 형식에 맞게 편집자가 자동으로 수정해주니, 원하는 한 어떤 스타일로든 글을 쓰기에 좋은 타이밍입니다.
에피소드 3 라이선스 표기법
신입 교육에서 신입 교육을 받았을 때, 신입 직원 교육 중에 소스 코드 시작 부분에 회사 이름의 라이선스 표기법을 쓰는 법을 배웠습니다.
일본 저작권법상 직접 작성할 필요는 없지만, 어차피 파일 설명을 올릴 예정이라 추가로 작성해야 한다는 것을 알고 있었습니다.
하지만 이 웹 산업, 정확히 말하면 Colorkrew에서는 오픈 소스 코드에 확실한 라이선스 표기법이 있는 것을 본 적이 없고, 그들이 작성한 소스 코드는 라이선스가 부여되어 있습니다. 파일 내용을 설명하는 헤더를 본 적도 없습니다. (*1)
그것에 대해 글을 쓰는 관습이 없는 것 같습니다. 처음에는 혼란스러웠지만, 최근에는 꼭 글을 쓸 필요가 없다는 생각이 들기 시작했습니다.
직접 작성하지 않아도 저작권이 확립되고, 소스 코드가 유출되면...... 저도 그렇게 생각했어요.
하지만 요즘은 회사 제품의 소스 코드를 제대로 첨부하는 것이 더 낫다고 생각합니다.
드디어
나쁜 문장을 많이 썼지만, 인기가 있으면 계속될 수도 있어. 우리 컬러크루 프로그래밍 노인회 회원이야...... 우리는 가끔 직원을 채용하고 있어.
관심 있으시면 아래에서 연락해 주세요.
https://recruit.colorkrew.com/
*1) 예외는 Xcode에서 생성된 파일입니다. 자동으로 파일 이름과 저작권을 생성합니다.
그래서 가끔 Xcode에서 생성된 소스 코드에 회사 이름 대신 개인 이름이 저작권으로 표시되는 경우도 있습니다.
Xcode 프로젝트 파일이 이렇게 설정되어 있기 때문에, Xcode를 통해 소스 코드를 만들면 누가 만들든 그 사람의 저작권이 유지됩니다......