아침소리 (211.♡.103.115)
2026년 6월 19일 PM 05:56
코딩이 어느정도 양일지 알아보니...
12만줄이라네요.
이 정도 크기에서 기능 추가, 디버깅 등에서 에러 없이 바로바로 수정됩니다.
역시 처음 설계가 중요하긴 한거라 느껴지네요.
한번 구축하고 나니 부가기능들이 마구 붙네요..
댓글 (4)
-
삶삶은다모앙
06.19 · 61.♡.223.158
-
아아무개00
06.19 · 178.♡.142.161
기능별로 도메인별로 디렉토리를 나눠서 코드를 재사용 가능하게 리팩터링하는 과정을 한번 거치셔야겠군요.
개인적인 룰으론 대충.. 파일당 300줄이 넘어가면 뭔가 산으로 가고 있다고 생각합니다. 그정도가 되면 지금 바라보고 있는 영역이 어떤 기능을 하는지 한눈에 가늠이 안되기 시작합니다.
- 아
아침소리
→ 아무개00 작성자 06.19 · 211.♡.103.115
덧글 주신거 보고 내역 다시 보니 이미 대충 그렇게 구분이 되었네요. 파일당 300줄 안될거 같구요.. 도메인별로, 기능별로도 나누면서 작업이 되기는 했습니다.
아마 전사 릴리즈 전에 리팩토링 한번 할거는 같습니다.
그리고 어차피 이 프로젝트는 사람이 코드, 시스템 분석 안한다는게 목표입니다. 내부 개발자들도 다 안하는걸로 동의...
- 아
아무개00
→ 아침소리 06.19 · 178.♡.142.161
그리고 어차피 이 프로젝트는 사람이 코드, 시스템 분석 안한다는게 목표입니다. 내부 개발자들도 다 안하는걸로 동의...
우어.. 쉽지 않은 결정으로 보이는데요ㅎㅎㅎ행운을 빕니다!
배틀테스트를 거친 라이브러리는 적극적으로 쓰는것도 괜찮은것같아요. 클로드가 유독 지시를 명확히 안주면or 라이브러리의 이름을 명확하게 제시하지 않으면 바퀴를 재창조하는 짓을 자주 해서 코드의 양이 기하급수적으로 늘어나는 경우를 꽤 자주 봅니다. 오너쉽이 있는 코드가 그렇지 않은 코드보다 더 가치있다는 내부 선호 사항이 있는듯 하더라구요. 개인적으론 똑똑하고 열정 넘치는 분들이 테스트케이스까지 잔뜩 만들어놓은걸 더 선호합니다ㅎㅎㅎ
댓글을 작성하려면 이 필요합니다.
뭔말인지 모르지만... CBO 만들어 달라고 졸랐던 시절 반성합니다.
https://youtu.be/wCIrPJ6SBl4?si=CMRAA9BqZSD4SCwC