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

Comments

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

How to Win Friends and Influence People summary

Principles Fundamental techniques in dealing with people Don't criticize, condemn or complain. This makes them defensive and justifies their actions. Instead, praising them lowers their defense and they will be more receptive to your feedback. give honest and sincere appreciation arouse in the other person an eager want. become genuinely interested in other people i.e.: remember other people's birthdays send linkedin messages of congratulations when someone in your network gets a promotion or professional success coordinate office parties for personal celebrations such as births, accomplishments or birthdays. people crave the feeling of importance. "What is there about him that I can honestly admire?" appeal to the other person's interests. Virtually all people care more about what they want than what you want keep asking yourself - "what is it that this person wants?" everyone has something they can teach you, and you benefit by figuring out what that i...

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