1. 코딩으로 먼저 급하게 접근하지 말고, 순서도를 머리로 상상하라.
- 보통 코딩을 시작하려 성급하게 달려드는 경향이 있습니다. 그러나 우선 가장 중요한것은 퍼포먼스적인 면에서 가장 중요하게 생각해 차분히 접근하는게 중요합니다. 단순하게 이런 경우를 예로 들수 있겠군요. 만약 어떤 테이블의 분류코드를 변환시켜주는것이라고할때, 단순히 코딩적으로 막 짜지 말고, 자료가 그렇게 많지 않다면 프로그램 시작전에 미리 불러놓고 하는것입니다. READ TABLE 로 간단하게 DB를 구지 뒤지지 않아도 쉽게 해결될수 있도록 말이죠. SINGLE 등을 써서 반복적으로 가는 횟수가 적다면 상관없는데 같은 SINGLE데이터를 여러번 이렇게 하는것은 비효율적입니다. 순서도를 그릴때 고려해 할 요소, 그리고 전체적인 그림을 그리셔야 합니다. 코딩을 하면서 약간의 방향을 바꿔나가는건 언제나 있을수 있는 일이지만, 전체의 순서도 묶음단위가 바뀌는건 자신의 상상력이 부족한것입니다. 이러한 면에서 PERFORM 을 우선 만들고 시작하는게 중요합니다. 보통 코딩하면서 데이터 셀렉트 퍼폼을 만들고, 이제 수정 퍼폼, UPDATE 퍼폼을 순차적으로 만듭니다. 그것보다 우선적으로 PERFORM 등을 만들어 놓고 시작하는게 중요합니다.
2. 코딩하긴 전 상상하라. 데이터를 가정하고 상상하라.
- 코딩할때 상상력이 동원되어야 할 가장 큰 부분이 아마 LOOP 안에서 복잡한 로직을 짤때 일것입니다. 퍼포먼스를 포기하고 간편화 시켜서 짤수도 있지만 LOOP 을 한번만 돌려서 해결하고자 할때 우리는 상상력이 필요하죠. 테스트자료를 만들기전 상상하는 습관을 가지시는것도 중요합니다. 테스트를 하지 않아도 자료를 임의로 상상해서 그려보고 변경되어 가는 과정과 함께 합니다. 중요한것은 그냥 상상하는게 아니라, 정말 자료 A라는 값 B라는 값이 각각 존재한다고 실제로 머릿속에서 해보는것입니다. 그리고 만약 그 외의 경우가 없는지 생각해보는 거죠. 너무 뻔한 경우 말고 엄청나게 어의 없는 데이터가 들어올 가능성이 없는지 상상해 보는것입니다. 정말 이러한 경우가 전부인지 말이죠.
3. 상상하기 힘들면 디버깅을 하면서 순차적 코딩을 해라. (테스트 자료를 요구하라.)
- 상상하기 힘듭니까? 그럼 우선 무조건 테스트자료를 만들어 보던가, 요구를 합니다. ( 초보일경우, 숙련자야 알아서 구하겠지요. ) 저는 너무 로직이 복잡해서 머리가 안 떠오른다고 했을때, LOOP AT ... ENDLOOP. 만 적어놓고 코딩을 하나씩 하면서 돌리면서 합니다. AT NEW / AT END OF 등도 초심자에게는 그렇게 쉬운 경우가 아닌데, 이러한게 정말 제대로 타는지 볼려면 한줄씩 코딩을 늘리면서, 테스트 데이터를 계속 조작하면서 눈으로 확인해버리는게 가장 쉽습니다.
4. 순차적 코딩하기에 복합적으로 고려해 할 요소가 많다면 중단하라.
- 계속 코딩을 하다가 복합적으로 고려해 할 요소가 너무 많아서 자기는 나름 퍼포먼스 생각한다고 코딩을 하고 있는데 그게 오히려 너무 복잡하게 진행된다면? 그대로 하지 말고, 그냥 쉬운 코딩으로 바꾸는게 좋습니다. AT NEW / AT END OF 등을 안써도 아시겠지만. HEADER / ITEM의 개념으로 나눠서 LOOP 안에 LOOP을 돌리면 됩니다. SORT잘해서 해야 합니다. 너무 어려우면 우선 이렇게라도 바꿔서 자기도 , 또는 유지보수 하는 사람도 알아보기 쉽게 만들 필요가 있습니다. 저는 첫 사이트에 열심히 한다고 무조건 LOOP은 한번으로 해결한다는 신념으로 많이 했는데, 인수인계할때 이해를 시킬려면 힘든 경우가 많았습니다. (당시는 PERFORM도 잘 쪼깨지 않아서 더러워보였죠.)
5. 변수 CLEAR 시점에 가장 중점을 두어라.
- 가장 많이 하는 실수가 무엇일까요? 그렇습니다. CLEAR 입니다. 저또한 이같은 경우로 초반에 엄청나게 예상치 못한 에러를 만들었습니다. 거의 어려운 로직을 완벽히 구현하고도, CLEAR 를 특정시점에서 안 해주었을때의 문제는 정말 너무나도 큰 가장 중요한 문제였던것 입니다. 아무리 코딩을 잘해도 클리어를 못하면 바보가 됩니다. 값이 이상하게 나오면 그게 끝입니다. 보통 APPEND 를 할 경우 또는 어떤 체크변수를 넣고 클리어되도 되는 시점이 어느시점인가? 값을 넣거나 APPEND를 하거나 한 후에.. CLEAR 시점을 바로 찾아야 합니다. 보통 APPEND 했으니 이제 다음 코딩으로 넘어가거나, 값을 넣었으니 다음코딩으로 넘어갑니다. 무조건 추가하는 시점에서 비워야 할 시점을 찾는게 중요합니다. 찾다가 비우지 않아도 되겠다? 싶으면 그때 다음 코딩을 진행하는 것입니다. 이걸 거의 절대적 코딩 습관입니다. 이렇게 하면 코딩하는 사람도 쉽습니다. 다음 코딩으로 넘어간 후 CLEAR 찾을려면 한참 보고 있어야 할지도 모릅니다.
6. 재사용화 해라.
* 다른데서도 장기적 중복 기능 사용할것 같으면 Function / 단기적 중복 사용할것 같으면 Perform
* 데이터등의 하나의 기능같은 data/method 객체화로 만들것이면 Class 를 사용하라.
- 다른 말이 필요있을까 모르겠지만, -_- 위와 같이 잘 생각하셔서 유용도에 따라서 나눠주는것도 좋습니다. 저도 class를 이용하는 코딩 type-pools를 이용하는 데이터중복선언모음.. 이런걸 잘 활용해서 다음년부터는 좀 다른 코딩 스타일을 만들어 갈려고 합니다.
7. 필드심볼 이용을 하라. 그러나 퍼포먼스가 두렵다면 그냥 안좋아보이는 코딩도 좋은것이다.
- 필드심볼이 없었더라면 아밥의 코딩은 거의 5000줄을 넘어갈것입니다. 실제로 필드심볼을 모르시는분들이 약간 어려운 프로그램을 짜면 이렇게 되죠. 필드심볼은 보통 사용할때가 패턴적으로 정해져 있기 때문에 그리고 이 글은 필드심볼을 강좌하는 게 아니기 때문에, 각자 잘 알아보시는게 중요할것 같습니다. 그러나 필드심볼을 무조건 좋다고 쓰는것도 그리 좋진 않습니다. ( ) = ( ) 라고 코딩할때 필드심볼을 이용해서 저는 코딩줄수을 줄일려고 하다가 오히려 속도면에서는 많이 뒤쳐지는것을 알았죠. 이쁜 코딩도 좋지만, 가장 속도가 나면서 하드코딩도 무척이나 좋은 것이라는것을 알수 있습니다.
8. 시스템 변수들을 최대한 활용하라. F1을 생활화 하라.
SY-TFILL, SY-DBCNT, SY-TABIX , SY-MSGID 등 시스템변수를 활용하면 은근히 체크를 쉽게 할수 있습니다. DBCNT = DBCNT + 1 . 로 체크를 하지 않아도 될게 은근히 많으며, 어떤 위치에 APPEND 가 되었구, 어떤 위치에 INSERT가 되었는지도 쉽게 알수 있습니다. SY-TABIX를 단지 룹돌때만 쓴다고 생각하시는 분들이 많은데 F1을 눌러보셔서 보시길 바랍니다. 그래서 하는 말인데, F1을 무조건 생활화합니다. ITAB을 수정할려고 하는데 어떤 조건에 만족하는 것만 한꺼번에 수정할수 없을까? 하는 의문이 들었을때, 두가지 방향으로 행동을 할것입니다. F1을 눌러서 찾거나 "아,,,그런게 있을까?;; 그냥 하자..LOOP돌려서.."
9. 아는 범주에서 기능을 구현하지 말고, 구현할 기능의 구현 가능한 SYNTAX를 찾아보라.
- 많은 부분 "상식적으로 기능이 있지 않을까?" 생각하고 접근하는것과 자기가 아는 SYNTAX만 쓰는데는 그 성장이 큰 차이가 있습니다. 프로그램 언어는 인간이 만들었는데, 인간이 접근하는 것처럼 접근하는 방법이 거의 왠만하게 있습니다. 그러나 보통 아는 신택스로만 복잡하게 코딩하고 효율적이지 않다고 느끼는 코딩을 우리는 실제로 봅니다. 그러나 분명 인간이 만들었고, 효율적이라고 생각하는 접근법, 즉 가장 근접한 SYNTAX나 또는 활용법이 있습니다. 그것을 발견하는 능력이 중요합니다. 이렇게 발견한 SYNTAX가 결국 응용에서 응용으로 이어질것이기 때문입니다.
10. 여러 구문의 취약점을 알아놓아라.
SELECT ENDSELECT 돌리다가 BREAK-POINT의 유의점, IN RANGE변수보다 오히려 FOR ALL 이 뻑나서 덤프떨어질 확률이 적은점등, ABAP에 여러가지 취약점들이 있습니다. 퍼포먼스 개선의 여지를 생각하면서 언제나 연구하는게 좋습니다. 인생을 살때 언제나 "더 나은 무엇인가가 있겠지" 하는것 처럼, "더 나은 방법이 있지 않을까?"라는 의문을 달고 사는게 중요합니다.
마지막 정말 하고 싶은 말 . 아무리 안 되어도 어려워도, 스트레스를 받지마라.
- 많은 부분 사람들은 스트레스를 받습니다. 스트레스가 있다는 것은 그 사람은 무엇인가에 '저항'하고 있다는 것입니다. 즉, 스트레스는 어떠한 욕망의 저항에서 나오는것이지, 정말 어떠한 일이 어렵다 또는 짜증난다 해서 나오는게 아닙니다. 생각해 보겠습니다. 게임을 하는 것 VS 코딩하는 것 어느게 더 하기 싫습니까? 할때 대부분 '코딩'이라고 거의 100% 말합니다. 그 이유는 무엇일까요? 코딩을 할때 놀고싶은 마음, 쉬고 싶은 마음이 존재하기 때문입니다. 게임이나 코딩이나 둘다 머리를 써야 하고, 손을 써야 합니다. 게임도 안되면 스트레스 받지만, 하기 싫지는 않습니다. 그 스트레스를 즐기기 때문이겠지요. 아밥의 코딩도 그렇게 생각하세요. 즐기고 그냥 안되면 다시 뒤지어 업고, 누가 자기 실력가지고 모라고 하면, '다 나 잘되라고 하는 말이야' 하면서 그냥 받아들이면 됩니다. 인생에서 가장 많은 일을 하는 일터에서 감정의 에너지를 소모하지 마십시오.
'개발이야기' 카테고리의 다른 글
| IT의 풀리지 않는 미스테리 (0) | 2010.12.24 |
|---|---|
| 애플이 플래시를 지원하지 않는 이유 - 스티브 잡스 (0) | 2010.05.25 |
| 개발자의 심리학[지디넷코리아] (0) | 2010.01.28 |