많은 프로그래머들이 2:8 이론을 들어 최적화된 코드를 작성할 필요가 없다고 주장하곤 한다.
극히 일부의 코드가 전체 성능하락의 주요 원인이라는 얘기다.
틀린 얘긴 아니다.
그러나 바꿔 얘기하면 80%의 코드가 최적화되어 있다면 20%의 성능하락 요인을 수정하지 않아도 된다는 뜻도 된다.
게다가 전체적인 코드의 최적화여부는 날 잡아서 하는 최적화에 달려있지 않다. 습관과 기초지식에 달려있다. 기초지식을 잘 습득하고 습관만 잘 들이면 날 잡아서 최적화하지 않아도 언제나 최적화된 코드를 얻을 수 있다.
2:8 이론을 주장하는 사람들에게 이 문구를 들려주고 싶다.
“어떻게 프로젝트가 1년이나 늦어질 수 있지? 매일 하루씩 늦어지면 된다.” – ‘맨먼스머신’에서
전체의 80% 코드에서 조금씩 성능을 깍아먹으면 그게 다 합쳐졌을땐 상당히 큰 손실이 된다.
그리고 더 큰 문제는 이건 날 잡아서 수정할 수 없다는거다.
yuchi's development 
Wow
레퍼런스카운트로 인한 초보적 메모리누수 비교적 잘잡아내서 ,
방심하고 있다가 , 다시 터졌는데 코드자체의 양이 많아지니까 누수체크함수 써도 어디가 문젠지 모르겠고,
더욱이 어디서 문제코드를 적었는지 찾을생각 하면 그냥 그 시간들여 찾은다한들 남은게 뭐가있나 밖에 생각안들어
그냥 조금씩가더라도 체크해줘야 할 부분에서 체크하면서 , 쌓아올리는 방향으로 처음부터 다시 만드는게
옳은 방향이겠구나
싶은 생각이드는 오늘 에서 이글을 다시보니 그때보다 와닿게 느껴집니다.
사실 따라치는데도 누수가 발생한거라, 그냥 첫시작부터 포인트만 쏙 빼내서 자기가 직접 만들어보는걸로 생각을
굳혔습니다. 1번은 따라해보고 할려했는데..
좋아요좋아요
ref count에도 헛점이 존재하고 사람 실수에 의해서 문제가 생길수 있죠. 이런 방식에서 문제가 생기면 완전 수동관리할때보다 디버깅은 더 힘듭니다. 그래도 일단 누수나 힙커럽션이 발생했다면 다시 짜기로 결심했다하더라도 원인은 찾아내서 해결하고 기록을 남겨두는게 좋습니다.
좋아요좋아요