Notice
Recent Posts
Recent Comments
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- LastModified
- brotli
- Kotlin
- 클래스레벨밸리데이션
- etag
- cross parameter
- 지뢰찾기
- jsr303
- 이렇게살아야되나자괴감이
- 랜선아미안해
- 개미수열
- kotliln
- 지수반등
- 알고리즘
- 리얼월드HTTP
- jsr380
- 알게뭐냐
- i18n
- 스프링
- Spring
- cache-control
- 워드프레스
- 코드스피츠
- HTTP
- 브로틀리
Archives
- Today
- Total
취미개발 블로그와 마음수양
코드스피츠 84 #3 본문
어떤 알고리즘은 이런 식으로 저런식을 짰는데 코드배치를 비슷한 모양으로 함
어떤 곳은 for문, 어떤 곳은 재귀
일관성있는 설계를 위하여 둘다 함수에 담을 수 있다.
학습비용 효과
1) 고인물효과 (조직전체의 폐쇄를 일으킴)
2) 비용이 늘어난다 (시간=비용)
3) 수정, 확장을 시키지 않으려는 탄성이 일어난다.
그 부분을 폐쇄하고 격리하게 된 다음에 다른 코드를 만들게 됨.
고인물 코드를 if 로 격리시키고 나머지에 내 코드를 적게 됨
==> 제품의 수명이 짧아짐
해마다 차세대..!
멋있는 설계 = 학습비용을 줄이는 설계
하나만 익숙해지면 나머지를 똑같이 적용할 수 있다?
학습해야하는 비용을 최소한 줄이는 것
일관성있는 설계 => 제너릭한 설계, 알고리즘에 제너릭한. 코드의 배치를 할 수 있는
일관성있는 설계를 하다보면 그 일관성에 부합하지 않는 놈이 튀어나오기 마련
일관성이 있다면 기능을 줄여나갈 수밖에 없다
우리가 나아가야할 길?
알고리즘을 설계로 바꿔서 일반성을 획득해보는 것
설계모듈간의 일관성을 획득하는 것해서 컴포넌트화
컴포넌트화를 하여 시스템
나중에 시스템간의 프로그래밍
'개발관련 잡다 > 스터디_세미나이야기' 카테고리의 다른 글
코드스피츠 83 오브젝트 #1-2 (0) | 2020.07.25 |
---|---|
코드스피츠 오브젝트 83 #1 (0) | 2020.07.25 |
공마 스터디 #2 (0) | 2019.09.26 |
코드스피츠 84 #4 (0) | 2019.09.24 |
코드스피츠 S84 #2 (0) | 2019.09.10 |