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

Labels:

Comments

Post a Comment

Popular posts from this blog

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

Collaborative Learning at Coderetreats

Written collaboratively by: Trung Vo, Bob Allen, Jacqueline Bilston, Christopher Fietz, Llewellyn Falco “… I really liked that there was something there for every level and anytime I would get stuck, there was someone there to help….” — Sara K. What is a Coderetreat? Coderetreat is a day dedicated to allowing developers time to practice their craft. The focus is on practicing skills like Test-Driven Development (TDD), refactoring, and incremental design that is proven to make developers move faster with fewer bugs. It is designed to enable participants to focus on their practice, with as few distractions as possible. The day is made up of several short sessions where we either work in pairs or mobs to solve a small coding problem. Each session, we start new with the same problem; this allows us to focus on the new skill we are learning. What do you get out of it? Coderetreat is an excellent place to learn what you know and what you don’t know. As in life in general, there are always ne...
Post a Comment
Read more

Code Retreat 2017 retrospective

  In general, this year is much better compared to previous years There are several important points that I need to write down Typically, the main reason for me to do code retreat to help developers in the community to expose more to TDD/craftsmanship. Recently, I asked myself question: “How come it’s not eas y  to adapt TDD, automated testing which should be the core value of any efficient teams?” I don’t think that people is lazy or people is resistance, I think as the industry, there’s lots of ambiguity in how people should approach TDD (SOLID principles, 4 simple rules of design, etc … are too generic) and agile practices (agile manifesto, etc…) How can I apply SOLID, 4 simple rules of design into my day to day jobs? What’s the most important reasons for developers to write automated tests? is it testability design, is it executable documentations?…. what’s the different between integration/component/API tests? should we care? when I discuss about unit tests with QA, typic...
Post a Comment
Read more