'좋은 프로그래머'에 해당되는 글 3건

  1. 2012.07.01 좋은 엔지니어의 자세
  2. 2008.09.23 초심으로 돌아가서...
  3. 2008.09.07 좋은 프로그래머란 무엇일까? (4)

예전에 작성했던 글을 다시 보게 됐다.


좋은 프로그래머란 무엇일까?  (http://elky.tistory.com/174)


4년이 지난 지금 내가 생각하는 좋은 프로그래머란 무엇일까? (지금은 프로그래머란 표현보다 엔지니어란 표현을 좀 더 즐겨쓴다. 이것도 마인드의 변화겠지?)


우선 무엇보다 부드럽게 이야기하는 법, 대화 자세 이런건도 좋아졌고.


현실과 타협도 많이 한거 같다.



이전에는 책에서 보거나 느낀 최선을 실천하지 못하면 마음이 너무 불안했다.


그런데 그 실천이란 것을 주변 상황을 둘러보지 않고 하다보니, 이 상황에서 중요한 판단들을 놓쳐왔다.




예를 들면 원인 파악보다 중요한게 현재 상황에 대한 대처인 경우가 많다.


또한 패치가 얼마 남지 않은 상황에서 큰 설계상 오류에 대한 대처는 패치를 미루거나, 설계상 오류를 감안하고 최소한의 리스크로 서비스를 하는 것이 맞다.


완벽함을 추구한답시고 시간과 여건을 고려하지 않은 개발자 개인의 욕심이 안정성을 무너뜨려선 안되더라.




애초에 안정성이란 검증된만큼 이뤄지는 법이다.


우리는 스포츠 선수들 만큼은 아니지만, 평정심을 갖고 침착하게 상황을 바라볼 필요가 있다.




내가 생각하는 안정성을 위해 중요한 것은 무엇이냐?


바로 경험과 시스템이다.




좋은 경험을 많이 한다면 필요 수준의 기술은 갖추고 있는게 일반적이고.


경험을 바탕으로 퀄리티 높은 결과물을 만들기 위한 시스템을 갖추는 것이 너무나도 중요하다.


언제나 내가 생각하는 전제는 "사람은 언제나 실수한다"라는 것이다.


언제든 실수 할 수 있는 사람을 돕기 위해 시스템을 구축해야한다.



개발자 개개인의 역량은 그 시스템을 잘 구축하고 관리하기 위함이다.


많은 개발자의 실수는 섬세함과 부지런함의 부족이다.


섬세함의 부족이란 어떠한 목표만을 생각하다보니 운용상의 불편함을 만들거나, 운용이 편하지만 결합도가 높은 코드를 양산하는 등의 부족한 완성도를 말한다.


부지런함의 부족이란 갖춰 있는 시스템이 운용이 불편하던지 등의 이유로 적용을 미루는 것을 말한다.


시스템 운용이 불편하다면, 불편한 운용법을 효율적으로 고치는 것도 엔지니어의 자세다.


엔지니어는 철저히 결과로 말해야 하기 때문이다.




현재는 좋은 엔지니어는 상황에 맞는 최선의 판단을 해야 하며 이를 위해서는 일정 수준 이상의 기술과 시스템을 마련해야 된다는 것이 내 생각이다.


현 상황을 잘 개선할줄 아는 사람치고 빌드업을 못하는 사람은 없더라.


보통 난재는 빌드업과정보다, 잘못된 빌드업을 고치는 과정에서 더 많이 발생하기 때문이다.


잘못된 빌드업된 상황이 오래 유지되면 됐을수록 더 고치기 어려운 편이고.



자신이 만들어낸 것들에 대해서 좀 더 냉정히 바라보고, 그 완성도를 끌어올리는 일을 반복함으로써 조금 씩 더 좋은 엔지니어가 된다고 생각한다.


무언가를 그냥 만들어내는 것보다, 잘 만들어 내는 것을 요구 받아야 하고 (일정을 못지키더라도 잘 만들어내란 의미가 아닌 것은 알거라 믿는다.) 또한 그렇게 만들어 내야 한다.


그렇게 하는 사람이 바로 좋은 엔지니어가 아닌가 싶다.

Posted by 엘키 엘키

댓글을 달아 주세요

나는 처음 프로그래밍을 배울 때, 독학 기간이 길었던터라 하나 익히는데에 (특히 포인터) 꽤나 긴 시간이 필요했고, 어떤게 좋은지 나쁜지를 대부분 경험으로써 느껴왔다.

최초 설계에 구현을 어떻게든 맞추는 일도 해보고, 설계가 존재하지 않는 run and fix 프로그래밍도 해보고, 프로토타입을 많이 만들어놓고 베스트한걸 고르기도 해봤다.

다양한 방법을 경험하던중 안좋은 습관 하나가 붙었다. 너무 바쁘게 일을 하다보니 정리의 습관이 부족해 졌단 것이다.

내가 감당하기에 힘들만큼 버겁고, 많은 일이 주어지긴했지만, 그런 것들은 결국엔 다 핑계고 조급한 맘이 문제였다.

메모의 기술에 대한 서평에서 내가 메모를 기록과 증빙의 용도로 사용한다고 얘기했지만, 사실 내 머릿속에 있는 내용을 정리하는 과정으로도 많이 사용했다.

그 중에서도 로직을 순서도로 그리는 방법은 나에게 있어 특히 효율적이었는데, UML을 몰랐고, UML이 필요하지 않았던 혼자 프로그래밍해오던 나로썬 매우 유용한 방법이었다.



어느 덧 경력도 쌓이고 일도 적응이 되자, 머릿속과 코드 만으로 로직을 이해할 수 있다고 자신했으나... 간결하게 코드를 작성해왔다고 한들, 클래스와 클래스 간의 결합도가 높아져버리면 대책없었다. 복잡도도 복잡도고, 변경이 잦은 경우 어느 선을 넘어서 복잡도가 지나치게 커지면 일관성 있는 코드를 유지하기가 힘들어졌다.

이럴때 로직을 작게 나누고 (작게 나누어지지 않는다면 결합도가 높다는 뜻이니 이 결합도를 낮추는 작업을 먼저하고), 작게 나누어진 로직에 순서도를 그렸더니 코딩이 너무 편해졌다. 순서도를 현재 로직대로 업데이트 하며 관리했더니 코드를 보지 않고도 처리 방식을 훨씬 빨리 찾고 이해할 수 있었다.

처음 프로그래밍을 배우고, 게임을 만들때의 방식을 되찾은 것이다. 어린 시절 즐겁게 프로그래밍을 처음 배웠을 때 하나 하나 알아가던 때와 같은 기분이 들어 신이 난건 덤이었다.



이런 순서도만으로 프로그램 내에 수립된 가정을 이해하긴 힘들것 같다고? 나도 그렇게 생각한다. 그래서 생각한 것이 바로 클래스 관계도다. 사실 데이터 베이스의 경우에도 ER다이어그램이라 불리는 스키마 관계도가 일반적으로 통용되고 있다.

순서도는 세부 로직별로 작성되어야 되고, 클래스 관계도는 전체적인 상관관계를 그려놓는것이 좋다. 그에 있어 기준도 명확히 기록해둔다면 해당 관계도 하나만 보고도 이해하기 쉽다.

여기서 또 중요한것이 어느정도 선까지 클래스 관계도를 디테일하게 작성할 것이냐인데... 내 생각엔 멤버 하나 하나 자세하게 나열하는 것보다는 객체와 객체간의 큰 가정(has a 관계나, is a 관계, 또는 패턴을 적용한 경우 패턴 이름 등)을 기록해둠으로써 새로운 가정이 기존 가정을 깨드리지 않도록 하는 것이 중요하다고 본다.

XP에서 강조하듯 죽은 문서는 필요 없지만, 문서화 자체가 필요없는 것은 아니다. 자신이 생각하기에 업무 능률을 높여줄 수 있는 문서화는 반드시 필요하다.

서비스에서 사실상 가장 중요한 DB작업의 경우 여러 단계의 점검 이슈 검토 작업을 거친다. 사실 처음엔 그게 굉장히 번거로웠고, 단순 반복 작업이라 느껴져 귀찮기도 했는데, 각 단계를 거치면서 사소한 실수는 많이 줄어들었다.

코드의 내용을 그대로 담는다면 중복이고 번거로운 반복 작업이 되겠지만, 클래스 관계도는 중복 조차 아니다. 요약이다. 이 얼마나 즐거운가! 우리가 싫어하는 중복이 아니란 말이다!

물론 코드 작성시마다 검토하고 수정해야 되는 번거로움 정도는 있지만, 잘 생각해보면 그 한번의 과정을 통해 잘못된 코드를 양산할 확률이 급감한다.



내가 너무 늦게 깨닳은 것인지 모르지만, 벼는 익을수록 고개를 숙이고, 프로그래머는 경력이 쌓일 수록 더 꼼꼼해져야 한다고 본다.

조금만 더 부지런해지자.

'BlahBlah' 카테고리의 다른 글

새 해를 맞이하며~  (0) 2009.01.05
강컴 2008년 9월 서평왕 당선~  (4) 2008.11.24
초심으로 돌아가서...  (0) 2008.09.23
좋은 프로그래머란 무엇일까?  (4) 2008.09.07
단점 고치기에 대한 썰  (0) 2008.09.06
프로그래밍은 상상이다 예약중  (1) 2008.08.26
Posted by 엘키 엘키

댓글을 달아 주세요

어느 날 문득, '좋은 프로그래머'란 어떤 의미일까라는 생각을 하게 됐다.

내가 떠올린 좋은 프로그래머를 분류 해보자면 '실력은 보통이지만 같이 일하기 좋은 프로그래머', '굉장히 능력이 뛰어난 슈퍼 프로그래머', '매우 꼼꼼해서 실수를 거의 하지 않는 프로그래머' 정도로 나뉘어졌다.

생각해보니 나는 어떤 부류에도 포함이 되지 않았다.



현재 내가 생각하고 있는 좋은 코드와 개발 방향에 대한 의지가 너무 강해 같이 일하기 좋은 사람이 되지도 못했고, 슈퍼 프로그래머도 아니며, 실수 빈도도 낮지 않다.

상황이 이렇다보니 나 자신에 대한 확신을 갖기 어려워지고 있었다.

슈퍼 프로그래머는 타고 나는 것이니 패스하고 나머지 두개를 생각해봤다.

내가 같이 일하기 좋은 프로그래머가 되려한다면 어떻게 해야 할것인가?

내가 생각하는 옳은 방식을 버리고 다른 사람이 하자는 방식대로 따라 가기만 하면 일하기 좋은 프로그래머가 되는 것일까? 그건 아닌거 같았다.

그러면 과연 내 어떤 점이 문제였을까 고민을 해봤더니, 토론을 원하지만 토론을 원하는거 같지 않은 대화 습관이 문제였다.

내가 생각하고 있는것과 다른 이야기로 흘러갈 때 어투가 강해지고 목소리가 커지는 태도는 다른 사람들이 보기에 화가 난것 처럼 보였고, 대화하기 꺼려지게끔 만들었더라.

내 의지를 관철 시키기 위해 침착한 말투로 다른 사람을 잘 설득할 수 있다면, 내 의견을 관철 시킬 수도 있고, 일하기 좋은 프로그래머가 될 수도 있겠단 생각이 들었다.



남은 한가지 요건인 '꼼꼼한 프로그래머'가 되기 위해서 해야 할일은 무엇일까?


이 부분에서는 일정 부분 좋은 습관과 좋은 환경이 상당 부분 해결해 줄 수 있겠단 생각을 했다.

잘 찾아볼수 있게 할일을 리스트업하고, 우선 순위를 메기는 것만으로도 해야 될일을 놓치는 빈도가 적어질 수 있기 때문이다.

또한 규칙(예를 들면 코딩 인벤션과 같은 것들)을 세우고 그 것을 습관적으로 지킨다면 실수할 여지가 분명히 줄어들었다.

여기서 중요한 것은, 이미 적용중인 규칙을 바꾸려 할 때는 그 규칙이 적용된 모든 것을 바꾸거나, 바꾸지 않거나 해야 된다는 것이다.

규칙을 변경할 때 소급적용한다는 것은 안하니만 못한 결과를 낳았다. 다양한 규칙이 적용된 상태는 규칙이 없는 무질서한 상태나 마찬가지기 때문이다.



지금의 나를 돌아봤을 때 20살때 꿈꿔온 목표했던 것보다 많은 것이 이루어졌다.

그렇다보니 할 수 있구나 하는 자신감도 갖게 됐지만, 욕심이 더 해져 더 큰 목표와 많은 것을 갖게 되기도 했다.
 
20살 때 세웠던 내 목표중 하나는 '기술적으로 뛰어나고, 좋은 게임을 만드는 것'이었다.

하지만 지금은 좋은 사람, 좋은 프로그래머가 되고 싶은 목표로 바뀌었다. 내 꿈이 언제 또 변할지 모르지만, 내 변하고 있는 생각이 옳다고 믿고 최선을 다하면, 결국은 해피 엔딩이 되지 않을까 하는 추상적인 꿈을 꾸며 노력하는 수밖에 없는것 같다.

'BlahBlah' 카테고리의 다른 글

강컴 2008년 9월 서평왕 당선~  (4) 2008.11.24
초심으로 돌아가서...  (0) 2008.09.23
좋은 프로그래머란 무엇일까?  (4) 2008.09.07
단점 고치기에 대한 썰  (0) 2008.09.06
프로그래밍은 상상이다 예약중  (1) 2008.08.26
Software Development MEME  (0) 2008.07.14
Posted by 엘키 엘키

댓글을 달아 주세요

  1. BlogIcon J 2008.09.08 23:59  댓글주소  수정/삭제  댓글쓰기

    객관적으로 분석할 수 있는 프로그래머가 되는 것도 참 중요하다는 생각이 드네요. 동료를 설득시키고자 한다면, 자신의 생각과 경험을 표현할 수 있는 객관적인 자료를 들수 있어야 한다고 생각해요. 단지 감으로 혹은 믿음만으로는 타인의 마음을 동요시키기 어렵기 때문이겠죠.. :)

    • Favicon of http://elky.tistory.com BlogIcon 엘키 2008.09.09 21:30  댓글주소  수정/삭제

      네 말씀하신대로 대부분의 상황에서는 내 경험상 이러이러하니 이렇게 하자보다, 객관적인 자료가 더 효과가 좋겠죠.

      이따금 타협이 필요할 때는 (양쪽다 합리적인 경우나, 양쪽다 비합리적인 경우라고 생각합니다) 그런 경우에는 서로를 이해하려는 오픈 마인드를 가져야 한단 생각이 들더라군요. ^^

  2. Favicon of http://www.productionkim.com BlogIcon productionkim 2008.09.09 04:33  댓글주소  수정/삭제  댓글쓰기

    "내가 만든 프로그램을 사용할 사람의 입장을 생각하는 프로그래머가...좋은 프로그래머가 아닐까요?" 이것이 전부는 아니더라도 좋은프로그래머를 정의하는데 큰 부분을 차지하지 않을까 생각합니다 ^__^

    • Favicon of http://elky.tistory.com BlogIcon 엘키 2008.09.09 21:31  댓글주소  수정/삭제

      그렇죠...^^ 그래서 사용자 스토리와 같은 부분이 주목 받고 있나봅니다.

      사용자의 입장을 이해한다면, 개발자 본인으로써도 좀 더 성공적인 프로그램이 될 가능성을 높이는 것이니 좋단 생각에 저도 공감이 가네요 ^^ 좋은 의견 감사드려요

이전버튼 1 이전버튼

블로그 이미지
Software Engineer
엘키

공지사항

Yesterday31
Today29
Total1,605,483

달력

 « |  » 2020.8
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

글 보관함