개발자의 인생은 프로그램이다.
프로그래머는 자신의 인생에 프로그래밍 습관이 베어 있습니다.
왜냐하면, 프로그래머는 하루시간의 대부분을 코딩을 하다보니 무의식 중에 그렇게 살고 있기 때문입니다.
왜냐하면, 프로그래머는 하루시간의 대부분을 코딩을 하다보니 무의식 중에 그렇게 살고 있기 때문입니다.
몇가지를 볼까요?
- 통신을 하기 위해서는 프로토콜을 맞추어야 합니다.
- 그리고, 스펙도 정의해야 합니다.
- 일을 시작할 때는 “{” 끝날 때는 “}” 라고 하십시요.
- 그리고, 전역변수와 글로벌변수를 잘 선언해서 쓰십시요.
- 일이 많고, 혼란스러우신가요?
- 혼자서 할 수 없을만큼 일이 많다구요?
- 그리고, 가능하면 super deamon이 process들을 control 하는 방식으로 일하지 마세요.
- 일이 잘 진행되고 있는지 모르겠다구요? Alive check를 날리세요.
- 자, 중요한 건 로그입니다.
- 주석을 잘 달지 않는 사람들은 두 가지 경우입니다.
- 프로그래머가 procedual language 에서 object oriented language 를 배우게 되면, 사고체계도 그렇게 변하게 됩니다.
- 웹 프로그래밍과 서버 프로그래밍과 클라이언트 프로그래머는 사고체계가 틀립니다.
프로토콜을 맞추지 않고, 메시지부터 던지면 통신은 되지 않습니다.
당신은 혹시 회의석상에서 메시지부터 던지시진 않나요?
당신은 혹시 회의석상에서 메시지부터 던지시진 않나요?
즉, 같은 용어는 같은 뜻이어야 합니다.
같은 말을 다르게 듣고 있지 않으신가요?
논쟁을 하거나 회의를 할 때 만일 같은 이야기가 맴돈다면,잠시 중단을 하고 스펙을 정의하셔야 합니다.
같은 말을 다르게 듣고 있지 않으신가요?
논쟁을 하거나 회의를 할 때 만일 같은 이야기가 맴돈다면,잠시 중단을 하고 스펙을 정의하셔야 합니다.
일의 시작선언과 종료선언을 하지 않는다면, 당신은 프로그래머가 아닙니다.
“언제 시작해서 언제쯤 끝날 것 같아요.”
“끝났습니다.” 이렇게 이야기를 해야 합니다.
늦어지면, 당연히 늦어진다고 이야기해야죠. 익숙해지셔야 합니다.
“언제 시작해서 언제쯤 끝날 것 같아요.”
“끝났습니다.” 이렇게 이야기를 해야 합니다.
늦어지면, 당연히 늦어진다고 이야기해야죠. 익숙해지셔야 합니다.
대화하면서, “아까 그거? 아니 그거” 를 자주 말씀하신다면, 변수선언을 잘못했을 확률이 큽니다.
잠시 대화를 멈추시고, “그건 A이고, 그건 B야.” 라고 다시 선언을 하세요.
잠시 대화를 멈추시고, “그건 A이고, 그건 B야.” 라고 다시 선언을 하세요.
그러면, thread 를 더 만들어야 합니다.
thread 는 멀티태스킹을 의미합니다.
thread 없이 여러 개의 일을 혼돈해서 처리하고 있다면, 분명 잘못된 결과가 나올 가능성이 큽니다.
일이 복잡해진다면, thread를 분리하십시요.
thread 는 멀티태스킹을 의미합니다.
thread 없이 여러 개의 일을 혼돈해서 처리하고 있다면, 분명 잘못된 결과가 나올 가능성이 큽니다.
일이 복잡해진다면, thread를 분리하십시요.
프로세스를 하나 더 만들어야 합니다.
자신과 비슷한 일을 하는 사람을 데려오세요.
그렇지 않으면, 현재 돌고 있는 프로세스(당신)가 dead-lock 이 걸려서 좀비상태가 되어버립니다.
만일, 혼자 밖에 없다면 혼자서 할 수 있는 만큼만 하세요.
dead-lock이 되면, throughput 이 제로이지만 혼자서라도 처리하면 적어도 제로는 아니니까요.
자신과 비슷한 일을 하는 사람을 데려오세요.
그렇지 않으면, 현재 돌고 있는 프로세스(당신)가 dead-lock 이 걸려서 좀비상태가 되어버립니다.
만일, 혼자 밖에 없다면 혼자서 할 수 있는 만큼만 하세요.
dead-lock이 되면, throughput 이 제로이지만 혼자서라도 처리하면 적어도 제로는 아니니까요.
대용량 처리가 힘들어집니다. component 를 잘 정리하고 스펙을 잘 정리해서 event driven 방식으로 처리하세요.
(잘 안될겁니다. 하지만, 성공하면 업그레이드 되는 겁니다.)
당신이 사람인 이상, super process 의 한계는 있습니다.
일욕심을 혼자 내지 마세요.
일이 늘었다 줄었다 하는 동안 프로젝트는 실패를 향해 치닫게 될겁니다.
(잘 안될겁니다. 하지만, 성공하면 업그레이드 되는 겁니다.)
당신이 사람인 이상, super process 의 한계는 있습니다.
일욕심을 혼자 내지 마세요.
일이 늘었다 줄었다 하는 동안 프로젝트는 실패를 향해 치닫게 될겁니다.
물론, 규격은 사전에 합의해야겠지요.
Alive check를 하지 않으면, 업무 펑크(장애)가 나도 알 수가 없습니다.
이건 매우 중요한 행위입니다.
Alive check를 하지 않으면, 업무 펑크(장애)가 나도 알 수가 없습니다.
이건 매우 중요한 행위입니다.
화면이 없는 서버프로그램의 경우, 로그를 통해서만 정상작동 여부를 알 수 있습니다.
당신은 업무로그는 어디에 찍고 계십니까?
만일 팀에 당신이 하고 있는 일을 찍은 로그시스템이 없다면, 당장 JIRA 를 설치하십시요.
그렇지 않으면 wiki 라도 설치해서, 하고 있는 일의 이력을 남기십시요.
그렇지 않으면, 일이 중간에서 멈추었을 때 추적하고, 분석하고, 감지하는 모든 행위를 할 수 없게 될 것입니다.
로그를 남기지 않는 서버 프로세스는 빠르지만, 결국 유지보수할 수 없는 프로세스가 되고 맙니다.
항상 하는 일이 똑같아서 소스변경이 없는 경우에는 로그를 남기지 않기도 합니다.
당신은 업무로그는 어디에 찍고 계십니까?
만일 팀에 당신이 하고 있는 일을 찍은 로그시스템이 없다면, 당장 JIRA 를 설치하십시요.
그렇지 않으면 wiki 라도 설치해서, 하고 있는 일의 이력을 남기십시요.
그렇지 않으면, 일이 중간에서 멈추었을 때 추적하고, 분석하고, 감지하는 모든 행위를 할 수 없게 될 것입니다.
로그를 남기지 않는 서버 프로세스는 빠르지만, 결국 유지보수할 수 없는 프로세스가 되고 맙니다.
항상 하는 일이 똑같아서 소스변경이 없는 경우에는 로그를 남기지 않기도 합니다.
하지만, 매번 하는 일이 갱신이 되는데, 업무 로그를 남기지 않는다면 이미 당신은 프로그래머가 아닙니다.
빨리 다른 직업으로 전환하시길 권유드립니다.
빨리 다른 직업으로 전환하시길 권유드립니다.
아주 쉽게 말을 하거나, 대화를 잘 하지 않는 성격인 경우입니다.
아주 쉽게 말을 하는 사람은 코드가 실제 언어처럼 쉽게 읽힙니다.
따라서, 주석을 달 필요가 없습니다.
하지만, 대인관계에 서투른 사람은 다른 사람을 배려하지 않기 때문에 주석을 달지 않습니다.
전자는 고수이고, 후자는 하수이죠.
아주 쉽게 말을 하는 사람은 코드가 실제 언어처럼 쉽게 읽힙니다.
따라서, 주석을 달 필요가 없습니다.
하지만, 대인관계에 서투른 사람은 다른 사람을 배려하지 않기 때문에 주석을 달지 않습니다.
전자는 고수이고, 후자는 하수이죠.
은행 전산실의 사람들은 일을 순차적으로 처리하는 걸 좋아합니다.
또, cobol의 숙련도만큼 순차적 일처리가 매우 세련됩니다.
일을 잘하는 것과 사고체계가 다른 것은 분리되어 이해되어야 합니다.
자신과 카테고리가 다른 개발자들을 무시해서는 안됩니다.
우리와 맞는지 안맞는지를 판단해야 합니다.
맞지 않다면, 빨리 제자리를 찾아주는게 좋습니다.
또, cobol의 숙련도만큼 순차적 일처리가 매우 세련됩니다.
일을 잘하는 것과 사고체계가 다른 것은 분리되어 이해되어야 합니다.
자신과 카테고리가 다른 개발자들을 무시해서는 안됩니다.
우리와 맞는지 안맞는지를 판단해야 합니다.
맞지 않다면, 빨리 제자리를 찾아주는게 좋습니다.
프로그래머들도 그 변화를 겪을 때 매우 많이 성장하게 됩니다.
하지만, 꼭 클라이언트에서, 웹, 서버, DB가지 섭렵해보시길 강권해드립니다.
시장에서 강자가 되려 하신다면, 적어도 1년씩은 해보시길 추천드립니다.
하지만, 꼭 클라이언트에서, 웹, 서버, DB가지 섭렵해보시길 강권해드립니다.
시장에서 강자가 되려 하신다면, 적어도 1년씩은 해보시길 추천드립니다.
그리고, 당신이 프로그래머라면 지켜야 하는 당연한 것들이 있습니다.
만일 당신이 동료들과의 커뮤니케이션조차 어려움을 겪고 있다면 분명 당신은 이 업종이 적성에 맞지 않는 겁니다.
만일 당신이 동료들과의 커뮤니케이션조차 어려움을 겪고 있다면 분명 당신은 이 업종이 적성에 맞지 않는 겁니다.
댓글 없음:
댓글 쓰기