-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathRetrospective.txt
2875 lines (2633 loc) · 135 KB
/
Retrospective.txt
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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Retrospective: Ensemble #146 (Fri Dec 27, 2024)
-----------------------------------------------
Thoughts, Observations
Consistent way of creating "things" on a higher-level of abstraction in our tests
Helper/fixture methods spread all over the place
Different tests end up with different helper methods
Perhaps a Test Data Builder?
If not familiar with codebase, looking into the code: do you need to know how it works?
Why are we in this code? What answer are we searching for? If you go deep into code, that uses up valuable cognitive space, which may not be necessary.
Event Sourcing: using Reconstitute to create the Player
Create Player in repo with a specific Player ID
Had a choice of how to get a PlayerAccount with a known ID into the PlayerAccountRepository
Learnings
F4 - jump to source from Git log (and elsewhere)
and CMD+down-arrow
Test Doubles are used to "stand in" for I/O or hardware (Date/Time or Random) access
To make them predictable for testing
Domain objects never get replaced with Test Doubles
Retrospective: Ensemble #145 (Fri Dec 13, 2024)
-----------------------------------------------
Thoughts, Observations
We were red much of the time!
We got green for a bit when we were working on something unrelated to the failures
Updating tests one by one to reflect change
Hard to see the best way to connect the PlayerAccountRepository with GameBuilder
Only one test class had to change, so not enough to guide us
Start from the test side by extracting into a method and generalizing that test
Could end up with degrading tests
We don't always pay attention to readability of tests once we get them to pass
But better than elsewhere!
Paying attention to red test over cleaning up green?
Need a good "domain" name for the phase after bets are placed and the initial deal
Consistency of local variable naming: use "default" names
Dopamine hit from predicting the correct failure of a test, "red" but a "good" red
Watch out for autocomplete by "AI"
It can make it hard to change once it writes the code
Helps with unfamiliar syntax
Need to review carefully
Look at IDE errors, don't just guess
Retrospective: Ensemble #144 (Fri Nov 8, 2024)
----------------------------------------------
Thoughts, Observations
Reading test failures is harder than you think (keep it simple)
Use English and not focus on technical (method calls, etc.)
Good to be able to switch from thinking as a developer to thinking as a user (point of view)
Talked to our Customer to validate what the game should display
Feel like cleaning up the test should have happened before we moved on to the next feature
Moved on to fixing the Done view before we cleaned up the tests
Test setup getting overly verbose
Have a way to more easily create players with IDs and names
Ensemble with 3 people feels very fast
Bit more intense
Had a lot of fun!
Breath of fresh air to have fast tests (and good tests)
+1
Quick to get back up to speed
Learnings
Clarified rules around Adapters accessing "Repository" (really a Finder), which is fine
View is a snapshot of the current state of the Game, needs the "Finder" to resolve the Player Name, but doesn't change state
Retrospective: Ensemble #143 (Fri Nov 1, 2024)
----------------------------------------------
Thoughts, Observations
Spring Form objects are a bit confusing when using for both providing data to the Thymeleaf template AND for extracting submitted form contents
For BettingForm we use both ids and names, but upon submission, we only care about the bet values
Perhaps split into two objects?
Thymeleaf is complex and can be confusing
Cody really helps here
We don't currently have automated tests for the actual HTML generation
Future we could write an HTMLunit test
Felt good to be back!!
+1 +1 +1
Assertions aren't always as readable as they could be
Pay more attention to what we care about and what we don't care about in test setup
Keep the things we care about obvious and the irrelevant things hidden
Test names too technical vs. more domain-ish?
Good that we renamed the tests to be more expressive as we encountered
Learnings
Appropriate Primitive Obsession for View/Form objects
Next Time
Is there a way to add getting the player name without breaking a whole bunch of tests?
Look at the @Disabled test
Questions?
Can we use DataFaker?
Retrospective: Ensemble #142
----------------------------
[canceled]
Retrospective: Ensemble #141 (Fri June 14, 2024)
------------------------------------------------
Thoughts, Observations
4 minutes is kinda short for 3 participants
Lada is happy to be back! +1
Start with anonymous implementation might have been confusing
PlayerAccountFinder as inner class inside the test bettingFormContainsPlayerNames() might have been better to push it out
Learnings
Change Signature lets you type anything into the variable definition, lambda, null, garbage, whatever
Quick fix for constructor to bind variables
Quick fix for @Override to fix via "pull up" method
Can use that directly as a refactoring
Quick fix to implement the interface (on PlayerAccountRepository with PlayerAccountFinder interface)
Create (read-only) property quick-fix creates the method AND the field
Some refactorings are mini-wizards, tab/enter through them to get the benefit
Watch out for the blue rectangle
Retrospective: Ensemble #140 (Fri May 24, 2024)
-----------------------------------------------
Thoughts, Observations
"I don't DRY-up my DTOs"
Not all duplication is bad, sometimes it's very useful
e.g., make it easier for Thymeleaf templates to consume
If Navigator doesn't have enough context, then need more guidance/background of what's needed
Outside-in TDD for new/changed functionality
(outside may not always be the UI)
Adapter is allowed to READ from an Outbound Port (but not modify, so best to use a Read-only Port)
According to Ted, at least. :)
This is a nuanced rule, so if there's less confidence in the team's judgment, you might want to enforce "No Port Access from Adapter" rule
Finding out WHY the Mission asked for putting the PlayerName into the PlayerInGame was important to flesh out the true reason, which led us to not do that, but get the player name at the Adapter level
Learnings
Learned about Spring MVC auto-conversion of incoming HTTP message text to variables/objects
For user-entered data (e.g., text field), accept a String, but for pre-filled data (select from list), you can use an int/long directly
Spring MVC docs are informative +1
Parallel change: extract part of the old method that has the signature you want, or copy to create a new version
Retrospective: Ensemble #139 (Wed May 15, 2024)
-----------------------------------------------
Thoughts, Observations
Reinforced why cleaning up commented out code right away: so we don't have to remember why it was commented out in the first place
Finally deleted commented out code!
Liked reviewing previous Retrospectives
Having only 3 people in Ensemble feels more fast-paced
Loosened things up, especially when collaborating on Thymeleaf template
Fun!
Mike triggered same thought about using Introduce Parameter to push out (change signature) of createGame to accept the PlayerSelectionForm instead of NewGameForm
Cody wanted to invite Lada into the Participants file
Learnings
Learned about Thymeleaf's "th:object" and "th:for(#ids)"
Retrospective: Ensemble #138 (Fri April 26, 2024)
-------------------------------------------------
Thoughts, Observations
Haven't used the Mission in a while, could that have helped as a reminder
We don't have a habit of looking through "Next Time" when we start
Found another disabled test that we're not sure about
Implementing our custom equals() was harder than expected
Confused playerId with the object itself
Dealing with the generated code and then modifying it, vs. writing it from scratch
Entity's ID defined equality, but that null IDs are NOT equal to each other
Except if the objects are the same instance
We didn't look at hashCode!
What's the implication of this?
Created a TestableAggregate subclass for testing instead of using PlayerAccount
Turns felt shorter because of fewer pauses
Do we pause explicitly, or make turns longer?
Test names out of sync, or too short (or too long)
Disabling tests with no reason could be improved by adding a reason
"ratchet up the assertion"
Make the test assertion more precise, e.g., "hasSize(2)" to "containsExactlyInAnyOrder(...)"
Next Time
What's up with the disabled test?
#3: clean up commented out code in BlackjackControllerTest
Make hashCode "correct" for the case when playerId is null
Be explicit about "huddle" for pausing
Add reasons for disabled test
Retrospective: Ensemble #137 (Fri April 19, 2024)
-------------------------------------------------
Thoughts, Observations
Using dependencies (coupling) to figure out responsibilities of the controller class(es)
Coupling and cohesion
Led us to moving separate responsibility out of BlackjackController into a new controller, which made it smaller
Test against WelcomeController (currently) doesn't need GameService
Code Smell: adding a new dependency that's only needed by 1 (or few) methods
Passing in dummies frequently might be a hint that there's an issue
Liked discussion around factory creation methods vs constructors
Understanding why we're using the methods we're defining
DTO from(Domain) for transforming Domain to DTO vs. of() for easy Value Object creation
Confused by unexpected behavior around the index page
Multiple steps to finally find that it's "magic"
But perhaps not the magic we were expecting
Break It To Learn
and then might be surprised by no tests failing
If the result isn't expected, investigate
Inside-Out vs. Outside-In
Outside-in can provide test "backstop" vs. Inside-Out having to write more tests
Not every single method necessary needs to be test-driven
Inside-out might result in a bad "protocol" (API of the object is wrong!)
Good day!
Learnings
Spring Boot tries to be helpful by pulling static resources from lots of places (not just /static)
Next Time
Clean up and delete the commented out test code
Retrospective: Ensemble #136 (Fri April 5, 2024)
------------------------------------------------
Thoughts, Observations
Big group today
Felt different
Felt good
Got a bit confused and frustrated about Thymeleaf
Forms can be a bit confusing in context of Spring
Had pre-populated information, vs. empty form that has user enter information
Noticed some "noise" in setup code for the BlackjackControllerTest
Bit of a delay in updating names: name of the test, name of attribute in the model, etc.
As the purpose of the test changes, update the names to reflect their new purpose
Learnings
Learned about static index.html
Learned about Model and testing
Forms vs. Views
(re)learned about MVC test
Does the minimum possible, anything else we do one layer down (as an I/O-Free test)
All Tests are slow, so better to run only the MVC test that you're working on
Learning more about AssertJ
Learning it better/more deeply
Cmd+Shift+T/Ctrl+Shift+T to go between Test and Test Subject
Next Time
Clean up BlackjackControllerTest
Retrospective: Ensemble #135 (Fri March 29, 2024)
-------------------------------------------------
Strong-style is not always useful, e.g., "whiteboarding" some ideas and thoughts
Driver is not really learning
It's very tedious and awkward for both parties
Let's stop and huddle, which means that the person with the idea or question becomes driver+navigator
Finally deleted events from EventSourcedAggregate!
Once we store the lastEventId explicitly, that let us delete events
Let's try this! Try instead of thinking.
More participation among folks during a rotation
Using AssertJ's .as() to add a description to be displayed if the test fails
Safe Delete is available on the Refactor This menu or the Refactor menu
Command+Delete (Cmd+Fn+Backspace) or Alt+Delete
Retrospective: Ensemble #134 (Fri March 15, 2024)
-------------------------------------------------
Thoughts, Observations
Seeing the "don't let super-class constructors call abstract methods implemented by the subclass" problem makes it more real
Experience is more powerful than reading/watching
Sad that moving the for loop into the base class didn't work, unclear what a good solution
Lambdas can't modify primitives, so we use an AtomicInteger
Can't point the variable at a new reference inside a lambda, so just add a level of indirection
Postcondition assertion: discovered it wasn't providing enough information in the error message, but we were still confused.
Then added more error message information to see what happens
Two "small" tasks took longer than we thought
Hofstadter's Law
Mob hand-off when tests passed (incorrectly) was made less of an issue, because other machines were failing, so we were pretty sure it was a machine-specific problem instead of spending lots of time troubleshooting the code
Off-by-one errors are hard
Questions?
Could have an internal/separate state object be useful (instead of storing the Aggregate's state directly in PlayerAccount, have it in an inner class of PlayerAccountState)
Could make that internal state object part of the generification of the EventSourceAggregate base class
Retrospective: Ensemble #133 (Fri March 8, 2024)
------------------------------------------------
Thoughts, Observations
"Mental Model Sync-up"
Ensure clause vs. Require clause
Bertrand Meyer's Design by Contract
Preconditions and Postconditions
Thumb-voting to decide what to do
We decided to ensure that the in-memory repository ensures that eventDto's ids are increasing (to simulate what the database would do)
Keeping track of object references can get confusing (see the PlayerAccountRepository.save() method)
Which could lead to bugs down the line
Purposely created a test to drive new behavior, and then deleted the test
Felt weird/artificial because we were trying to push private implementation in a certain direction
Better: extract the behavior into a smaller class that exposes the behavior and test-drive that new class (e.g., a UniqueIdList)
Monotonically Increasing: later values have a higher value, does not imply consecutive (so can skip numbers)
Usually found in distributed systems (e.g., database IDs)
Learnings
Map's computeIfAbsent also returns the value
Next Time
Use a REAL database for storing the PlayerAccountAggregates
Use a library for storing events?
Retrospective: Ensemble #132 (Fri March 1, 2024)
-----------------------------------------------
Thoughts, Observations
Highly enjoyable!
Love the design discussion
Discussed options and what works, what wouldn't
Coding was fun as well
Experimentation was good
Just change the code to see, but wasn't quite there yet, so reverted changed (so nice to have good tests)
Pattern of command methods creating an enqueuing events, which are then applied
Parallel change (with "freshEvents")
Swapping freshEvents for events where it made sense—until it didn't
How to get rid of the "old" behavior, is the hard part
Ugly Green
Lie, cheat, steal, break rules, don't worry about clean or pretty—whatever it takes
Refactoring is the time to clean and tidy the code
And only have to focus on that and not ALSO solving the problem
Otherwise leads to writing too much code
Small steps is always better than larger
Felt like I was coding, even though I only navigated
Zooming is great to increase size of fonts, etc.
Learnings
Willem Larsen: micro-retrospectives (every rotation for 3-5 minutes)
Throw "stickies" on a board (e.g., Miro) and then quickly go through them
Could write them as the rotation was happening and/or during the micro-retro
For tiny things, leaving bigger issues for the larger/longer retrospectives
5-7 minute keystroke practice once or twice a week
Turn Presentation Assistant on
Cmd+Shift+A (Ctrl+Shift+A) to get access to the Zoom
Can assign your own shortcut from the Actions search
Retrospective: Ensemble #131 (Fri Feb 16, 2024)
-----------------------------------------------
Thoughts, Observations
Good session, made good progress
Fun!
Humbling: need to spend some time doing intentional learning
Especially stream mapping and optionals
Seemed so easy!
With only 3 participants, feels much faster, less time "leaning back and enjoying the ride"
Perhaps led to faster progress?
Felt a little less "formal" and working well together: due to either smaller rotation, or we know each other better. More talking/discussion that didn't feel intrusive.
Rotation Timer switching is still useful to take a different step
Tiny step vs. stepping off a cliff
Appreciated the discussion around instantiating the ObjectMapper vs. making it a static variable and GC related issues.
"Do it out of empathy for the database"
"Comment out these lines" vs. "Comment out the switch statement"
Strive for higher-level Navigation commands over low-level detail
"Just do the rest"
"scroll down, no the other way, no more" vs. "bring line 25 into view" or "bring the entire method Pants into view"
Learnings
Optionals are special collections (can hold either none or one element)
Retrospective: Ensemble #130 (Fri Feb 9, 2024)
----------------------------------------------
Thoughts, Observations
Good to understand when to use Generics vs. inheritance and base classes
"PlayerWonGame" vs. "Player 1 Game" are homonyms
Pairing/Ensembling increases communication among colleagues (because you get to know them better)
When refactoring: focus (first) on what's changed recently, not all the code
If things look slightly similar, see if you can make them even more similar
Keep pushing on the similarity until you can get to exact duplication
And the use Inline Method!
Preference to keep DTO constructors expressed as using primitives instead of doing conversion/transformations inside the constructor
Learnings
Unnamed variables (released in Java 22)
ObjectMapper for JSON to Object (and vice versa)
Don't throw checked exceptions in methods that will be used in the context of a stream operation
Next Time
Set up Presentation Assistant to show Mac and Windows shortcuts
Retrospective: Ensemble #129 (Fri Jan 26, 2024)
-----------------------------------------------
Thoughts, Observations
Jackson JSON annotations overwhelming
Verbose way of converting when things are non-standard
Ask ChatGPT to figure this out
Happy to avoid directly annotating Domain objects
Switched to more "typical" ensemble behavior when trying to solve difficult problems (with JSON mapping)
Can be a bit more chaotic
With parallel work from individuals, bringing ideas and possible solutions back to the Ensemble
Making sure the Driver knows who (which Navigator) to pay attention to can reduce the chaos
Making it explicit that we're no longer in strict Navigator-Driver mode
Interesting solution(s) from JetBrains AI for the JSON serializing-with-type problem
Write it (event-sourcing persistence) yourself to understand what a library might provide
Learnings
Join Lines: Ctrl+Shift+J (eliminates whitespace in the way that you'd want)
Next Time
Have event concrete subtypes provide an "asMap" method to make conversion easier?
Instead of embedding the event type into the JSON, make it a separate database column (field)
Retrospective: Ensemble #128 (Fri Jan 19, 2024)
-----------------------------------------------
Thoughts, Observations
Liked sketching out things in more detail to help understand where we're going
Especially what a record in the database table will look like
Creating the DTOs is interesting as we're storing JSON instead of concrete (primitive) fields
Composite ID for events: PlayerID + EventId for storing the events in the DB
Was confused and unclear about things, storing the events +1
A good confusion
Learnings
String Templates ("interpolation") as a Preview Feature
Read the JEPs!
Retrospective: Ensemble #127 (Fri Jan 12, 2024)
-----------------------------------------------
Thoughts, Observations
Felt a bit weird to have a concrete Repository implementation in the application layer
Prefer writing tests against minimal amount of desired behavior (IDs are unique vs. next ID = 80)
A little more scared of the change to returning Optional from the load/find method: everything will have to change
CHANGE RETURN TYPE: Can't really use Change Signature, so create new method, delegate old to new, then inline as needed
Felt really rusty today
In-memory repositories are often built in very much the same way
Unique IDs
Save by ID
Store the snapshot ("content") of the object instead of just storing a reference to the object
Better simulates "real" repositories
Will be easier because we already have the "content" as events
Learnings
IntelliJ IDEA can auto-fix to wrap our int with PlayerId when the parameter is required to be a PlayerId type
Next Time
Tell a better story by rearranging the order of test methods and make names consistent in PlayerAccountRepositoryTest
Retrospective: Ensemble #126 (Fri Jan 5, 2024)
----------------------------------------------
Thoughts, Observations
TDD is a series of TINY moves
Repository load() vs. findById() vs. findOne() -- all the same idea
Liked how we started from the outside, disabled, and then moved down another layer, disabled again and finally started implementing
TDD Inception
The outer test helps define what is needed from the next layers (objects)
Not "real" layers: but distance from where the behavior is implemented
Read model is basically a cache (holds computed state of event-sourced aggregate)
It's an optimization
If it's a separate table in a database (or held in a completely different database, e.g., document database), then can be accessed outside the app
Frequent commits via "mob next"
Learnings
Eventual Consistency = Weak Consistency (vs. Strong Consistency = Transactional)
Quick Fix to transform Constructor to Factory Method
Ctrl+Shift+; | Cmd+Shift+;
run recent TESTS
Next Time
Future: generify the EventSourcedAggregate
Create dedicated subclass (nested class) for testing only
Retrospective: Ensemble #125 (Fri Dec 29, 2023)
-----------------------------------------------
Thoughts, Observations
Pattern matching with Record patterns and switch and unnamed variables (underscore) and Sealed/Permits
Aggregates are self-contained and do not reference other aggregates directly
Different kinds of "Commands": Command Objects (Pattern), Command Methods on Service/App Layer and on Domain Objects
Domain Object Command method must not return any value
Service Layer commands may return a Result
PlayerAccount Invariant? do we require a bet to have been placed in order to process a "win"?
Learning more about event sourcing
Best way is to write the code
Aggregates are for organizing/implementing how data is changed, read models may differ
May have a "PlayerAnalytics" read model that has no command methods
Next Time
Command methods past or present: is "win"/"lose" or "won"/"lost"??
Retrospective: Ensemble #124 (Fri Dec 22, 2023)
-----------------------------------------------
Thoughts, Observations
(For event sourcing:) Tests being split to: Commands Generate Events and Events Project (results in new) State
Could split along Command/Event lines: all tests for Register, all tests for Deposit, etc.
Names are still hard
Still getting head wrapped around Event Sourcing
Other ways to handle event application?
Learnings
Pattern matching for if statements (with local variable of that type)
Pattern Matching switch
Sealed + Permits to support pattern matching
Evident Data: in tests, showing clearly where the assertion came from, e.g., isEqualTo(20 -10)
Helps tests be readable/understandable at a glance
Next Time
Resplit PlayerAccountTest along commands vs. current command-event split
Encapsulate Setup for PlayerAccountTest
Retrospective: Ensemble #123 (Fri Dec 15, 2023)
-----------------------------------------------
Thoughts, Observations
Event sourcing - bloody hell!
Don't quite understand event sourcing architecture
Need to experience implementing it to truly learn it
emit (JavaScript) = raise (PHP)
Evident Data: e.g., assert that balance is 53 + 25 to make it easier to connect the assertion with the setup data
Testing "at a distance" for testing the behavior at different levels of abstraction
What tests to getting rid of the balance = (wrong) via new tests
Finding tests to guide our implementation to event-sourcing not easy
Letting the code guide tests
Learnings
List.of() creates an unmodifiable/immutable List
Aggregate can be state-sourced or event-sourced for storing state
Choosing between the two types is mostly a business decision, but may be the default implementation if you have good support (team knowledge/framework)
Refactoring Event Streams is not as straightforward
All events coming from the database to reconstitute the Aggregate must be valid
Commands Generate Events (if it's OK to do so—holding invariants) is fundamental to Event Sourcing
Events Modify State, too
Next Time
Split the current apply() into two methods for adding the event and executing the state change
Retrospective: Ensemble #122 (Fri Dec 8, 2023)
----------------------------------------------
Thoughts, Observations
Drivers and Navigators communicate two-ways
When N/D are unfamiliar communicate can be confusing
Feedback from drivers is just as important as corrections from Navigators
Liked the use of the word "emit" relating to events
Use of "projection" for events to state
Code feeds back into writing new tests
TDD gives you almost immediate feedback when code is broken
New navigator can always talk to the previous navigator!
Make sure you know exactly why a test has failed
So you can fix it properly!
Separated tests into two parts: Commands->Events, Events->State
Patterns of Event Sourcing — very different from State Sourcing
Learnings
Records in Java
Instanceof pattern matching without having to manually cast
Switch pattern-matching coming
Event-sourced events must be ordered by time
Nested tests! +1
Next Time
Reducing details from test method names to make intent more clear
Retrospective: Ensemble #121 (Fri Dec 1, 2023)
----------------------------------------------
Thoughts, Observations
Starting something new, didn't require a lot of context/baggage.
Event-sourcing is new for us!
Nice to be able to do it, never having done it before
Command objects vs. calling methods will be interesting
Hard to figure out where to start implementing the event-sourced PlayerAccount, but liked where we ended up: TDDing rehydrating the PlayerAccount with events
Liked the cognitive jump from sketching out the solution to our TDDing. Started thinking about the state, but how to "force" us to implement events
Tempting to create the event hierarchy (base class) before we needed it
Planning is useful, but still need to take small steps when TDDing
Also the implementation of processing the events, no need for an "apply" method just yet
Refactoring: adding explicit constructors to Record (a bit confusing) vs. convert to a class and then convert back to Record
Inlining method: ensure the method (to be inlined) only calls public methods, not the field, to make sure after the inline, the caller has access to the method
See inlining id()
.arg helpful as always
Deleting code (even test code!) can be difficult (loss aversion)
delete! delete!
Retrospective: Ensemble #120 (Fri Nov 24, 2023)
-----------------------------------------------
Thoughts, Observations
Discussion of mixing Test Code in Production Code: relaxing the "no test code in production" rule
Original intent was not mixing test-based logic in production code, so why not put test values or substitutable test code in production code? (As per James Nullables)
Extract new method and inline old to refactor return value
Encapsulated Setup as a name for refactored test setup code
Finally got rid of Deprecated place bets code!! 🎉
Feature flag is removed
We are really done!
Looking forward to event-sourced PlayerAccount aggregate!
IDs don't have to be longs (or numeric in general), but encapsulating them in a Value Object means it's easier to change in the future
Rotation felt faster, even though only 1 fewer people (4 instead of 5)
Perhaps because more drivers know their shortcuts?
Fewer huddle pauses
Being diligent about marking code as @Deprecated, and then searching for it to ensure we cleaned everything up helped a lot
Learnings
.arg postfix
Retrospective: Ensemble #119 (Fri Nov 17, 2023)
-----------------------------------------------
Next Time
Add @Nested for unit tests
Maybe play with Modulith for the Player Management bounded context
How to extract setup in com/jitterted/ebp/blackjack/adapter/in/web/BlackjackControllerTest.java:178
Use GameBuilder?
Thoughts, Observations
Finally getting to where we can delete deprecated methods
Seeing more differences between pairing and ensembling
Strong-style pairing
Controller method is now tiny
Transformation of Domain to DTO (Form) happens in the Form
Which is in the Adapter
This is a common pattern: DTO transforms Domain Objects to primitives (int, String, etc.)
Inside the Hexagon, it's all Domain Entities and Domain Value Objects
Speak in the language of the domain
Spend the time to refine names after the refactoring
Use the initial name for a bit before thinking about renaming
Test code that tested both sides of the feature flag: didn't immediately notice that, but then only had to delete the "old" version
Having them next to each other made it easier to notice
Maybe using Nested tests
We haven't had to deal with feature flags and database changes
Using ""+int instead of String.valueOf(int)
Finished the feature!
Let's make lots of money
RORA - Run Once Run Away
Retrospective: Ensemble #118 (Fri Oct 27, 2023)
-----------------------------------------------
Thoughts, Observations
Don't apologize for asking to commit
Either use mob next or explicit commit with a comment only if we think we might mess something up
Refactoring to change return type of a method can be difficult to automate
Liked how straightforward it was to onboard Clare
Power of the Ensemble!
Recognized we were perhaps going too far changing the player IDs from `int` to `PlayerId` and we stopped
Nice to not feel like I'm the only one who doesn't understand the migration preview dialog
BlackjackControllerTest: do we setup using the BlackjackController (using the NewGameForm) vs. more directly using the GameService
It's a trade-off
Learnings
Shortcuts!
CTRL+T (mac) refactor menu
CMD+SHIFT+ENTER completes the current statement/line
More on the cheat sheet
Introduce Parameter
Changes parameter type
`gst` shorthand for git status
git diff
Next Time
Do `mob next` more often
Retrospective: Ensemble #117 (Fri Oct 20, 2023)
-----------------------------------------------
Thoughts, Observations
Disabled vs. keeping a test "red"
Makes it harder to think about "are we green?"
Could delete the test
When it is rewritten, folks will learn a lot by having to create
If it's hard to write, could tell you a lot about the state of the code
Fighting loss aversion/sunk-cost fallacy
"I hate it, so I have to try it"
Or only limit WIP to one disabled test
Lots of moving parts in the Spring MVC + Thymeleaf templates
Two different "Forms": the HTML form itself (is a "view of the model") and the Form Object (DTO)
Feature Flag
Can use tools to manipulate the flags
Can lead to misuse
Branch in code vs. create branches in version control
The application was broken for a while, because we hadn't run the application
Happy to have Clare joining as Spectator!
Learnings
Introduce Parameter as way to safely add a parameter to a method
Use Stream<> as a Query method return type to indicate immutability
Retrospective: Ensemble #116 (Fri Oct 6, 2023)
----------------------------------------------
Thoughts, Observations
Coding in C#, wasn't sure how to do it in Java
Lean on the ensemble supporters for help
Maps and the fact that they're not sorted by content nor by order added, as they're almost always HashMaps
Treating the BlackjackControllerTest as an "acceptance test", and then how to test the inner layers
Outside-in TDD
How much Parallel Change (backwards compatibility) do we want/need
We skipped the Zero case for BettingForm
Learnings
Use add unambiguous imports on the fly, tune by excluding ones that should never be imported
Using the correct assertThat for containsExactly vs. containsExactlyInAnyOrder
Cheat sheet: https://ted.dev/courses/mastering-assertj.html
Retrospective: Ensemble #115 (Fri Sept 29, 2023)
------------------------------------------------
Thoughts, Observations
Had lots of "luck" today: exposing random issues with WebConfigurationTest
Got rid of all Disabled tests!
Validating the incoming form for players playing: the form is responsible for doing that validation
Thinking about how the UI will handle placing bets
One big form for all players and their bets vs. looping through all players
We're doing one screen multiple players
PlayerId.of was nice to add
Parallel change was good: allowed us to control what needed to change (instead of breaking a whole bunch of tests)
Was nice that we already had a way to serialize the StubDeck to a custom-deck string (convertToString) for use in the BlackjackController
Eradicating randomness can be hard (it can sneak up when unexpected)
Learnings
How the HTTP form encoded message becomes a Form object in Spring
The instance fields define the names of incoming parameters, not the containing form object
Retrospective: Ensemble #114 (Fri Sept 22, 2023)
------------------------------------------------
Thoughts, Observations
Microservices are not a solution to the problem you think you have
Single Point of Truth: placeBets boolean field duplicates information that we can infer from the playerBets List
Prefer SPOT to DRY (don't repeat yourself)
Who is responsible for converting those "unparsed" Strings to domain identifiers (PlayerId): Adapter or Service Layer? (It's Adapter)
Domain Logic belongs in the domain, not in the Adapter
Adapters can have logic, it's just UI or API or transformation logic
Domain Entities must have IDs
Even if they're not the Aggregate Root
Game must have globally unique ID, whereas Hand needs an ID, but only needs to be "locally" unique (within the Game)
Bounded Context vs. Aggregates
After breaking down and discovering the "journey", figuring out where to start was interesting: wasn't necessary at the UI/Thymeleaf level
Need to understand what we're implementing
Thinking about where to start from a testing point of view
Was straightforward to start testing against GameService with a new createGame() method
Start with the least known, scariest, riskiest task first
Learnings
Event Modeling -> focusing on the overall "customer journey"
Boundary Objects
Discovery
Retrospective: Ensemble #113 (Fri Sept 15, 2023)
------------------------------------------------
Thoughts, Observations
Satisfying to get rid of the GameFactory and complete the GameBuilder
Easier to understand the chained (fluent) builder methods than the long static factory names
Builder names require iteration to settle on good names: requires discussion and consideration of tradeoffs
Formatting weird: auto format was fine, but indentation was off for fluent builder
Bug?
Improving error messages when tests fail is always helpful to solve test failures
Safe Delete "cascade deletions" to all methods in the graph that would no longer be used
Inline Parameter worked as expected
Ensembles allow for easier joining/leaving without work being interrupted
Discussion flowed nicely
Next Time
Might consider a builder .addPlayer() for when we need a player, but not its ID (or bet)
Game placePlayerBets, etc. is a bit confusing, and playersInGame has Primitive Obsession smell
Retrospective: Ensemble #112 (Fri Sept 8, 2023)
-----------------------------------------------
Thoughts, Observations
ID creation, don't use random, use something like (i+1)*n to avoid zero IDs
Avoid duplicate ID
Have stable IDs across executions
Noticing when we get error messages that don't have enough information
Fix them!
Adding cross-checks/validations with good error messages to quickly figure out what's wrong
Developer "ergonomics"
Make mistakes hard/impossible to make
Make the common things very simple, with little to no noise
How far do we go to tidy up usages of GameBuilder factory methods?
Learnings
Ctrl+Shift+J - "join lines"
Drag-n-drop tabs into center
Next Time
Tab Shifter plugin
Can we remove placeBets boolean field and just look at size of playerBets list?
Retrospective: Ensemble #111 (Fri Sept 1, 2023)
-----------------------------------------------
Thoughts, Observations
Negotiation between Driver<->Navigator for pairing
Driver does whatever the navigator says, even if disagreeing
Driver should generally understand what the Navigator's intent is
Learning Ensemble is for "productive struggle" for the Navigator
vs. in a Work Ensemble, other members are more vocal/active
Kent Beck's "Tidy First?"
Good practice refactoring to Test Data Builder
How to refactor methods, staying in "the green", not breaking things ("in the red") for too long
Sketching out the builder's API to provide a plan for the builder
Put "what will it look like" in the comments where you'll write it
Builder does most (all) of the creation in the "build()" method
Builder's have instance fields to hold onto configuration
Finding a balance for when adding characterization tests
Prefer writing more tests is better than fewer tests
If already covered, though, no need to write an explicit test
Fun!
Learnings
Cmd+Opt+T (Mac) Ctrl+Alt+T (Win) for Surround With (if statements, etc.)
Retrospective: Ensemble #110 (Fri August 25, 2023)
--------------------------------------------------
Thoughts, Observations
"Ergonomics" of test data helpers
Easy to use
Hard to make mistakes
Fall into the "pit of success"
Refactor to build() for the GameBuilder from the GameFactory
Extract full method, turn constructor into Factory method
Sketched out what we wanted it to look like
Can be hard to break it down into smaller steps, tried different things
Lots to learn from refactoring a Factory to a Builder
Good as a kata
When all tests are passing, what are some "tidy up" steps we can do
Tidy up the code you've just "finished"
Check for warnings: try to get to "Green Checkmark"
Name things to help with autocomplete
e.g., playerOneId vs. firstPlayerId
Create a "save point" commit before doing refactors
"Before doing <scary/unknown thing>" as the commit message
Learnings
F2 (and Shift+F2) to find next (previous) warning/error
Look into the right gutter
Git reset vs. Git revert commit
For mob use, we want Revert Commit
Retrospective: Ensemble #109 (Fri August 18, 2023)
--------------------------------------------------
Thoughts, Observations
Danger of using "mocks" when refactoring code, tests might not detect those changes
Avoid using sequential numbers in tests, may mislead reader to thinking they must be sequential or that it's a relevant detail
Testing too many properties of an object individually instead of comparing against known objects
Tidying up: when to stop refactoring/tidying up?
Don't nest changes too deep
Took a while to load context of what we need to do
Can be risky to modify code when a test is failing
But that risk may be OK—it's a judgment call
Learnings
assertThatNoException().isThrownBy() alternative
Change Signature via create local variables, that then become parameters via Introduce Parameter
IntelliJ will suggest removing (no longer used) parameters — that are replaced by the one being introduced
Next Time
Navigators specify the SIDE (left/right) and LINE NUMBER
Navigator picks the (random) number, instead of the Driver
Make sure Player IDs are all using value object instead of int
Questions?
When to introduce random to generate arbitrary numbers (into the setup) when they don't really matter? The assert still needs to match the setup.
Retrospective: Ensemble #108 (Fri August 4, 2023)
-------------------------------------------------
Thoughts, Observations
Could there be some parameterizing of tests once we have a builder that makes it easier to create Games and Decks with parameters?
Too focused on trying to get rid of deprecated method, not looking wider at where/how it was used
Driver in a mob does what the navigator says, not as flexible to switch roles on the fly, vs. pairing
Put ego aside, let navigator do what they think is right
Overload method — Parallel Change — instead of changing the existing method
Break only "one test" at a time
Makes it more obvious that a Test Data Builder might be more appropriate than a Factory with lots of overloaded methods
Lots of "busy work"
But is necessary
High-level vs. low-level directions
Interrupting the driver to correct instructions, providing another way of phrasing your desire is how things work
Necessary and unnecessary detail in tests
Learnings
Cmd+P or Ctrl+P to view Parameter Information (instead of code inlay hints)
Retrospective: Ensemble #107 (Fri July 21, 2023)
------------------------------------------------
Thoughts, Observations
Annoying to create games, how to make it easier?
Introducing the PlayerId was cause of some of the pain
Perhaps updating the GameFactory to use PlayerId and placePlayerBets first, instead of updating individual tests, would have been a better approach
Phrase of the day: "sore thumb"
Term of the day: "Mike List"
(this is the structure popup Ctrl or Cmd + F12)
In the green most of the time (except when we wanted to find out what is different)
Use the opportunity of having to update tests to reflect on the test and perhaps rewrite from scratch
Not having mobti.me disrupted the flow: unsure who's next, who's doing what, etc.
You don't know how valuable it is until it's gone
Split the editor on the left side to top/bottom to have the same view of the same file
Tab Shifter has shortcuts for this
vs. move the test methods closer together
Old habits die hard
reluctance to move methods around
declaring all variables first
Next Time
Self-host mobti.me
Retrospective: Ensemble #106 (Fri July 14, 2023)
------------------------------------------------
Thoughts, Observations
Getting better at combining different refactorings (inline, intro param) — Refactoring Maneuvers
Intro parameter to change the signature
Not sure when to stop doing clean up
Clean up = Refactoring
Try spending 10 minutes more before being "done for now"
It doesn't get better over time, it gets worse
After refactoring tests, make sure they are still readable/understandable in ISOLATION
When asserting, be thoughtful about why you're asserting it
Don't remove asserts unless you know that behavior is covered somewhere
Fix "sharp edges"
Improving the InvalidBet exception to make it easier to understand why it failed
PlayerCount vs. using an int
Think less at first
Try it, run tests, then think if you have to
Save that thought energy
Fast-paced, felt like a better session
Learnings
Ctrl+` to bring up the switcher (especially Zoom)
Kata to practice: code and refactoring, but DON'T use the mouse
Retrospective: Ensemble #105 (Fri July 7, 2023)
-----------------------------------------------
Thoughts, Observations
Liked the Test Refactoring
So much more readable, even a product owner could understand it
Interesting how far you can take the refactoring
Navigating/driving feels more comfortable after pairing for a while
Tend to give higher level instructions
We were in The Red for a while
Noticing is the first step
The refactoring of "I have a method that takes a list of one type, and I want it to be a list of another type" comes up and is not always temporary
Creating arbitrary numbers to use in tests vs. sequential vs. random
Learnings
Generics are ignored for overloading (etc.) in method signatures — Type Erasure
Extend Selection! Ctrl+W and Ctrl+Shift+W for Windows
Or just do Extract Method/Variable
.fori postfix for indexed for loop
Cmd (Ctrl) +Shift+Enter to complete the statement
.toMap postfix (in the Custom Postfix Templates plugin)
Learning "by heart" shortcuts, etc., to be able to stay focused on higher level thoughts
Retrospective: Ensemble #104 (Fri June 16, 2023)
------------------------------------------------
Thoughts, Observations
I often didn't know what to do
Discussion on pairing & mobbing was helpful
Inlining of methods is interesting: it's easier to inline stuff and then extract in a better way
"You can close PlayerId if you want"
Parallel List as code smell
Have an object that represents the pair (or tuple) of pieces of information.
e.g.: PlayerBet = PlayerId + Bet
(still) liked shorter turns
Trying something out: "why don't we change the index and see what happens?"
Experimenting
Jumping to PlayerAccount instead of starting with PlayerId
YAGNI
More huddles
Making low-level "engineering" tasks
Learnings
Quick Definition - Option+Space or Ctrl+Shift+I
Retrospective: Ensemble #103 (Fri June 9, 2023)
-----------------------------------------------
Thoughts, Observations
Took too big a step manually without running tests
Felt unease
Running tests then showed the change was wrong
Try to change 1 thing at a time
TCR can help
Aggregate discussion
Finding boundaries can be hard
Realized that "Player" wasn't a "Global" Player, but really was part of Game and only makes sense to exist in a Game
Renamed to PlayerInGame to make clear that it only exists in Game
When naming or design is hard, it indicates that there's an underlying issue
Can't always solve it, so leaving it as an "honest" name is a good step because it's obviously ugly
Not being in the rotation (Spectator) changes your viewpoint
Looking at other ways to contribute
e.g., writing into chat
Trying to get better at smaller steps
It's a never-ending quest
Good fun, as usual
Learnings
Ctrl+Shift+I to preview (Option+Space) -> Quick Definition
Type to narrow in various menus (Refactor This, Run Configuration)
Retrospective: Ensemble #102 (Fri June 2, 2023)
-----------------------------------------------
Thoughts, Observations
Assigning multiple fields in a method: evaluate whether it's really different information, or if they're duplicated knowledge
e.g., in Player: isDone & player's reasonDone
Duplicate Data
"Why" is there duplication?
Optional indicating that not having any (having 0) is a valid and expected state
Duplication: calling done() and then setting the reason
Combined them
Surprised when tests failed: ordering matters
As a Spectator, was a bit hard to focus/engage
Switching from Spectator to Participant meant wasn't "prepared"
Thinking about the next step helps being engaged
Liked shorter rotations
Sometimes it feels really short
Sometimes it feels like we're rushing to get things done
Refactoring to get rid of recursion worked!
More chaotic as we were getting direction and instructions from multiple people
More "swarm"-like
Navigator: "can you X when you get around to it?" 👍
Learnings
Stream's flatMap()
unwrap nested "collections"
vs. map()
Optional as a collection that holds 0 or 1 items
Which means you can .stream() them
Learning how it works
Record conversion was a bit tricky because of the different named query method and field name
Retrospective: Ensemble #101 (Fri May 26, 2023)
-----------------------------------------------
Thoughts, Observations
"Retarget Test"
Do this often after extracting a new class
When testing against Player, the Game isn't involved, so the Dealer isn't relevant
A "micro-test"
aka Solitary
How to organize tests such that they're easy to find?
"Mutation" and code coverage can help
Very different from how production code is organized
Separate test classes don't necessarily help (but can indicate the class is getting too large)
Better test method (and class) names can always help
Thinking about naming of the Game states
Yes, it's a "new game", but is that what we care about? (No, it was that the bets hadn't been placed.)
Looking at who is in charge of "recording" the PlayerDoneEvent
Turns out it's Feature Envy and should be the responsibility of the Player
Learnings
Using Extract Method to extract a Record ("Fixture") and then the method
Hit ENTER while going through the refactoring process
Retrospective: Ensemble #100 (Fri May 19, 2023)
-----------------------------------------------
Thoughts, Observations
Remember Ctrl+F12 (or CMD+F12) to see methods in current class
Transition from Refactor to Behavior Change can be confusing
Replacing Query (isGameOver) with State (using state transitions)
Make State Machine explicit
Domain knowledge is important
playerStateChanged is still confusing
3-minute rotation