Continued Learning: The Beauty of Maintenance - Kent Beck - DDD Europe 2020
ฝัง
- เผยแพร่เมื่อ 11 ต.ค. 2020
- Domain-Driven Design Europe 2020
dddeurope.com - / ddd_eu
Organised by Aardling (aardling.eu/)
Kent consistently challenges software engineering dogma, promoting ideas like patterns, test-driven development, and Extreme Programming. Currently affiliated with Three Rivers Institute and Gusto, he is the author of many Addison-Wesley titles. - วิทยาศาสตร์และเทคโนโลยี
No, nothing fancy, just simple things!
A simple, yet good example of leadership, experience and humility.
It just feels so easy and pleasant to listen to Kent.
Always learning from him.
Thank you.
The first nine minutes is all you need. Love it!
Love this style of explaining things: informative and fun.
Very deep: Make change easy than make easy change
It’s so pleasant to hear and listen to you Kent as always ☺️👍
Nice to stumble upon this one again, remember it from the conference. Such a nice talk and love the hand-drawn slides
Awesome talk from one of the greats!
I didn't know Stone Cold Steve Austin was a domain driven design expert.
“What is the collective salary of this room?”. Just awesome. Thank you Mr. Beck!
Just used Parallel today, thank you Kent Beck!
11:30 자동차를 구매하는데 30%의 돈을 쓰고 유지보수에 70%의 돈을 썼다면 나쁜 차를 의미한다. 하지만 소프트웨어는 70%의 예산을 유지보수에 사용한다.
11:40 소프트웨어는 등장하자마자 변화하는 요구사항에 대응해야한다. 변경은 소프트웨어의 본질이다.
13:04 Structured Design(a.k.a 그린북)에는 Coupling(결합도)와 Cohesion(응집도)에 대한 명확한 정의가 나와있으며 이 정의를 따를 것이다.
14:10 s/w는 element(요소)로 구성됐다. variables, statement, expression, function, class, module, repository 모두 element이다.
14:40 Element A와 B가 있을 때, COUPLED(A, B, Δ) :: ΔA -> ΔB. 즉, A를 변경(Δ)했을 때 B도 변경해야하면 A와 B는 Coupled 이다.
16:30 시스템 1, 2, 3이 파라메터 (A, B)에 결합되어 있으며, B 이름을 바꾸고 싶을 경우 1, 2, 3 모두 중단하고 동시에 배포해야하는 문제가 있다.
18:20 이 문제를 피하려면 1에 C를 추가해서 2, 3이 B를 안쓰고 C를 쓰도록 한 다음 B를 지워야함. 이렇게하면 시스템을 ugly(B와 C가 중복이므로)하게 만든 뒤에 청소(B=중복을 제거)해야한다.
20:30 COST ~= COST(CHANGE) ~= COST(BIG_CHANGE). 대부분의 변경은 적은 비용만 들지만, 소수의 변경에 엄청나게 큰 비용이 든다. ( www.cs.toronto.edu/~penny/teaching/csc407-02s/lectures/04structured-design.pdf )
25:20 커플링은 의도치 않게 발생할 수 있다. 두개의 서비스가 하나의 렉에서 같은 스위치를 공유하다보니 백업 절차와 관련해서 커플링이 발생했고 이것때문에 장애가 발생했다.(대충 이 얘기인듯)
27:15 expert 개발자는 "Global state를 쓰지 않는다"라는 근본적인 습관을 갖고 있다. 이렇게하면 커플링을 줄일 수 있다.
28:20 Cohesive(adjective. 응집력이 있는) : sub element 하나가 바뀔 때 같이 바뀌어야하는 sub element의 갯수.
29:30 엘리먼트 E가 e1~e4 4개의 sub element가 있고 e1의 변화는 e2의 변화를 요구한다할 때, (e1, e2)와 (e3, e4) 두개로 E를 분리하면 cohesive가 더 높아지는 것임.
30:50 커플링이 많아질수록 변경에 드는 비용은 높아지고, 디커플링 비용은 모듈이 늘어날수록 줄어든다. 이는 trade off여서 적절한 지점을 선택해야한다. (발표자료 p5 기준으로 couple = inter-module, decouple = intra-module, cost = errors, x축=#모듈 인듯.)
32:15 소프트웨어 디자인은 "reduce coupling & improve cohesion 하는 작업"을 할지, "그냥 ugly한 현재 코드에 기능을 추가"할지 선택하는 작업이다.(일듯?)
35:40 사람들은 경멸적인 표현으로 "이 시스템은 유기적(organic)으로 증식했다"라고 표현하는데, 그게 정상이고 다른 옵션은 없다.
37:15 좋은 소식이 있다. 당신은 항상 cohesive한 방법을 찾을 수 있다. 동시에 변경해야할 것들을 뽑아내면 cohesive가 높아진다. 내 학생중 한명이 수정사항이 생겨서 긴 함수의 두줄을 바꿀일이 있었는데, 이 두 줄을 extract해서 cohesive element로 만들고, 테스트&변경 후에 다시 inline했다.
39:20 어떤 문제에 답을 원하면, 문제를 올리지 말고 나쁜 답을 올려라. 그러면 누군가 좋은 답을 써줄것이다.
39:45 두가지 스타일의 디자이너가 있다. "Lumpers and splitters"가 있고 난 splitter이다.
41:35 Coupling은 A가 바뀌려면 B가 바뀐다는 것이다. Cohesion은 하나가 바뀌면 sibling들이 같이 바뀐다는 것이며, 이는 Coupling의 scope을 줄인다.
43:50 Idea behavior / idea -> structure -> behavior. idea(어떤 변경을 가할지에 대한 아이디어)와 behavior(시스템의 기능)은 상호작용한다. s/w 디자이너는 여기에 더해 structure 변화도 생각해야하는데 structure 변화에 대한 idea는 behavior와 분리해서 적용해야한다.
44:30 MCETMEC : Make Change Easy Then Make Easy Change.
45:44 Make "Next" Change Easy가 절대 아니다.
48:20 structure 변경과 behavior 변경을 분리해야하며, 예를들면 PR 분리하는 것. behavior 변경은 (예를 들어 db에 데이터가 바뀌어버리면) 되돌리기 어렵지만 structure 변경은 언제든 되돌릴 수 있다.
50:50 waterfall 방식 개발이 부활하고 있다. feedback loop가 길면 그게 waterfall이다. 변경에 대해 feedback을 안받으면 다음 변경은 무의미하다. 결과를 예측할 수 없고, 앞선 변경이 그 뒤 상황을 다르게 바꿔버린다. DDD는 feedback을 요구함으로써 waterfall의 부활을 막을 수 있다.
----
Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design
ㄴ www.amazon.com/Structured-Design-Fundamentals-Discipline-Computer/dp/0138544719
ㄴ 발표자료 : www.cs.toronto.edu/~penny/teaching/csc407-02s/lectures/04structured-design.pdf
Lumpers and splitters : en.wikipedia.org/wiki/Lumpers_and_splitters. Lumper=부두일꾼 인데...비유적 표현일듯. "Lumpers rejected differences and chose to emphasize similarities. Splitters, by contrast, emphasised differences, and resisted simple schemes."
Great lecture I watch it all and loved it
Very good one!!! Thank you very much!
Enjoyed this so much!! A good mix of life & tech lessons.
you all prolly dont care at all but does anyone know a method to log back into an instagram account?
I stupidly lost the account password. I appreciate any assistance you can offer me.
@Knox Zavier instablaster ;)
@Fisher Alaric Thanks so much for your reply. I got to the site thru google and I'm in the hacking process atm.
Takes quite some time so I will get back to you later with my results.
@Fisher Alaric it did the trick and I actually got access to my account again. I am so happy:D
Thank you so much you really help me out!
@Knox Zavier you are welcome :D
Great talk, thank you very much! The most important takeaway for me: Separate structural changes from behavioral changes!
36:51 > you need to make it better, _in some kind of way_
37:50 reflex: extract one/two lines into function. test-change-test function
38:55 "cohesivating"
41:35 > a way of reducing the scope of coupling.
Might it rather be to make explicit the scope of coupling by removing from the sub-elements those which are not coupled ?
43:40 > I could add this database…
44:30 MCETMEC : Make Change Easy Then Make Easy Change.
> What would the system have to look like in order for the change to be easy ?
48:00 necessary to do a little more now to be able to continue to make desired changes
48:20 separate structure & behavior changes
easy to undo vs not easy to undo
I have no idea what he's referring to at 50:50 "there are people saying", "things that are very waterfall-y"... what people? Saying what?
Spend your brainpower on making the change easy instead on making the change itself.
cohesivating? Gluing?
What is the "PR" he talks about at 48:20?
All right, could be Public Relationship or maybe Pull Request...
Definitely “pull request”
24:13 "whoops"
"WhooOap!" part was awesome 😄
th-cam.com/video/3gib0hKYjB0/w-d-xo.html