Skip to main content

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 easy 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, typical answers I get is that it’s programmer tests? IT’S SO NOT TRUE? It does contain many behaviors of the systems, some behaviors are at very low level and business people shouldn’t care about, but I believe MOST OF THE BEHAVIORS could and should be expressed at high level domain language and can be used as executable documentation for different stakeholders such as QA/Non technical people. Should we call those tests as behavior unit tests instead of unit tests?

How can we make the TDD/Refactor/agile practices easier for people to adapt?

  • Maybe, shrink the change?
  • Maybe, there’s lots of things can go wrong but there’s few things that you got to get it right, so script critical moves?
  • Maybe, Looking for bright spot (examples) so people can see the benefits and start small?
  • Maybe, tweak the environments to encourage the right behavior and discourage the wrong behavior?

I think code retreat is one of the good place for me to find the answer to that question.

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

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