프로그래밍 언어를 가르치는 데 있어서 순서가 꼭 정해져 있는 걸까? (루비 글 정리하면서)

원래라면 지금 한참 잠을 자야 할 시간인데….

잠이 안오고 해서 대학원 석사논문 좀 빨리 쓰려고 이용했던 루비 언어 자료를 정리해서 블로그에 올려보려고 했는데…

일전에 C 언어 공부하던 자료는 내가 지금 올릴 수 없는 것이 그 자료가 한국에 있단 말이지…;ㅅ;

뭐 일단, 그렇게 자료 정리 좀 하고 있는데… 왠지 형식적인 글만 쓰게 될 거 같아서 좀 여러모로 맘이 복잡하다.

언어 배울 때 우리는 간단한 문법부터 해서 하나 하나 글 써나가는 법부터 배우고 그러고 나서 클래스니 뭐니 하면서 여러모로 해당 언어의 특징이니 그런 것들을 쭉 정리하고 더 나아가서 고급으로 가르치고 하는 것이 좀 많았는데…

 나름대로 여러 언어들을 쓰면서 느낀 것이지만, 한 언어를 제대로 할 줄 알면 나머지 다른 언어들 배울 때 여러모로 자기만의 노하우나 이해법에 맞춰서 금방 배울 수 있는 것이 있다는 걸 알고있다. 문법이라고 해서 뭔가 막 특이한 문법을 이용한다거나 하는 그런 것은 아니다. ㅎ마수형 프로그래밍이 어렵다고 한다면 그건 특정한 형태의 언어론이나 방법론에 의해서 만들어진 언어적 개념이다 보니 그 개념과 방법론만 알면 일단 구현 자체는 할 수 있으니깐 어렵다고도 느껴지질 않는다.

그러다 시간 좀 지나가다 보면 기존 언어에서도 새로운 언어나 패러다임에서 좋은 거 있으면 자꾸 흡수해 나가기도 한다. 그렇다고 해서 본질적인 부분이 막 바뀌고 그런 것이냐고 물으면 그건 절대 아니라는 것도 컴퓨터 공학의 이론적인 내용을 공부하게 되면 알 수 있는 내용들인 것이고…

그래서 여기저기서 막 걍 찍어내기식으로 정리하는 것보단 좀 더 확 와닿는 형태로 설명하는 것이 좋을 거 같은데…

어려울 지 아닌지는 모르겠지만 그렇게 하다보면 언어뿐만 아니라 언어 안에 들어있는 언어만의 특징이나 그런 쪽에 대한 설명이나 정리도 될 수 있을 거 같아서 좋은 거 같다만…

음…. 일단 정리 좀 해보자. ;ㅅ;

Advertisements

언어와 프레임워크, 기술에 휘둘리는 개발자..?

오랜만에 잡소리를 올려본다… (것보다 워드프레스가 오랜만이다..)

오래전에 OKKY에서 읽었던 글이 떠올랐다. 아마 이민석 교수님 글일꺼다. 컴퓨터공학으로, 프로그래머로써 올라가면서 부딧히는 5가지 벽에 대해서 설명하던 글이었을 꺼다. 그러면서 그래프로 보여주면서 어떤 단계에서 어려워하거나 휘둘려서 시간을 보내다보면 그때는 실력이 평행하게 가다가 나중에 어느 순간 지나면 실력이 확 오르고 하는 데 그 방해가 되는 5가지 였다.

글이 다 기억이 나질 않아서 찾아봐야 되나 하다가 말았다. 왜냐면 그때 5가지 중에서 프레임워크가 들어있었단 것을 알고 있었다. 그리고 그게 아마 중간 단계에서 좀 길게 이어져 있었던 것까지도 대강 기억은 나니깐…

어떤 특정한 기술을 보고 익히거나 그걸 보고 고민하거나 하는 시간은 분명 존재한다. 현업 개발자들이라고 해서 다를 건 없다. 그리고 그것들 중에서 제일 많은 시간을 보는 게 내가 보기엔 아무래도 프레임워크들 같다. 뭐 좀 보면 이것도 봐야되고 저것도 봐야 되고 하는 것에서는 프레임워크 따라갈 것이 없다. 나도 여러 프레임워크들에 치이고, 그것들을 구현하고 있는 기술들에 치이고 뭐 그래봤으니깐…

근데 이 때 빠지기 쉬운 오류가 있다면 아마 이런 것일 꺼다. “이 프레임워크에서는 이런 이런 생각을 해서 구현되었고 그 패턴, 그 동작에 대해서 주로 요구를 하고 있으니 우리도 그에 따라서 해야지.” 라고 하는 것이다. 나쁜 거 같은가? 좋은 거다. 일단은…

근데 그 프레임워크를 통해서 구현해야 하는 일부 기능에서는 구현을 했다. 문제는 그 후에도 자신들만의 로직, 자신들만의 개발 공간에도 이 내용을 절대신으로 믿고 따르는….. 다른 것에서는 팔랑귀가 되지 않으면서 유독 프레임워크 좀 더 건드려보고 재미 들리면 그 환경과 그 마인드가 최고라고 생각해서.. 되도 않는 형태로 개발하는 특정 집단의 개발자들이 존재한다.

사실 정답이 있는 문제가 아니다. 그렇게 해야만 되는 분야가 존재하기도 한다. 그렇지만, 일반 응용 프로그램에서는 정말 정답 있는 것이 아니다. 더 쉽고 확실하게 할 수 있다면 굳이 이용할 필요 없다고 하는 사람들도 존재한다. 그를 여러모로 이용하기 위해서 우리는 디자인 패턴을 배우고, 알고리즘에서 좀 더 좋은 방법을 찾기 위한 사고를 길러서 오는 그런 과정을 거쳐서 개발자가 되었다. 그런데도 불구하고 왜…ㅠㅠ

말도 안되는 방식으로 개발되었다고 해서 역정을 내는 다른 팀 맴버를 보면서, 대체 뭐가 문제인가 해서 봤다가 특정 개발 패턴에 휩쓸려서 남들이 이해 못할 그런 방식을 이용한 모 개발자를 보면서…. 솔직히 여러모로 맘이 교차하고 있다.

그래서 제목을 저렇게 적었다. 더 자유롭게 표현할 수 있는 것은 개발자의 역량인데도 불구하고 프레임워크에서 지원해 주지 않기 때문에 못한다, 메뉴얼에 없어서 못한다, 여기서는 이렇게 하는 것이다 라는 식으로 말하면서 프로그램 내부를 개판으로 만든….

내 인생에서는 좀 여러모로 이해 못할 개발자를 만난 듯 하다.

Xamarin…. 초보 개발자들한텐 접근 난이도 높아…ㅠㅠ

리엑트 네이티브, 자마린, 그리고 뭐 또 하나 있었는데….

크로스플랫폼 개발을 위해서 한번씩은 들어본 기술들이다. 근데 지금 규링이 있는 곳에서는 자마린 기반으로 크로스 플랫폼 클라이언트 개발을 하는 곳이라 자마린을 여러모로 건드리고 있다.

근데 이게 진짜 쉬운 게 아니라는 느낌을 확 받았다. 나 혼자 할 때에는 잘 몰랐는데, 내가 되게 당연시 하던 내용에서부터 엄청나게 막혀하는 이제 1년차 밖에 안된 녀석을 봤기 때문이다.

자마린이 리엑트보다 어려운 이유는 다른 게 아니다. 자마린 특유의 전용 환경에 대해서 다시 공부해야 한다. 혹여나 MFC를 쓰던 사람이 갑자기 WPF를 쓰게 되면 WPF 전용 환경에 대해서 다시 공부하게 되듯, 자마린 또한 쓸 수 있는 언어가 그냥 C#인 거랑 닷넷에서 지원해주게 된 것이라는 걸 제외하면 이 자체의 환경에 대해서 잘 알아야지 개발을 할 수 있다.

이걸 잘 알게 되는 예제는 이미 튜토리얼만 몇 번 해봐도 금방 알 수 있으니 별로 설명하고 싶진 않다. (글 쓰는 곳도 카페고…)

밑에 네이티브 환경에 신경쓰지 않고 이용하기 위해 크로스 플랫폼 개발을 시작했는데, 그 위에 올라가는 자마린 자체의 환경도 또 네이티브와 같은 수준으로 알아야 한다는 것이 여러모로 스트레스를 주는 듯 하다. 이것도 내 밑에 있는 1년차 개발자를 가지고 테스트 해본 결과다.

음….

근데 이걸 자유자재로 못다뤄주면 골아픈 일이 생기는 것이 요즘의 환경이긴 한데….. 난감하다.