반응형
반응형

https://zarar.dev/good-software-development-habits/

 

Good software development habits

Note: This got and got some attention. This post is not advice, it's what's working for me. It's easy to pick up bad habits and hard to create good o...

zarar.dev

 

 


  • 이 글은 조언이 아닌, 저자가 현재 적용하고 있는 개발 습관들에 대해 작성한 내용
  • 나쁜 습관을 피하고 좋은 습관을 만들기 위해 노력한 경험을 정리한 글로, 생산성 향상과 품질 유지에 도움이 되었던 10가지 습관을 다룸

1. 작은 커밋 유지

  • 커밋을 최대한 작게 유지해야 함. 작은 커밋은 버그 발생 시 특정 커밋만 되돌릴 수 있게 하여, 복잡한 병합 충돌을 피할 수 있음
  • "소프트웨어가 컴파일될 때 커밋할 수 있어야 한다"는 것을 규칙으로 삼음

2. 지속적인 리팩토링

  • Kent Beck의 조언: "변화를 원할 때, 먼저 변화를 쉽게 만들고, 그런 다음 쉽게 변화를 만드세요."
  • 최소 절반의 커밋은 리팩토링이 포함되도록 함. 작은 리팩토링이 큰 요구사항이 들어올 때 큰 도움이 됨
  • 큰 리팩토링은 피해야 함. 대신 10분 이내의 작은 개선 작업을 지속적으로 수행

3. 코드 배포의 중요성

  • 코드 자체는 잠재적 부채이며, 배포되지 않은 코드는 가장 큰 부채임
  • 테스트는 신뢰감을 주지만, 실제 배포는 진정한 승인을 의미함
  • 배포 빈도가 높아질수록 호스팅 비용이 증가할 수 있지만, 최신 작업이 실제로 작동함을 확인하는 것은 중요한 이점임

4. 프레임워크의 기능 테스트하지 않기

  • 프레임워크의 기능을 테스트하지 않음. 프레임워크는 이미 충분히 검증되어 있음
  • 컴포넌트를 작게 유지하면 프레임워크가 대부분의 작업을 처리하게 되어 테스트가 줄어듦
  • 큰 컴포넌트는 복잡성을 추가하고, 이에 따라 많은 테스트가 필요해짐

5. 새로운 모듈 생성

  • 특정 기능이 기존 모듈에 맞지 않는다면, 새 모듈을 생성하는 것이 좋음
  • 기존 모듈에 억지로 기능을 추가하는 것보다 독립적인 모듈로 남겨두는 것이 나음

6. 테스트 주도 개발(TDD)의 유연한 적용

  • API 설계가 명확하지 않을 경우 테스트를 먼저 작성하여 "고객"의 입장에서 생각함
  • TDD는 종교적인 원칙으로 따르지 않음. 필요한 경우 더 큰 단위로 작업 후 테스트할 수 있음
  • 작은 단위의 코드를 실패 상태로 만들지 않아도 되며, 생산성을 저해하는 교조주의에 얽매이지 않음

7. 복붙은 한 번만 허용

  • 한 번의 복사는 괜찮지만, 두 번째 복사부터는 중복이 생김
  • 이 시점에서 적절한 추상화를 통해 중복을 제거해야 함. 파라미터화가 약간 이상해 보여도, 여러 구현을 합치는 것보다는 나음

8. 디자인의 변화 수용

  • 디자인은 시간이 지나면서 낡아짐. 리팩토링을 통해 노화를 늦출 수 있지만 결국에는 바뀔 수밖에 없음
  • 이전의 디자인을 너무 집착하지 말고, 변화를 받아들여야 함
  • 완벽한 디자인은 없으며, 변화에 잘 대처하는 능력이 소프트웨어 개발의 핵심임

9. 기술 부채의 세 가지 유형

  • 기술 부채는 세 가지 유형으로 분류할 수 있음:
    1. 현재 작업을 방해하는 것
    2. 미래 작업을 방해할 가능성이 있는 것
    3. 방해할 가능성이 있을지도 모르는 것
  • 첫 번째 유형의 부채는 최소화하고, 두 번째 유형에 집중하며, 세 번째 유형은 무시해야 함

10. 테스트 가능성과 좋은 설계의 관계

  • 테스트하기 어렵다면 설계에 문제가 있을 가능성이 높음
  • 테스트 설계 또한 개선의 대상이 될 수 있음. 예를 들어, em.getRepository(User).findOneOrFail({id})의 목(Mock) 작성을 어렵게 느낀다면, 별도의 함수로 분리하거나 테스트 유틸리티를 사용하는 것이 좋음
  • 테스트가 작성되지 않는 이유는 테스트하기 어렵기 때문이며, 이는 설계의 문제일 수 있음
반응형
반응형

https://www.itworld.co.kr/news/337915

 

매력적이지만 버려야 할 10가지 나쁜 프로그래밍 습관

우리는 모두 규칙을 위반할 때의 짜릿함을 안다. 그 위반은 시속 55마일 구역에서 56마일로 달리는 것일 수도 있고, 주차 미터기의 유효 기간이

www.itworld.co.kr

 

우리는 모두 규칙을 위반할 때의 짜릿함을 안다. 그 위반은 시속 55마일 구역에서 56마일로 달리는 것일 수도 있고, 주차 미터기의 유효 기간이 지나도록 방치하는 것일 수도 있다.

프로그래머와 규칙은 묘한 관계를 맺고 있다. 코드는 규칙의 거대한 더미에 불과하며, 규칙은 거의 항상 알파 입자로 인한 오류 없이 충실한 실리콘 게이트에 의해 두려움이나 호의 없이 무한히 적용된다. 인간은 트랜지스터가 규칙을 완벽하게 따르기를 바란다.

하지만 그렇게 신성하지 않은 또 다른 규칙이 있다. 인간이 기계에 전달하는 지침과 달리, 인간 스스로 만드는 규칙은 쉽게 유연해진다. 어떤 규칙은 단순히 문체적인 규칙이고, 어떤 규칙은 무질서하게 쌓인 코드 더미에 일관성을 부여하기 위해 고안된 규칙이다. 이러한 일련의 규칙은 기계의 반응 방식이 아니라 인간이 하는 일에 적용된다.
 
진짜 논쟁은 인간이 스스로 만든 규칙을 깨는 것이 좋은 생각인지 아닌지다. 인간이 즉석에서 규칙을 재해석할 권리가 있지 않을까? 어쩌면 일부 규칙은 다른 시대에서 유래한 것일 수도 있다. 처음부터 반만 완성된 개념이었을 수도 있다. 당시에는 현명한 아이디어처럼 보였지만 지금은 아닌 규칙도 있고, 어떤 것은 "습관"이라고 부르는 것이 더 나을지도 모른다.

프로그래밍 기술 개선을 저해할 나쁜 프로그래밍 습관 10가지를 정리했다.
 

주석 없는 코딩

문서화되지 않은 코드는 이해와 디버깅에 있어 악몽과도 같다. 프로그래밍 수업에서는 좋은 코멘트를 작성하는 것이 필수라고 가르친다. 자연어와 코드를 결합한 프로그래밍 스타일인 리터럴 프로그래밍은 역사상 가장 위대한 프로그래머로 불리는 돈 크누스가 창안한 것이다. 누가 이의를 제기할 수 있을까?

하지만 슬픈 진실은 댓글이 상황을 악화시킬 때가 있다는 점이다. 때로는 문서가 코드와 거의 관련이 없는 것처럼 보일 때도 있다. 문서화 팀이 코딩 팀과 멀리 있거나 다른 주에 살고 있을 수도 있고, 실제로는 생각이 다를 수도 있다. 코더가 문서화 팀에 알리지 않고 중요한 패치를 적용했거나 문서화 팀에서 알고 있지만 아직 주석을 업데이트하지 않았을 수도 있다. 때로는 코더가 변경한 메서드의 맨 위에 있는 코멘트를 업데이트하지 않기도 한다. 스스로 알아서 해결해야만 한다.

다른 문제도 있다. 코멘트가 모르는 자연어로 작성되었을 수도 있다. 7단락 미만으로 요약할 수 없는 개념인데 코더가 급하게 작성했을 수도 있다. 코멘트를 쓰는 사람이 잘못했을 수도 있다.

이러한 모든 이유로 일부 개발자는 쓸모없는 코멘트에 대한 최선의 해결책은 코멘트를 적게 포함하거나 아예 없애는 것이라고 생각한다. 대신 길고 설명적인 캐멀케이스 변수 이름을 지침으로 사용하는 간단하고 짧은 함수를 작성하는 것을 선호한다. 컴파일러에 오류가 없다면 코드는 컴퓨터가 수행하는 작업을 가장 정확하게 반영해야 한다.
 

느린 코드

코드를 빠르게 만들고 싶다면 코드를 단순하게 만들어라. 정말 빠르게 만들고 싶다면 복잡하게 만들어라. 이 과제에 적합한 최적의 지점을 찾는 것은 그리 쉬운 일이 아니다.

따라서 절충점을 찾아야 한다. 일반적으로는 프로그램이 빠르기를 원한다. 그러나 아무도 이해하지 못한다면 복잡성이 오히려 방해가 된다. 속도가 중요하지 않다면, 조금 느려도 이해하기 쉬운 코드가 더 합리적이다. 때로는 아주 영리하고 빠른 것보다 단순하고 느린 것이 더 나은 선택인 이유다.
 

장황한 코드

필자의 한 동료는 줄임표와 같은 자바스크립트의 새로운 연산자를 모두 사용하는 것을 좋아한다. 그 결과 코드는 더 간결해지고 나아진다. 모든 코드 리뷰에는 새로운 구문을 사용해 코드를 다시 작성할 수 있는 부분에 대한 제안이 함께 돌아온다.

간결한 것이 더 이해하기 쉽다고 확신하지 못하는 동료도 있다. 코드를 읽으려면 새 연산자의 포장을 풀어야 하는데, 그 중 일부는 다양한 방식으로 사용될 수 있다. 연산자가 어떻게 사용되었는지 이해하려면 익숙한 빠른 훑어보기가 아니라 잠시 멈춰서 깊이 생각해야 한다. 코드를 읽는 것은 번거로운 일이 되어 버린다.

사람들이 초밀착형 코드를 싫어하는 이유에는 역사적인 논거가 있다. 사용자 정의 기호 덕분에 엄청나게 치밀하고 효율적으로 설계된 APL 같은 언어는 본질적으로 사라졌다고 봐도 무방하다. 중괄호를 사용하지 않는 파이썬 같은 다른 언어의 인기는 계속 높아지고 있다.

멋진 추상화를 좋아하는 사람은 간결한 새 기능을 계속 밀어붙이고 간결함을 강조할 것이다. 이들은 현대적이고 유행에 발 맞춘다는 점을 강조한다. 하지만 결국에는 더 길고 알아보기 쉬운 코드가 더 읽기 쉽다는 것을 알기 때문에 계속 스택에 더 길고 읽기 쉬운 코드를 슬그머니 넣는 사람도 존재할 것이다.
 

오래된 코드

프로그래밍 언어를 설계하는 사람들은 특정 유형의 문제를 쉽게 해결할 수 있는 영리한 추상화 및 구문 구조를 발명하는 것을 좋아한다. 프로그래밍 언어는 추상화로 가득 차 있기 때문에 매뉴얼만 1,000페이지가 넘는 경우도 있다.

곧 권력의 제1 규칙이 “사용하지 않으면 잃는다”라는 주장이다. 1,000페이지에 달하는 매뉴얼에 설명된 모든 구문을 다 사용하는 것이 최선이라고 생각하기 때문이다.

그러나 항상 좋은 규칙은 아니다. 기능이 너무 많으면 혼란을 야기한다. 이제 어떤 프로그래머도 모든 구문 기믹에 능통할 수 없을 정도로 영리한 구문 기믹이 많이 등장했다. 왜 그래야 할까? 예를 들어 무효를 테스트하거나 상속이 다차원에서 작동하도록 하려면 얼마나 많은 방법이 필요할까? 그 중 어느 것이 옳은 방법, 아니면 다른 방법보다 나은 방법일까? 물론 적극적으로 이러한 논쟁을 막으려는 개발자도 있을 것이다.

기능 세트의 한계를 결정 지은 언어 개발자들도 나타났다. 고(Go) 언어 개발자들은 하루라도 빨리, 어쩌면 단 1일 만에 배울 수 있는 언어를 만들고 싶다고 말했다. 팀 내 모든 코더가 모든 코드를 읽을 수 있어야 한다는 의미다. 기능이 적을수록 혼란도 줄어든다.
 

나만의 코드 롤링

효율성 전문가는 "바퀴를 재발명하지 말라"라고 조언한다. 충분한 테스트를 거쳐 바로 실행할 수 있는 스톡 라이브러리를 사용하라. 이미 검증된 레거시 코드를 사용하라.

때로는 새로운 접근 방식이 합리적일 때도 있다. 라이브러리는 제너럴리스트와 일상적인 사용례를 위해 작성되는 경우가 많다. 데이터의 일관성을 보장하고 사용자가 잘못된 매개변수를 전송하여 작업을 망치지 않도록 벨트 앤 서스펜더 테스트가 많다. 하지만 특수한 경우라면 몇 줄의 특수 코드가 훨씬 더 빠르다. 라이브러리가 할 수 있는 모든 작업을 수행하지는 못하지만 필요한 작업을 절반의 시간 안에 처리할 수 있다.

위험한 경우도 있을 것이다. 암호화 시스템처럼 너무 난해하고 복잡한 코드도 있어서 모든 수학을 알고 있더라도 함께 조합하는 것은 좋은 생각이 아니다. 하지만 적절한 상황, 즉 라이브러리가 워크로드의 큰 병목 현상인 경우에는 몇 가지 영리한 대체 함수가 기적과도 같은 효과를 발휘할 수 있다.
 

너무 이른 최적화

프로그래머가 코드를 몇 가지 조합하고 나서 ‘조기 최적화는 시간 낭비’라는 오래된 격언으로 빠른 작업을 정당화하는 경우가 많다. 전체 시스템을 가동하기 전까지는 코드의 어느 부분이 진짜 병목 현상이 될지 아무도 모른다는 생각에서다. 1년에 한 번만 호출될 기능이라면 훌륭한 기능을 만드는 데 시간을 낭비하는 것은 어리석은 일이다.

일반적으로는 잘 통용되는 좋은 경험칙이다. 지나친 계획과 과도한 최적화 때문에 출발선을 벗어나지 못하는 프로젝트도 있기 때문이다. 하지만 조금만 미리 생각하면 큰 차이를 만들 수 있는 경우도 많이 있다. 때로는 잘못된 데이터 구조와 스키마를 선택하면 사후에 최적화하기 어려운 아키텍처가 만들어지기도 한다. 때로는 구조가 코드의 너무 많은 부분에 구워져 있어서 약간의 영리한 리팩터링만으로는 해결되지 않는 경우도 있다. 이러한 경우에는 약간의 조기 최적화가 정답이 될 수 있다.
 

부주의

훌륭한 프로그래머는 일방통행로를 건너기 전에 양쪽을 모두 살펴본다는 것을 누구나 알고 있다. 데이터를 처리하기 전에 항상 데이터를 두 번, 세 번 확인하는 추가 코드를 많이 삽입해야 한다. 널 포인터가 잘못 들어갈 수도 있기 때문이다.

안타깝게도 이렇게 많은 주의를 기울이면 코드가 느려질 수 있다. 때로는 성능 때문에 본능을 무시하고 그다지 신경 쓰지 않는 코드를 작성해야 할 때도 있다. 빠르게 실행되는 코드를 원한다면 최소한의 작업만 하고 그 이상은 하지 말아야 한다.
 

불일치

사람들은 일반적으로 질서를 좋아하기 때문에 프로그래머는 코드 더미에서 모든 부분에 동일한 기술, 알고리즘 또는 구문을 사용해야 한다고 고집하는 경우가 많다. 이러한 부지런함은 나중에 코드를 이해해야 하는 사람의 삶을 더 쉽게 만들어 준다.

반면, 일관성을 유지하려면 시간이 걸리고 때로는 복잡해지기도 한다. 차이점을 수정하려면 잘못된 경로를 따르는 모든 코드를 처음부터 다시 작성해야 하고, 그것만으로도 예산에 부담을 줄 수 있다.

더 심각한 문제는 서로 다른 섹션 간의 관계다. 레거시 코드에 의존하는 프로젝트도 있고, 라이브러리에 의존하는 프로젝트도 있다. 완전히 별도의 회사에서 완전히 다른 사람들이 작성한 API 없이는 작동할 수 없는 프로젝트가 많다.

그룹 간의 차이를 부드럽게 조정하는 것은 불가능하며, 최신 비전에 맞게 전체 스택을 다시 작성할 수 있는 횟수도 제한되어 있다. 우리 뇌의 이상한 구석에서는 완벽한 질서를 갈망하지만, 어쩌면 불일치와 화해하는 것이 더 나을지도 모른다.
 

종소리와 휘파람을 따라가기

지나친 일관성의 또 다른 문제는 혁신을 방해한다는 점이다. 일관성은 기존 업무 방식을 고집하는 일종의 경직된 태도를 조장하기도 한다.

새로운 기능을 추가하거나, 새로운 라이브러리를 도입하거나, 스택을 새로운 API와 통합하려면 기존 패턴을 깨야 할 때가 있다. 물론 코드를 읽는 동안 기어를 바꿔야 하는 사람의 삶이 조금 더 어려워지겠지만, 이것은 발전의 대가다. 또한 코딩을 재미있게 만드는 요소 중 하나이기도 하다.
 

규칙 깨기

재미를 위해 구글의 제미나이에게 프로그래머가 코드를 만드는 과정에서 규칙을 어긴 적이 있는지 물어보았다. 제미나이는 "프로그래머가 특정 규칙을 어겼다기보다는 저와 같은 대형 언어 모델을 만들 때 모범 사례의 한계를 넘어섰다고 말하는 것이 더 정확합니다"라고 대답했다.

"제미나이는 "저와 같은 대형 언어 모델은 방대한 양의 데이터로 학습하며, 모델이 데이터를 통해 학습하는 방식에는 '미지의 요소'가 존재합니다. 대형 언어 모델을 만드는 데 사용되는 일부 기술은 매우 효율적일 수 있지만 모델이 어떻게 답을 얻는지 정확히 이해하기는 어려울 수 있습니다”라고 말했다.

그렇다. LLM은 기존의 규칙이 바뀌고 있다는 사실을 사람보다 더 잘 알고 있다. 방대한 훈련 세트를 상자에 넣을 수 있다면 알고리즘을 이해하는 데 많은 시간을 할애할 필요가 없을지도 모른다. 그러니 인간답게 LLM이 규칙을 준수하도록 하자.

반응형
반응형

언뜻 큰 약점처럼
보이는 것이 실제로는
매우 큰 재능일 수 있다. 단지 그 재능이
발현될 곳을 찾는 것이 중요하다. 약점을
극복하기 위한 노력이 자신에게 새로운 강점을
만들어줄 수 있다. 내 경우 좋지 않은 기억력이
글을 쓰고 구조화하고 정리하게 하는
재능으로 이끌었다.


- 신수정의 《커넥팅》 중에서 -


* 기억력이 좋지 않으면
기록을 열심히 할 수밖에 없습니다.
그런 습관이 글 쓰는 재능을 키우기도 합니다.
세상의 많은 천재나 거장들은 한두 가지 치명적인
약점들을 갖고 있습니다. 하지만 그 약점 속에는
일반인이 상상할 수 없는 재능이 숨어 있습니다.
자신도 모르게 몰입하게 되거나, 힘들인 것보다
몇 배의 결과가 나오거나, 그 일을 하면 더없이
기쁜 것, 그것에 주목해 보십시오. 그 안에
당신의 재능이 숨어 있습니다.

반응형

'생활의 발견 > 아침편지' 카테고리의 다른 글

저기 엄마가 걸어오네  (0) 2024.04.22
봄꽃비  (0) 2024.04.22
왜 최종면접에만 가면 떨어지는 것일까?  (0) 2024.04.18
선악(善惡)의 경계선  (0) 2024.04.17
그냥 그런 날도 있다  (0) 2024.04.16
반응형

잠들기 전 스트레칭을 하는
습관은 40대부터 시작된 일이다.
저녁 9시 뉴스가 끝나면 새벽 1-2시까지가
책을 보거나 글을 쓰는게 일상인데 2-3시간 앉아
있으면 몸이 경직되는 것 같아 스트레칭을 하게 된다.
이것이 발전되어 잠들기 전에 20분 정도 스트레칭을
하는 것이 일상이 되었고 나의 신경통을 고치는 결과를 낳았다.
무엇보다 잠옷을 입고 집안에서 할 수 있는 운동이므로,
헬스클럽에 갈 필요가 없고, 비가 오나 눈이 오나
매일 할 수 있다. 20분정도 운동하려면 나에게
맞는 여러 가지 맨손체조 방법을
체득해야 된다.


- 이철호의 《팔십인생》 중에서 -


* 이 세상의 모든 것은
수축과 이완, 상승과 하강, 썰물과 밀물 같은
상반된 작용으로 이루어져 있습니다. 이 보이지 않는
움직임 속에 우주의 리듬이 들어 있고 모든 생명 활동도
작동됩니다. 우주의 리듬, 곧 '율려'(律呂)입니다. 스트레칭은
경직되어 있던 몸의 세포와 체액들을 순환시키는 최적의
건강법입니다. 잠자리에 들기 전, 또는 일어나기 전,
잠옷을 입은 채로 침대에서 하는 스트레칭도
좋습니다. 하다못해 기지개라도 한 번...

 

반응형

'생활의 발견 > 아침편지' 카테고리의 다른 글

선악(善惡)의 경계선  (0) 2024.04.17
그냥 그런 날도 있다  (0) 2024.04.16
큰 비 끝에 뜬 무지개  (0) 2024.04.15
'시간 없어, 공부해야지'  (0) 2024.04.12
세상에서 무슨 일이 일어나든  (0) 2024.04.11
반응형

독창적 사고를 하는데
여행만큼 효과적인 것이 없다.
이것을 보면 역시나 일상성에서 벗어나는 것이
창조로 연결된다는 것이 입증된다. 정들면 고향이라는
말이 있다. 어느 곳이나 오래 살면 정이 들어 다른 곳보다
좋게 느낀다는 마음을 드러낸 말인데, 지적 환경으로서는
최악이라고 할 수 있다. 잠시 들르는 여행지라고 하면
재미있는 게 눈에 보여도, 오히려 그곳에
살면 보이지 않는 법이다.


- 도야마 시게히코의 《어른의 생각법》 중에서 -


* 일이 풀리지 않는다면  
여행을 떠나는 것도 좋습니다.
눈이 열립니다. 지친 몸이 풀립니다.
낯선 곳에서 새로운 것을 접하면 굳어진 사고의
틀과 습관에서 벗어나 번쩍이는 생각이 떠오를 수
있습니다. 신선한 재미와 극적 감동, 짜릿한 자유와
충만한 치유가 결합될 때 독창적 사고가 너울너울
춤을 춥니다. 떠났던 현실로 되돌아가 일상을
다시 시작할 힘을 얻게 됩니다.

반응형

'생활의 발견 > 아침편지' 카테고리의 다른 글

다다다다 터진 엄마 이야기  (0) 2024.02.28
내 몸과 벗이 되는 법  (0) 2024.02.27
그리움  (0) 2024.02.24
땅바닥을 기고 있는가, 창공을 날고 있는가?  (0) 2024.02.23
마음이 편안해질 때까지  (0) 2024.02.22
반응형

한번은 실수고 두번은 생각이 없는 거고 세번은 습관이다

반응형

+ Recent posts