CODE REVIEW를 가장한 후기글_(상)

program blueprint

뭔가 이렇게 큰 테두리를 잡고 시작해야 편하고 빠르게 만들 것 같아서

한 번 마인드맵을 만들었다.

 

이렇게 하니까 확실히 반복되는 부분도 보이고 깔끔하게 만들 것 같았다.

(근데 왜 중간중간 추가할 기능들이 생각나는지...)

---

솔직히 구 버전(20년도.ver)을 수정하려 했었는데

너무 막 짜여있어서 새로 시작했다.

일단 본문부터 뼈대를 잡고 필요한 대로 모듈화 했다.

 

모듈화

프로그램을 짜다보면 반복되는 부분이 나오기 마련이다.

이를 용도에 따라 함수나 클래스로 정의 해  잘 사용하면 편리하고 깔끔해진다.

함수

나는 이 프로그램에서 함수를 쓸까 클래스를 쓸까 고민하다가

굳이 클래스로 작성해야하나 싶어서

결국 함수만 사용했다. 함수로도 충분했다.

 

클래스랑 함수랑 엄연히 다르긴 한데

클래스는 뭔가 기능이라기보다 속성(?) 같은 느낌이고

그렇게까지 방대하고 복잡한 프로그램을 만들 게 아니었어서 그냥 함수만 사용했다.

 

확실히 이렇게 정의하고 나니 코드가 깔끔하고

어느정도 줄 수가 줄어들어 보기 좋다.

 

---

함수

함수를 사용할 때 가장 주의해야 할 것은 변수처리라고 생각한다.

함수 변수

함수에는 인자라는 것이 있다.

함수에 주는 input과 비슷하다고 할 수 있는데

함수는 인자를 내부적으로 활용할 수 있다.

인자

하지만 이렇게 외부에서 정의된 'critical'을 바꿀 수 없다.

비슷하게, 함수 내부에서 새롭게 정의된 변수는 지역변수라고 부르는데

이 또한 내부에서 임시로 생성된 것이기에 함수 외부에서 사용할 수 없다.

.

함수 외부에 영향을 주려면 'global'로 수식해야 한다.

이렇게하면 함수 내부에서 전역변수로 사용할 수 있게 된다.

 

---

반복되는 부분을 함수로 처리해 코드를 줄였는데

함수 안에서 다른 함수를 불러오고, 전역변수로 할당하고,

그러다보니 생각보다 복잡해진 감이 없지 않아 있다.

.

데이터 처리

어떤 코드든 데이터 처리가 가~~~~장 중요하다는 생각이 든다.

사용자에게서 받아오든, db에서 받아오든 데이터를 어떻게 처리, 가공하느냐에 따라

프로그래밍 방식이 달라지는 것 같다.

.from database

파이썬에는 3가지 형태로 다량의 데이터를 수납할 수 있다.

형태가 변할 수 없는 (튜플), 키와 값으로 존재하는 {딕셔너리}, 흔히 사용하는 [리스트]

.

나는 영단어 프로그램이고 단어를 줄 때 뜻을 찾아야하기에

딕셔너리를 쓸까했는데 이후 구현이 너무 어렵고 복잡해질 것 같아서

그냥 리스트를 사용했다.

생성된 n차원 리스트

 

주로 split()함수를 이용해서 리스트를 만들었고

영단어를 {딕셔너리}의 키처럼 이용해서 적재적소에 출력했다.

(split을 많이 쓸수록 리스트 안에 리스트 안에 리스트....)

.

한 번 나온 단어는 또 시험보는 등의 중복을 피하려면 pop해서 없애야하는데

이는 guide리스트(실제로 pop되는)를 이용해 실제 리스트에는 영향이 없도록 만들었다.

파이썬 기본 내장 모듈인 random을 이용해 단어순서는 랜덤하게 출제된다.

데이터베이스 예시

database 파일에 가보신 분들은 아시겠지만 이렇게 메모장에 데이터들이 적혀 있다.

프로그램에서 원하는 데이터를 원하는 방식으로 편하게 끌어 쓸려면

이렇게 어느정도 전처리가 필요하다...

(생 노가다 작업이었다.. 이것만 아니었어도 2주는 빠르게 끝내는데..)

.

Unicode

데이터를 보면 문장형식은 첫 머리가 대문자로 시작한다.

영문과 해석문을 한 줄에 출력하면 공간을 너무 많이 차지할 것 같아서

이것만 따로 출력하려고 유니코드를 사용했다.

ord()로 유니코드 변환

처음 유니코드를 접했을 때 이걸 '어따 쓰는 걸까'라고 생각했는데

생각보다 너무 유용하다;;

 

대문자를 어떻게 구별할까 고민하다

처음에는 upper(), lower()가 생각났는데 뭔가 안 맞을 것 같았다.

그러다 바로 아스키코드가 떠올랐고 드디어 처음 써봤는데 진짜 너무 편했다.

(유니코드는 아스키코드의 확장판 느낌)

 

User

사용자에게서 입력을 받는 것은 기본 중의 기본이다.

하지만 내가 원하는 대로 입력해준다는 보장은 없다.

.

원하는 형식이 아니거나 / 지정된 범위를 넘어가거나 등등

보통 이런 경우에 아무것도 안해놓으면 프로그램이 오작동한다.

그래서 이번엔 만드는 김에 예외처리까지 제대로 만들었다.

try~ except~ finally~ else~

사실 예외처리가 에러를 예상하고 넣는게 아니라

에러를 만나고 보수하는 느낌이 강하다.

그래서 이렇게까지 하겠어?라는 모든 경우를 다 막아야 했다..

일부러 에러 띄우고 준비한 길로 유도하는 느낌이랄까

---

글이 너무 길어질 것 같아서 (하)에서 계속됩니다.