Continued Learning: The Beauty of Maintenance - Kent Beck - DDD Europe 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.

[@anitsh]

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.

[@onlinesaurav]

The first nine minutes is all you need. Love it!

[@PigOfNinja]

Love this style of explaining things: informative and fun.

[@l_combo]

Awesome talk from one of the greats!

[@B0K1T0]

Nice to stumble upon this one again, remember it from the conference. Such a nice talk and love the hand-drawn slides

[@casualgamer--7dsgrandcross607]

It’s so pleasant to hear and listen to you Kent as always ☺️👍

[@aldosilva6]

Very deep: Make change easy than make easy change

[@user-yj6hl1op1j]

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."

[@Tiptup300]

Just used Parallel today, thank you Kent Beck!

[@adipratapsinghaps]

I didn't know Stone Cold Steve Austin was a domain driven design expert.

[@noamnoam9500]

Great lecture I watch it all and loved it

[@romanzabeida695]

“What is the collective salary of this room?”. Just awesome. Thank you Mr. Beck!

[@pauloch8]

Very good one!!! Thank you very much!

[@abdulkaderjeelani]

Enjoyed this so much!! A good mix of life & tech lessons.

[@knoxzavier7554]

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.

[@fisheralaric692]

@Knox Zavier instablaster ;)

[@knoxzavier7554]

@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.

[@knoxzavier7554]

@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!

[@fisheralaric692]

@Knox Zavier you are welcome :D

[@TubingWoody]

Great talk, thank you very much! The most important takeaway for me: Separate structural changes from behavioral changes!

[@GuillaumeNoireaux]

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

[@LetTheNewDayBegin]

Spend your brainpower on making the change easy instead on making the change itself.

[@haskellelephant]

cohesivating? Gluing?

[@pauloch8]

What is the "PR" he talks about at 48:20?

[@pauloch8]

All right, could be Public Relationship or maybe Pull Request...

[@peterbarabas9358]

Definitely “pull request”

[@fennecbesixdouze1794]

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?

[@JSANL]

24:13 "whoops"

[@tahirraza2590]

"WhooOap!" part was awesome 😄 kzbin.info/www/bejne/aZjMk2OegL6deJI