Skip to main content

Sudoku refactoring

 

Sudoku Refactoring Kata

Following Jay and Llewellyn on their sudoku refactoring, I have forked the sudoku repo and added the java version. As usual, I will post the snippets I found useful in doing the refactoring

Snippets

  • Golden Master
  • Extract Method
  • Extract anonymous class to named class
  • Delete Comments
  • convert parameters to object
  • move the inner class to upper level
  • specify type explicitly
  • transform out parameters to object
  • move types to matching files
  • inline variable
  • extract variable
  • move line above
  • move method to a different class
  • replace static with non-static
  • split variable declaration assignment
  • move method to the constructor
  • isolate field assignment
  • remove unused directives
  • extract constant
  • extract class from a field
  • return value early
  • remove redundant else
  • surround with block
  • asas
  • asas

References

Jay and Llewellyn Series on Sudoku Refactoring

https://www.youtube.com/watch?v=BVGH-dNn-tc&ab_channel=LlewellynFalco
https://www.youtube.com/watch?v=8dyZHMuCiKc&ab_channel=LlewellynFalco
https://www.youtube.com/watch?v=WvSr6E-cO9M&ab_channel=LlewellynFalco
https://www.youtube.com/watch?v=GU_8eMJ8Xd0&ab_channel=LlewellynFalco
https://www.youtube.com/watch?v=f2mZ7v9O3c8&ab_channel=LlewellynFalco
https://www.youtube.com/watch?v=SUgp-msVqnA&ab_channel=LlewellynFalco

Labels:

Comments

Post a Comment

Popular posts from this blog

growing object oriented software, guided by tests summary

Key ideas practice TDD as a design technique and not as a testing technique Software development as a learning process. Expose uncertainly early by testing our assumption as early as possible we use mock objects to identify the essential interactions between modules/objects. This leads to more effective abstractions, which reduces the cost of changing the cost safely over time. Stub queries; expect actions??? Write code that depends as little as possible on its context. programming by intention Test-Driven Development (TDD) and Quality Software development as a learning process. The best approach a team can take is to use empirical feedback to learn about the system and its use and then apply it back to the system. Development is incremental and iterative. Incremental development builds a system feature by feature. Each feature is implemented as an end-to-end slice. As a result, the system is continuously integrated and ready for deployment. A system is deployable when the acceptance t...
Post a Comment
Read more

What’s a simple way to share and learn refactor?

  I have been organizing coderetreat and creating screencasts on refactoring and TDD, etc… however, I find it takes lots of time and effort to organize, preparing and facilitate. (it’s not that I complain about it as a matter of fact I love it every single second and I’m amazed at how much I have learned from the community) I have been asking myself, what’s the simpler way for me to learn to refactor and share with others? (why refactor, you may ask? it’s because it’s my favourite topic in the long never-ending list of agile technical practices) and for some reason, I really like to share my boring meme jokes, so I guess why not share a list of animated gifs of refactoring and the motivation of it. I guess since I’m an Asian guy (hopefully some kind of descendants from Bruce Lee) so this saying is pretty cool to me: “I fear not the man who has practiced 10,000 different kicks once, but I fear the man who has practiced one kick 10,000 times.” Another way to look at it, from J.B Rain...
Post a Comment
Read more

implementing domain driven design summary

DDD overview anatomy of domain-driven design Putting the model to work Domain-Driven Design is an approach to the development of complex software in which we: Focus on the core domain Explore the models in a creative collaboration of domain practitioners speak a ubiquitous language within an explicitly bounded context. Bounded Context Explicitly define the context within which a model applies. Explicitly set boundaries in team organization, usage within specific application parts, and physical manifestations such as code bases and database schemas. Apply continuous integration to keep the model concepts and terms strictly consistent within these bounds, but don't be distracted or confused by issues outside.  Ubiquitous Language Use the model as the backbone of a language. Then, commit the team to exercise that language relentlessly in all communication within the team and in the code.   Use the same language in diagrams, writing, and speech within a bounded context. Recognize ...
Post a Comment
Read more