최적화 해결- 직면한 문제를 빠르게 해결- 구조가 망가지고 유지보수성이 극도로 떨어짐- 스케일업과 유사한 개념이라 한계가 명백함- 망가진 구조로 인해 근본적인 성능 개선이 불가능해지기도 함구조적 해결- 최적화의 반대최적화는 항상 마지막 순간에, 정확한 포인트를 짚어서 최소 단위로만 수행할 것
캐시의 경우 어떻게 적용하느냐에 따라 다른데, 백붕이들이 쓰는 수준이면 대부분 최적화 해결임
데이터 유형 고려, 캐시 정책 고려, 비용 고려, 글로벌 or 로컬 이런거 고려하라는 말이야?
그렇다기보다는.. 백붕이들 캐시는 기술적인 어필이 전혀 안된다고 말해주고 싶었음
감사합니다
개발에서 최적화 이야기는 분야를 막론하고 나오는듯 ㅋㅋ "섣부른 최적화가 만악의 근원이다."
최적화 코드나 구조 보면 탄식이 절로 나온다 이런씹..
이론적으론 정론인데 쉽지않음 은행권만봐도 구조적해결 논하면 "책임"이. . 단순한학교 팀프젝에선 불가능 도전하는 서비스기업의 가훈같음 - dc App
은행권도 버티고 버티다가 구조적 해결 하고 있잖아 코어 레벨은 어떤지 잘 모르겠다만
팀프젝은 언급도 하지마라.. 그건 개발이 아니야 애들 소꿉장난만도 못함, 소꿉장난은 즐겁기라도 하니까
구조적 해결은 이론이나 정론이 아니라 해야만 하는 일이야
글킨한데 혹시 은행쪽 코드본적있음?. . 레거시/틀딱보수형 환장의 콜라보레이션인데 - dc App
몇번 봤는데 참담하긴 하더라 여튼간에 필요하면 해야함 안하면 다른 대가를 치뤄야하는데, 언젠가는 대가로도 해결 불가능한 시점이 오게 됨
진짜 너같이 대기업서비스직 애들이 너무 부러움.. 시대가 바뀌어도 적응해나갈것같음 si/은행은 좋다고해도 파리목숨 "개발자무덤"임 - dc App
무작정 구조적 해결책 찾는거도 오버엔지니어링이라서 최적 지점을 찾아내는게 능력인듯 근데 공부하는 입장에선 그럴 필요가 없다보니 약간 억지 부려봤음