'Software Engineering/Develop Theory'에 해당되는 글 9건

  1. 2015.08.21 실용주의 프로그래머
  2. 2014.10.17 조엘 온 소프트웨어 - 손쉬운 기능명세 작성법
  3. 2012.07.01 좋은 엔지니어의 자세
  4. 2012.06.25 좋은 관리자의 요건
  5. 2010.08.20 좋은 프로그램 개발을 위한 원칙 (2)
  6. 2008.02.24 조엘 테스트
  7. 2008.02.13 코드 읽기에 대해서 (2)
  8. 2008.01.20 80-20 법칙

명언

가장 큰 약점은 약점을 보일 것에 대한 두려움이다 - 보쉬에우리는 종종 뭔가 나아지게 하려다가 괜찮은 것 마저 망친다 - 리어왕


지식에 대한 투자가 언제나 최고의 이윤을 낸다 - 벤자민 프랭클린

당신이 가진 생각이 딱 하나밖에 없다면 그것만큼 위험한 것은 없다 - 에밀 사르티에

언어의 한계가 곧 자기 세계의 한계다 - 루트비히 비트겐슈타인

진보라는 것은 변화와는 거리가 멀고 오히려 기억에 의존한다. 과거를 기억하지 못하는 사람은 과거를 반복할 운명이다 - 조지 산타야나

참으로 고통스러운 일입니다. 자신이 겪는 어려움을 보고는 알게 되죠. 다른 누가 만든 게 아니고 바로 자신이 문제를 만들었다는 걸. 소포클래스(아이아스)

상식과 정직만큼 사람을 놀라게 하는 것은 없다 - 랄프 왈도 에머슨

자기 비난에는 사치성이 있다. 우리가 자신을 비난할때, 다른 사람은 우리를 비난할 권리가 없다고 우리는 느낀다. - 오스카 와일드

좋은 울타리는 좋은 이웃을 만든다 - 로버트 프로스트

아무리 뛰어난 천재라도 세부사항에 집착하면 그 재능이 발휘되지 않는 법이다 - 레바의 8번째 법칙

주변을 둘러보니 변화와 쇠퇴뿐 - 라이트 “함께 하소서”

완성이라는 것은 더 이상 더할 것이 없을 때가 아니라, 더 이상 뺄 것이 없을 때 얻게 되는 것이다. - 생텍쥐페리

가끔은 망설이는 자가 재난을 모면한다 - 제임스 써버

생각없이 행할 수 있는 중요한 작업의 수가 늘어남에 따라 문명은 발전한다. - 알프레드 노스 화이트헤드

아무리 흐른 먹물이라도 가장 훌륭한 기억력보다 낫다 - 중국속담

Tip
자신의 기술에 관심과 애정을 가져라

자신의 일에 대해서 생각하면서 일하라

어설픈 변명을 만들지 말고 대안을 제시하라

깨진 창문을 내버려두지 말라

변화의 촉매가 되라

큰 그림을 기억하라

품질을 요구사항으로 만들어라

지식 포트폴리오에 주기적으로 투자하라

읽고 듣는 것을 비판적으로 분석하라

무엇을 말하는가와 어떻게 말하는가 모두 중요하다

DRY(Don’t Repeat Yourself) - 반복하지 마라

재사용하기 쉽게 만들어라

관련 없는 것들 간에 서로 영향이 없도록 하라

최종 결정이란 없다 (불변하는 결정은 없다)

목표물을 찾기 위해 예광탄을 써라(지금 무엇을 얼마만큼 하고 있는지를 확인하라)

프로토타입을 통해 학습하라

문제 도메인에 가깝게 프로그래밍하라

추정을 통해 놀람을 피하라

코드와 함께 일정도 반복하며 조정하라

지식을 일반 텍스트로 저장하라

명령어 셀의 힘을 사용하라

하나의 에디터를 잘 사용하라

언제나 소스코드 관리 시스템을 사용하라

비난 대신 문제를 해결하라

디버깅을 할 때 당황하지 마라

“Select”는 망가지지 않았다. (컴퓨터는 고장나지 않는다. 내가 코드를 잘못짠거다)

가정하지 마라. 증명하라

텍스트 처리 언어를 하나 익혀라

코드를 작성하는 코드를 작성하라

완벽한 소프트웨어는 만들 수 없다

계약에 따른 설계를 하라

일찍 작동을 멈추게 하라 (문제가 있을 때)

단정문을 사용해서 불가능한 상황을 예방하라

예외는 예외적인 문제에 사용하라

시작한 것은 끝내라

모듈간의 결합도를 최소화하라

통합하지말고 설정하라 (Config 기능을 따루 둬라. 코드에 상수를 박아넣지 마라)

코드에는 추상화를, 메타데이터에는 세부 내용을

작업흐름 분석을 통해 동시성을 개선하라

서비스를 사용해서 설계하라

언제나 동시성을 고려해서 설계하라

모델에서 뷰를 분리하라

칠판(개별 컴포넌트들이 모두 참조할 수 있는 공용 메모리공간)을 사용해 작업흐름을 조율하라

우연에 맡기는 프로그래밍을 하지 말라

여러분의 알고리즘 차수를 조율하라 (알고리즘의 대략적인 소요 시간을 예측하라)

여러분의 추정을 테스트하라

일찍 리펙터링하고, 자주 리펙터링하라

테스트를 염두에 두고 설계하라

소프트웨어를 테스트하라. 그렇지 않으면 사용자가 테스트하게 될 것이다

자신이 이해하지 못하는 마법사가 만들어준 코드는 사용하지 말라

요구사항을 수집하지 말고, 채굴하라

사용자처럼 생각하기 위해 사용자와 함께 일하라

구체적인 것보다 추상적인 것이 더 오래간다

프로젝트 용어사전을 사용하라 (팀원들 간에 공통의 용어를 사용할 수 있도록 하라 - 의사소통의 효율을 위해)

생각의 틀을 벗어나지 말고, 틀을 찾아라

준비가 되었을 때 시작하라

어떤 일들은 설명하기보다 실제로 하는 것이 더 쉽다

형식적 방법의 노예가 되지 마라

비싼 도구가 더 좋은 설계를 낳지는 않는다

팀을 기능 중심으로 조직하라

수작업 절차를 사용하지 말라

일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라

모든 테스트를 통과하기 전엔 코딩이 다 끝난 것이 아니다

파괴자(고의로 만들어놓은 버그)를 써서 테스트를 테스트하라

코드 커버리지보다 상태 커버리지를 테스트하라 (테스트 할때, 개별 코드에 빠지지 말고 전체적인 맥락을 놓치지마라)

버그는 한번만 잡아라 (같은 버그가 계속 나와서는 안된다)

한국어도 하나의 프로그래밍 언어인것 처럼 다뤄라 (문서를 작성할때도 코드를 쓰는 것처럼)

문서가 애초부터 전체의 일부가 되게 하라. 나중에 집어넣으려고 하지 마라

사용자의 기대를 부드럽게 넘어서라 (사용자의 기대를 제대로 이해하고, 그것보다 약간 더 좋게 만들면 좋아한다)

자신의 작품에 서명하라 (스스로에게 부끄럽지 않은 코드를 만들어라)


Posted by 엘키 엘키

댓글을 달아 주세요

모든 사람들이 명세서 작업을 해야한다고 생각은 하지만, 아무도 명세서 작업을 하지 않습니다.

왜 명세서 작업을 하지 않을까요?

명세서 작업단계를 건너뛰면 시간을 절약할 수 있다고 말합니다.

이런 사람들은 명세서 작성 작업이 NASA에서 우주 왕복선을 만드는 공학도나 큰 규모의 보험회사 직원에게나 필요한 사치쯤으로 치부합니다.

명세서 작업을 하지 않는 관례는 소프트웨어 프로젝트에서 가장 크고 불필요한 위험 요인을 짊어지는 행동입니다. 이는 등에 옷가지만을 걸친 다음에 날기를 기대하며 모하비 사막을 건너려고 출발하는 것만큼이나 바보스럽습니다.

명세서 작업을 생략하고 바로 코드 작성으로 뛰어드는 프로그래머나 소프트웨어 개발자는 스스로를 허리춤에서 순식간에 총을 뽑는 멋진 총잡이라고 생각하는 경향이 있습니다.

하지만 결코 그렇지 않으며, 이런 개발자일수록 놀라 자빠질 정도로 생산성이 낮습니다.

즉, 형편 없는 코드를 작성하거나 조잡한 소프트웨어를 양산하며, 결국 전혀 쓸데없느 ㄴ거대한 위험을 자초해 프로젝트를 위협합니다.


기능 명세 - FUNCTIONAL SPECIFICATION

완전히 사용자 관점에서 제품이 어떻게 동작할지를 기술합니다. 어떻게 구현했는지는 신경도 쓰지 않습니다. 기능에 대해 이야기하고, 화면, 메뉴, 대화상자와 같은 사용자 인터페이스 부품을 명세합니다.


기술 명세 - TECHNICAL SPECIFICATION

프로그램 내부 구현을 기술합니다. 자료구조와 관계형 데이터베이스 모델과 프로그래밍 언어, 도구, 알고리즘 선택과 같은 항목을 다룹니다.



 * 좋은 기능 명세에 대한 아이디어!


1. 면책 조항 

방어적인 내용 "이 명세는 완벽하지 않습니다." 시간이 흘러 명세가 완벽하게 되면 다음과 같이 면책 조항을 바꿀 수 있다. "제가 알기로는 이 명세는 거의 완벽합니다. 하지만 무언가 빠뜨렸을 경우에는 제게 말씀해주세요"


2. 저자

명세는 1명이 전담해서 작성해야만 합니다. 큰 제품일 경우라면, 여러 부문으로 쪼갠 다음에 각각을 개인에게 할당해서 독자적으로 명세하게 합니다. 어떤 회사는 명세에 이름을 넣어서 개인의 공로를 인정하는 관례를 이기적인 행동이나 팀워크를 해치는 일이라고 생각합니다.

하지만 이는 허튼 소리입니다. 사람들은 자신이 명세한 사항에 대해 책임감과 소유의식을 느껴야 합니다. 명세에서 무언가 잘못되면, 이를 수정할 책임이 있는 명세서 소유자를 지정해야 하며 이 사람 이름이 바로 명세서에 찍혀 있어야 합니다.


3. 시나리오

생생하고 현실적인 시나리오를 만들수록, 실 사용자나 가상으로 창조한 사용자 모두를 위한 제품을 더 잘 만들 수 있습니다.


4. 회피목표

팀 단위로 제품을 만들 때 없으면 못살겠다는 이유만으로 실제든 상상이든 간에 각자 좋아하는 상큼한 기능을 넣으려는 경향이 있습니다. 이렇게 불필요한 기능을 쳐내는 가장 좋은 방법으로 명세에 회피목표 항목을 추가합니다. 


5. 개괄

개괄은 명세를 위한 목차와 유사합니다. 개괄은 간단한 흐름도이거나 광범위한 아키텍쳐 관점에서 본 토론일 수도 있습니다. 모든 사람이 숲을 보기 위해 목차를 읽습니다. 이렇게 해야 나무도 의미가 있을 것입니다.


6. 세부사항

웹 타입 서비스를 설계할 때 세부사항을 정리하는  좋은 방법은, 모든 가능한 화면에 기준이 되는 이름을 붙인 다음, 너무나도 자세해 못 견딜 만큼 따분한 세부사항을 매 화면마다 기술하는 장을 제공하는 겁니다.

세부사항은 기능 명세에서 가장 중요한 핵심입니다.


7. 미해결 문제

명세 첫 버전에 미해결 문제를 남겨놓아도 나쁘지 않습니다. 문제점을 쉽게 찾을 수 있도록 특별한 스타일을 적용해서 표시를 하고, 적당한 대안이 있으면 이를 논의합니다. 프로그래머가 작업을 시작할 무렵에 이런 모든 미해결 사항들을 짚어놔야 합니다.

단순히 프로그래머가 모든 쉬운 작업부터 시작하도록 내 버려두고, 나중에 미 해결 문제를 푸는 방법이 옳다고 생각할지도 모르겠습니다. 하지만, 이는 잘못된 생각입니다. 프로그래머가 코드를 구현하려고 시도할 무렵에 나타나는 새로운 문제점과 씨름하는 과정에서 또 다른 문제점이 나타날 것이며, 당신이 미리 알고 있었으며, 예전에 끝냇어야 하는 미해결 문제 역시 그대로 남아 있을 것입니다. 설상 가상으로 난이도 높은 문제를 해결하는 과정이 코드를 작성하는 방법에도 상당한 영향을 미칠지도 모르겠습니다.


8. 방주 (SIDE NOTE)

명세를 작성하는 동안에 프로그래머, 테스터 , 마케팅팀원, 기술집필가와 같은 다양한 청중이 있음을 기억해야 합니다. 명세를 작성할 때 단지 특정 그룹에만 유용한 활자화한 사실을 고려하면 좋겠습니다. 예를 들어 프로그래머를 위해 기술적으로 유용한 몇가지 세부 사항을 기술하는 메시지를 '기술노트'항목으로 구분해서 기록할 수 있습니다. 마케팅 팀원은 이런 메시지를 무시하지만 프로그래머는 이런 메시지를 탐독합니다.


9. 명세는 지속적으로 개정해야 합니다.

주기적으로 개정하여 현실을 반영합니다. 명세는 항상 제품이 동작하는 원리를 최대로 반영하는 그림자 입니다. 명세는 단지 제품이 코드완료시점에서 굳어질 따름입니다.



 * 명세서 작성 팁


1. 재미있게 씁시다.

여러분이 작성한 명세가 유쾌하며 재미있고 읽기 쉽다는 이유로 당신을 얕보는 회사에 근무한다면, 어서 다른 회사를 찾는 게 낫습니다.


2. 명세를 쓰는 작업은 머리가 돌아가도록 코드를 쓰는 작업과 유사하다.

문서를 소개하려는 대상층을 감안하고, 단계마다 그 사람이 무엇을 이해하길 바라는지 먼저 상각해보세요. 문장마다 독자가 내용을 깊이 이해했을지, 문맥의 의미는 파악했는지 스스로 되물어보십시오. 그래야 명세를 읽는 높으신 분께서 수많은 기술 용어에 압도당해 처음부터 문서 읽기를 포기하거나 멈추지 않게 될 겁니다.


3. 최대한 단순하게 작성하라.

쉬운 문장으로 작성하는 방식은 왠지 프로답지 않다는 생각에, 형식적이며 현학적인 언어를 남발하지는 마세요. 가능한 가장 쉬운 언어를 사용해야 합니다. 실제화면 보다 명세서를 더 효과적으로 개선하는 방법은 없습니다. 그림은 천마디 말보다 낫습니다.


4. 여러차례에 걸쳐 검토하고 다시 읽어라.


5. 표준양식은 해롭다고 간주한다.

모든 명세는 일정한 형식을 갖춰야 한다라는 생각은 버리십시오.


-출처 - 조엘 온 소프트웨어 - 

Posted by 엘키 엘키

댓글을 달아 주세요

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


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


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


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


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



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


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




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


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


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




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


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




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


바로 경험과 시스템이다.




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


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


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


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



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


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


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


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


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


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




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


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


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


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



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


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


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

Posted by 엘키 엘키

댓글을 달아 주세요

언젠가 관리자란 주제로 글을 쓰리라 마음 먹었것만, 나를 관리해주시는 관리자도 몇 되지 않으셨었고 (지금도 많진 않지만), 그 분들과 이야기를 나누거나 회고하기에는 재직중인 상황이라 미루다 미루다 이제서야 쓰게 됐다.


사실 좋은 관리자=좋은회사라는 공식이 어느정도 성립한다고 생각이 든다.


그렇게 생각하는 데에는 여러가지 이유가 있다.


1. 소통이 적은 회사 일 수록 직속 상사내지는 관리자와의 대화가 업무 진행에 8할 이상을 차지하기 때문.
- 안타깝게도 대부분의 회사가 이렇다는 게 현실

2. 결정권은 관리자에게 있으므로 해당 파트 내지는 팀의 방향성도 관리자에게서 나오기 때문
- 물론 그 보다 위에 계신 분들이 방향성을 잡는 경우도 있지만, 그 마저도 관리자의 역량과 영향이 있다고 볼 수 있음


기본적으로 좋은 관리자라는 의미는 상당히 애매하다.


대부분의 관리자 (내지는 대다수의 사람이) 들은 장점만 갖고 있지 않기 때문이다. (정말 정분이 날 만큼 친해서 자신에게 모든걸 맞춰주는 관리자를 만나신 분이 있다면 연락주시길...)


내가 경험해보거나 듣게 된 관리자들의 성향은 대부분 몇가지로 분류 할 수 있다.


1. 배려파
- 기본적으로 좋은게 좋은거라고 개개인의 성향을 존중하고, 판단을 존중한다.
- 장점 : 대부분의 이야기를 들어주고, 이해해주려 노력한다.
- 단점 : 의견 제시를 하는 사람이 여러명일 때 본인이 혼란에 빠지곤 한다. 또한 판단이 늦는 경우가 많다.

2. 현실파
- 회사의 입장이 최우선이다. 회사에 피해가 덜 가는 것을 우선적으로 생각한다.
- 장점 : 회사 입장에서 판단하기 때문에 결과적으로 회사와 갈등이 빚어지지 않는다.
- 단점 : 개개인의 판단이 무시되기도 하기에, 현실파 관리자와 개인간의 갈등이 빚어지곤 한다.

3. 독단파
- 자신의 판단이 최우선이다. 나를 따르라~~
- 장점 : 명확한 신념이 있기에 추진이 빠르다. 또한 설득을 위한 시간 소모가 없다.
- 단점 : 독단파 관리자의 판단이 잘못 됐을 때에도 여지가 없다. 다른 의견을 가진 사람들 사이에서 불만이 터져나오고 이를 수습하기도 어렵다.


개인적으로는 이 세가지 스타일의 관리자를 다 만나봤으니... 뭐 결과적으로 좋은 경험이었단 생각이 든다.


어느 한 스타일의 관리자를 꼽기에는 상황에 따라 필요한 관리자 타입이 너무나도 다르다.


물론 나도 레아님이 말씀하신 빠른 의사 결정이 최고의 관리자라는 얘기(http://rhea1st.tistory.com/489)에는 어느정도 공감한다.


결과적으로는 나는 생각이 조금은 다른데, 빠른 의사 결정이 다는 아닌 경우가 많다는 점이다.



나는 서버 개발자기에 긴급한 상황을 다른 파트보다 조금 더 많이 맞이한다고 생각이 든다. (이로 인해 줄어든 내 수명은... 누가 늘려줄려나...?)


당연히 나의 관리자도 이런 긴급한 상황을 자주 맞이하게 되는 것이고.


이런 상황에서 빠른 의사 결정이 물론 중요하다.


허나 결정이 이럴 때만 이루어 지는가??


그렇지 않다는게 중요하다.




워낙에 팀 분위기도 좋고, 게임 방향성도 모두가 공감해서 트러블 슈트만 제대로 해내면 하하호호 할 수 있는 팀이라면 얼마나 좋겠는가?


하지만 현실적으로 그런 팀은 많지 않고, 풀어내야 할 문제가 기술적인 이슈나 서비스적인 이슈만이 아니라는게 중요하다.




사실 사람간의 갈등이 제일 어렵다. 이 문제까지 관리자가 해결하는 건 쉬운일이 아니라 생각하고, 경험해본 적이 없기에 넘어가보자.



내가 가장 많이 겪었던, 그리고 들어온 고충은 바로 업무 스타일과 퀄리티 문제다.


업무 스타일에 따라 서비스 시에 발생할 문제를 매우 많이 해결 할 수 있고, 퀄리티란 단순히 테스트 해보니 잘 되요가 아닌 함축적인 의미를 내포하기 때문이다.


서로 다른 환경에서 일해오던 여러 사람이 팀으로 묶였을 때, 다른 업무 스타일과 퀄리티를 조율 할 수 있는 관리자가 좋은 관리자라 생각한다.




사실 이걸 해낸 관리자는 거의 없고, 앞으로도 많지 않을 것이다.


대부분의 경우는 혼란 상태에 빠져서 좌초되거나, 혼란 상태로 연명하며, 그런 상황은 대게 독단파 한명이 팀을 휘어 잡을 때가 되서야 나름의 평온함을 찾게 된다. (억눌러서 얻은 평화는 오래가지 않는법...예외가 있다면 독단파가 뛰어난 자라면 좋은 결과를 내기도 한다.)


아주 운이 좋을 경우 업무 스타일이 흡사한 사람들끼리 평온한 팀이 만들어지기도 하고.


하지만 대게는 나쁜 팀으로 남는다. (혹은 여러가지 상황으로 인하야 버티거나)




이렇듯 현실적으로 어려운 이야기를 왜 하느냐고?


그런 어려운 일을 해내야 좋은 팀이 된다는 이야기를 해야 하는 것이다.


좋은 관리자가 되는게 그만큼 어렵지만, 그만큼 좋은 팀이라는 보상이 온다.



그런 관리자를 앞으로의 개발자 인생에서 만날 수 있을까? (내가 그런 관리자가 될 수 있을까란 질문은 던지지 않는걸로. 나는 관리자가 아닌 개발자로써 계속 남고 싶으니까)


뭐 꼭 내가 만나지 못하더라도, 그런 관리자가 하나라도 더 있었으면 하는 바램에서 이 글을 남겨본다.

Posted by 엘키 엘키

댓글을 달아 주세요

Open-Close 원칙
- 객체는 수정(modification)에는 닫혀있고(Close), 확장(extension)에는 열려있어야(Open) 한다.

중복을 제거하라
- 같은 기능을 하는 코드를 묶어, 중복을 제거하자는 원칙.

메소드 간소화
- 메소드는 두가지 일을 하게 만들지 말아라.
- 메소드의 이름에서 벗어나는 일을 하지 말라.
- 큰 규모의 행동이 필요하다면, 더 큰 범위의 단어로 메소드 명을 짓고, 그 큰 동작을 완성 시키기 위한 메소드의 연결만으로 구현하라.

직교성
- 클래스 끼리의 의존도를 낮춰, 해당 클래스가 변화를 국소화 시키고, 재사용을 촉진하라

가역성
- 변하지 않는 것은 없다. 코드도, 설계도 변화에 대비하라.

계약에 의한 설계
- 이 함수에 들어오기 전에 기대하는 선행 조건(Pre-Condition)과, 함수 종료시에 보장해야 될 후행 조건(Post-Condition)을 검사하라.

80-20법칙
- 20% 코드가 수행시간의 80%를 차지한다.
- 20%의 자주 불리는 코드를 수행하면 80% 이상의 성능향상을 거둘 수 있다.

'Software Engineering > Develop Theory' 카테고리의 다른 글

좋은 엔지니어의 자세  (0) 2012.07.01
좋은 관리자의 요건  (0) 2012.06.25
좋은 프로그램 개발을 위한 원칙  (2) 2010.08.20
조엘 테스트  (0) 2008.02.24
코드 읽기에 대해서  (2) 2008.02.13
80-20 법칙  (0) 2008.01.20
Posted by 엘키 엘키

댓글을 달아 주세요

  1. Favicon of http://blog.naver.com/ BlogIcon 너굴도령 2008.03.02 07:32  댓글주소  수정/삭제  댓글쓰기

    담아가겠습니다. ^^ 감사합니다.

1.      소스코드 관리 시스템을 사용하고 있습니까?

2.      한방에 빌드를 만들어 낼 수 있습니까?

3.      일일 빌드를 하고 있습니까?

4.     버그 추적 시스템을 운영하고 있습니까?

5.      코드를 새로 작성하기 전에 버그를 수정합니까?

6.      일정을 업데이트 하고 있습니까?

7.      명세서를 작성하고 있습니까?

8.      조용한 작업환경에서 일하고 있습니까?

9.      경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?

10.  테스터를 별도로 두고 있습니까?

11.  프로그래머 채용 인터뷰 때 코딩 테스트를 합니까?

12.  무작위 사용편의성 테스트를 수행하고 있습니까?


'Software Engineering > Develop Theory' 카테고리의 다른 글

좋은 관리자의 요건  (0) 2012.06.25
좋은 프로그램 개발을 위한 원칙  (2) 2010.08.20
조엘 테스트  (0) 2008.02.24
코드 읽기에 대해서  (2) 2008.02.13
80-20 법칙  (0) 2008.01.20
프로그래머 십계명  (0) 2008.01.11
Posted by 엘키 엘키

댓글을 달아 주세요

문득 코드를 작성하던 중 이런 생각이 들었다.

"과연 지금 내가 작성한 이 코드가 분석하기 쉬운 코드일까?"

생각해보면 아마추어 일때를 제외하고는 새 코드 작성보다 다른 사람의 코드 분석하는 시간이 더 잦았고, 새 코드를 작성하더라도 다른 코드와 어울려야 했기 때문에 코드 분석은 늘 필요했다.

심지어 내 코드를 분석해야 되는 일도 잦았다. 기억력에는 한계가 있고, 시스템의 전체적인 이해도는 높을 수록 좋겠지만 세세한 코드 하나 하나가 하는 일까지 외울 필요는 없다고 생각한다.

그렇기에 내 코드를 내가 몇달이 지나고, 심지어 몇년 후에 봤을 때도 읽기 쉽고 유지보수하기 쉬운 코드를 만들기 위해 노력해야 한다.

그래서 우리는 디자인 패턴, 리팩토링 등을 통해서 좋은 코드를 만들기 위해 노력하고, 표기 법을 만들었으며, 코딩 규약도 만들었다.

그런데 왜 코드 읽는 법에 대한 논의는 없을까?
코드를 잘 "작성"하는 것과, 코드를 잘 "읽는" 것과는 엄연히 다르다.

그런데 많은 사람들이 코드를 잘 작성하는 사람이 코드를 잘 읽을 것이라고 생각한다.
과연 그럴까?

분명히 좋은 코드가 무엇인지 이해하고 있는 사람은, 그렇지 않은 사람보다 코드를 잘 읽을 것이다.

코드 읽기와, 코드 작성은 별개로 보아야 한다. 또한 코드 읽기를 잘하기 위해선 단순한 코드 작성이 아닌, 유지보수하기 쉬운 코드 작성이 되어야한다.

좋은 코드가 무엇인지 이해하려면 경험이 필요하고, 그런 경험을 해오며 코드 읽기에 대한 노하우도 쌓였을 것이라 이미 코드 읽기에 대한 노하우가 있을 것이다.

그렇지 않은 사람들은 코드 읽기를 어떻게 해야 할까?

내가 생각하는 코드 읽기 방법이다.

1. 특정 클래스를 따로 떼어내서 사용해본다. 
만약 해당 클래스가 다른 클래스와의 결합도가 높다면, 별개의 모듈로 동작할 수 있도록 해체 작업을 해본다. 실패하더라도 그 과정에서 해당 모듈에 대한 이해도가 높아졌을 것이다.


2. 이미 완성된 프로그램을 돌려본다. 그리고 디버깅을 통해서 해당 코드가, 프로그램에 어떤 영향을 주는지 살펴본다.
 이 방법의 단점은, 나무는 볼 수 있지만 숲을 볼 수는 없다는 것이다.

3. UML등을 이용해서, 클래스 구조도를 그려본다.
그리고 각 클래스 별로 따로 분석한다. 1번과 2번 방법을 적절히 사용하면, 코드 분석이 좀 더 이로울 것이다.

이 글이 이제 갓 프로그래밍을 시작한 초보 개발자나, 코드 작성은 자신 있지만, 아직 다른 사람의 코드를 분석하고 수정하는 것은 어렵기만한 분들에게 코드 읽기에 대한 도움이 될 수 있는 글이 되었으면 좋겠다.

'Software Engineering > Develop Theory' 카테고리의 다른 글

좋은 관리자의 요건  (0) 2012.06.25
좋은 프로그램 개발을 위한 원칙  (2) 2010.08.20
조엘 테스트  (0) 2008.02.24
코드 읽기에 대해서  (2) 2008.02.13
80-20 법칙  (0) 2008.01.20
프로그래머 십계명  (0) 2008.01.11
Posted by 엘키 엘키

댓글을 달아 주세요

  1. Favicon of http://toc21c.tistory.com BlogIcon 21세기 2008.03.27 10:50  댓글주소  수정/삭제  댓글쓰기

    요즘 회사에서 코드리딩, 코드분석 작업을 하고 신입 프로그래머입니다.
    시간이 지남에 따라 "내가 과연 잘 읽고, 이해하고 있는 걸까?" 라는 물음에 점점 자신이없어지더라구요. 특히나 2.방법이 가장 많이 하고 있지 않나 생각됩니다. 그리고 숲을 볼 수 없다는 것에 공감가네요. 3.방법이 전 UML을 배워야한다는 부담감에(해야되긴 하지만) 제 자신이 미루고 있는 듯 합니다.
    적극적으로 한번 뜯어봐야겠네요 :)

    • Favicon of https://elky.tistory.com BlogIcon 엘키 엘키 2008.04.06 00:20 신고  댓글주소  수정/삭제

      뭐랄까 코드 분석은 프로그래머의 영원한 숙제가 아닐까 싶어요.

      개인 작업의 시대는 지난지 오래고, 자신의 코드만 유지보수 하게 된다는 보장은 없으니까요.

      C++은 특히나 제약이 별로 없는 언어이기 때문에 다양한 스타일이 존재하니 코드 분석이 어려운거 같아요.

      이런 부분에 대한 고찰이 계속되면 코드 분석에 대한 체계도 마련되지 않을까 싶습니다.

      이 부분에 관심 있으시면 Code Reading 이라는 책 한번 읽어보시는 것도 괜찮지 않을까 싶네요 ^^

80%의 효과는 20%의 노력으로 얻어진다는 법칙으로 중요한 일에 노력을 집중해 성공적인 삶을 살 수 있다는 것이다.

이 법칙을 프로그래밍에서 적용해보자면,
- 코드 중에 20%가, 수행시간의 80%를 차지한다.
- 프로그램의 리소스의 80%는 전체 실행 코드의 약 20%만이 사용한다.
- 메모리의 80%는 실행 코드의 약 20%만이 사용한다.
- 디스크 접근 회수의 80%는 실행 코드의 20%가 접근한 회수다.
- 프로그램 유지보수에 들어가는 수고의 80%는 실행 코드의 20%에 집중된다.


여기서 80-20법칙의 진정한 의미는 아무 곳이나 골라잡고 효율을 향상시키려고 애쓰는 것은 별 도움이 안된다는 의미를 갖고 있다.

'Software Engineering > Develop Theory' 카테고리의 다른 글

좋은 관리자의 요건  (0) 2012.06.25
좋은 프로그램 개발을 위한 원칙  (2) 2010.08.20
조엘 테스트  (0) 2008.02.24
코드 읽기에 대해서  (2) 2008.02.13
80-20 법칙  (0) 2008.01.20
프로그래머 십계명  (0) 2008.01.11
Posted by 엘키 엘키
 TAG 80-20법칙

댓글을 달아 주세요

이전버튼 1 2 이전버튼

블로그 이미지
Software Engineer
엘키

공지사항

Yesterday31
Today27
Total1,605,481

달력

 « |  » 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          

글 보관함