저도 동의합니다. 서비스에서 DB가 필요 이상으로 중요하게 여겨지는 경우가 종종있고, 때로는 정규화 깨지면 큰일이 나는 것처럼 과도한? 설계 투자를 하기도 하죠.
DB를 쓰지 말자가 아니라, 왜 쓰는 거였고 서비스의 근본이란 과연 무엇인가 정도로 생각을 리프레시하는 정도로만 봐도 충분히 좋을 듯요.
항상 밸런스가 중요하죠.
비유가 적절한 것 같습니다. 제 프로젝트도 사람의 Intent 와 Snapshot 2가지로만 사실상 구성되거든요.
결국은 사람의 의도 (eg. 키 입력, 마우스 클릭) 을 어떻게 계산하고 어떤 의미를 가지게 만들것인가가 제 프로젝트가 나아가야할 길이라고 생각하고 있었습니다.
네 말씀하신 의견이 공감됩니다.
코드로 대체할 수 없는 부분이 분명히 있습니다.
그런 의미에서 좀 다르게 설명해보자면, 가독성 높은 코드는 문서를 생산할 필요가 없도록 만든다는 얘기를 하고 싶었습니다.
소프트웨어가 장기화 되며 쌓이는 문서 또한 개발자에게 인지 부하를 주니까요. 코드와 문서를 번갈아 보는 작업을 줄이자는데 핵심이 있습니다.
온전히 코드만 남길 수는 없다고 생각합니다.
맥락과 처한 상황에 따라 다를 수 있다고 생각드네요.
댓글 주셔서 감사합니다.
반론을 조심스럽게 전달하자면, 저는 코드는 문서를 대신할 수 없다고 봅니다. 아직 programming language는 자연어의 풍부한 표현력과 전달력을 가지지 못했고, 현실적으로는 그 많은 코드를 언제 다 읽습니까?
문서를 대신할 수 있는 코드를 가져보는 것은 희망이고 바램이지만, 오르지 못할 바벨탑이지요.
차라리 OOAD를 열심히 하는게 더 나아보입니다.
저도 동의합니다. 서비스에서 DB가 필요 이상으로 중요하게 여겨지는 경우가 종종있고, 때로는 정규화 깨지면 큰일이 나는 것처럼 과도한? 설계 투자를 하기도 하죠.
DB를 쓰지 말자가 아니라, 왜 쓰는 거였고 서비스의 근본이란 과연 무엇인가 정도로 생각을 리프레시하는 정도로만 봐도 충분히 좋을 듯요.
항상 밸런스가 중요하죠.
국내에서 애자일은 개발자들 일정 압박용 그 이싱도 이하도 아님
엇.. 좋네요. 지금까지 없어서 바로가기 앱으로만 만들어서 썼눈뎃
그러게요. 사업 초기에 이용자가 많지 않을 때는 DB 구매하거나 복잡하게 하지 말고 기본 파일 I/O만으로 사업의 안착까지 갈 수도 있다는 제안 정도로 보면 되는데.
답글의 보석들은 덤이구요.
저는 아주 좋은 글이라고 생각합니다. 특히 저런 '숫자' 가 들어있는 자료는 귀하죠. 우리가 만드는코드, 가져다 쓰는 기술스택이 어떤 오버헤드가 있는지 '대충의 감이라도 있는' 개발자 보기가 쉽지 않은 시대인데, 즐겁게 읽었습니다.
비유가 적절한 것 같습니다. 제 프로젝트도 사람의 Intent 와 Snapshot 2가지로만 사실상 구성되거든요.
결국은 사람의 의도 (eg. 키 입력, 마우스 클릭) 을 어떻게 계산하고 어떤 의미를 가지게 만들것인가가 제 프로젝트가 나아가야할 길이라고 생각하고 있었습니다.
출시한거 보고 글쓰러 오려했는데 벌써 작성해주셨군요.
성능이 얼마나 될지 궁금합니다.
기존코드가 남아있으니 어떤 구현인지는 직접 확인이 가능합니다.
https://gitlab.com/sebuls/libhwp
개념은 매력적인데,경험상 이런 이상적인 시도 중에서 성공적이었던 적이 별로 없어서..
아직까지는 Feedly 가 AI기능도 좋고 가장 무난하지 싶네요.
rip
켄트백의 익스트림 프로그래밍, 제프 서덜랜드의 스크럼 등등 대부분의 애자일 기법 책에 기본적으로 나오는 내용입니다. 유저 스토리를 보셔도 됩니다. 대부분의 사람들이 애자일의 근간이 고객 요구사항에 대한 빠른 적응을 위한 짧은 스프린트와 데모 라는 것을 잘 모르더군요.
네 말씀하신 의견이 공감됩니다.
코드로 대체할 수 없는 부분이 분명히 있습니다.
그런 의미에서 좀 다르게 설명해보자면, 가독성 높은 코드는 문서를 생산할 필요가 없도록 만든다는 얘기를 하고 싶었습니다.
소프트웨어가 장기화 되며 쌓이는 문서 또한 개발자에게 인지 부하를 주니까요. 코드와 문서를 번갈아 보는 작업을 줄이자는데 핵심이 있습니다.
온전히 코드만 남길 수는 없다고 생각합니다.
맥락과 처한 상황에 따라 다를 수 있다고 생각드네요.
댓글 주셔서 감사합니다.
걍 생각의 전환 정도로 읽히는데 다들 민감하시네요
저도 한번 시도해봐야겠네요
좋은정보 감사합니다.
반론을 조심스럽게 전달하자면, 저는 코드는 문서를 대신할 수 없다고 봅니다. 아직 programming language는 자연어의 풍부한 표현력과 전달력을 가지지 못했고, 현실적으로는 그 많은 코드를 언제 다 읽습니까?
문서를 대신할 수 있는 코드를 가져보는 것은 희망이고 바램이지만, 오르지 못할 바벨탑이지요.
차라리 OOAD를 열심히 하는게 더 나아보입니다.
spec 자체를 애자일하게 쓴다는게 뭔가요?
애초에 애자일이 뭔지 모르겠다는게 저글의 핵심입니다. 애자일은 이런 특성이 있고, 이러저러하게 해야한다고만 떠들어댔지 정작 이게 애자일 방법론으로 만들어진 제품이다라고 제시해주는 글은 지금까지 보지못했습니다. 선언문을 봐도 아리송하더군요. 한번 보여주시면 어떨까요.
BckHWP. 엑셀 VBA 자동화
https://m.blog.naver.com/husky81/222045248589
gemini cli 는 좀 작동만 제대로 되면 좋겠는데 맨날 뻗어있음
요즘들어서 이런 경우를 더 자주봅니다