디지털 공학 개론 보면서 느끼는게 아래로 내려갈수록
당장 하드웨어 칩 만들면서 게이트가 복잡해져도
비용 줄이는 거 최적화
이런거 우선시 하고 올라갈수록 당장 사용자의 요청이나
상황에 따라 바뀔 염려가 있으니 최적화보다는 직관성을
우선시하는 경향이 있는듯
어차피 해당 기능에 대해서 잘 돌아가면 되니까
이후로 판매할 때는 크게 염려가 없으니...
근데 그게 sw에서는 어느 정도까지인지는 잘 모르겠음
자주 바뀔 가능성이 있으면 무조건 직관성이고
아닌 경우는 아직 잘 모르겠음
당장 하드웨어 칩 만들면서 게이트가 복잡해져도
비용 줄이는 거 최적화
이런거 우선시 하고 올라갈수록 당장 사용자의 요청이나
상황에 따라 바뀔 염려가 있으니 최적화보다는 직관성을
우선시하는 경향이 있는듯
어차피 해당 기능에 대해서 잘 돌아가면 되니까
이후로 판매할 때는 크게 염려가 없으니...
근데 그게 sw에서는 어느 정도까지인지는 잘 모르겠음
자주 바뀔 가능성이 있으면 무조건 직관성이고
아닌 경우는 아직 잘 모르겠음
둘이 vs 하는 관계가 아님 보통
알고리즘이랑 db짜는 것만 해도 vs관계는 맞음.. 당장 db에 있는 거 새로 속성이랑 안의 값 생성하면 그거 쿼리 생성 비용 들어가는데 db로 select 쿼리로 줄일 수 있음 제일 좋은 예시는 프갤에서 id를 주만번호(몇 번 본적있을 꺼임)vs id컬럼(김영한 강사님은 새로 만드는 걸 선호하시는 듯) 만들기 이건듯
work right fast 순
fast가 아니라 performance
작동 안하는 가독성과 가독성 없는 퍼포먼스는 의미없음
작동 안하는 가독성이라도 명시적으로 더 좋으면 그걸 선호할 수 있음 아직 컴파일러를 안 배워서 if문만 썼을 때 이게 완전히 최적화가 되는 지는 모르겠는데 배민에서 말하는 것 중 하나가 bad case가 있으면 바로 if문을 거쳐 o(1)로 리턴 하는게 명시적으로 좋다는 사실 이건 결국에 원래는 안거치는 조건문을 거쳐서 거의없겠지만 비용 소모가 일어남
근데 이렇게 하면 훨씬 명시적으로 복잡한 if문을 구조적으로 단순화해서 보일 수 있음 이게 님이 말하는 그 예시를 깨는 사례아님?
not work 라는건 잘 못된 동작을 뜻하는거임 즉 너는 퍼포먼스를 말하고 있는거임
저렇게 bad case가 있음 바로 리턴해라는 내용은 우태코 후기 블로그에서 봤는데 안보이네 암튼 그럼
잘 모르겠음 명시적인게 퍼포먼스보다 중요하다는 거임?
work는 프로그래머의 목적대로 동작하는가지 너는 쭉 성능 얘길했고
사실 수치 차이가 얼만가를 봐야할지 아니면 명시적인걸 우세하게봐야 할 지도 모르겠음 이제 막 동부 시작한 입장이라 그런듯
나중에 확장 가능성을 고려한 work에 대해서 하는 말임 설계를 완벽히했고 그에 따라 했어도 실제로는 그에 따라 잘 해결되었지만 정부 법이 바뀐다던가 같은 건 어떻게 알음?
정답은 없음 확장 가능한 구조가 옳을지 지금 당장의 간단한 구조가 옳은지 현실의 요구는 디지털이 아니니까 프로그래머의 의도와 목적에 따라 다름
직관성이지 ㅇㅅㅇ 암만 최적화해바라 ㅇㅅㅇ 하드웨어가 더 빨리 발전하는데 ㅇㅅㅇ
그래서 내려갈 수록 최적화를 우선시 하는 경향이 있다고 말해도 되는 것 같기도 함
아 ㅇㅅㅇ 그건 맞지 ㅇㅅㅇ m1칩 암만 복잡하게 짜바라 ㅇㅅㅇ 내가 유지보수할거 아닌데 먼상관이고 ㅇㅅㅇ