4 Developers – presentations overview part I

This is my first post on this blog – Me (Maciej Gren), Peter Horsten and Kuba have decided to join our ideas and share them here. Probably, in the near future some new people will join this blog to express their own thoughts here. First of all, it was a long day. We started at 9 with registering at the conference – 4Developers. Me, as a .Net developer and currently Operational Manager,decided to attend mainly the .Net track. First presentation – F# Very nice and witty speaker – Ted Neward presented F# in the easiest way possible, and explained how to use it. In 1 hour he managed to convince me to research more on F# because of its easy syntax and the way it handles the parallel threads (more natural). What I am only not fully sure about is whether the code maintenance can be hard due to a very flexible syntax and ability to code without a pure object oriented approach (but I may be wrong). What I’m also concerned about, is how to use it with the applications. Should I use it for the entire code behind or only in parts were I need complex math or parallel features enabled? We will see. The presentation was successful and urged me to read Ted’s books even. “The power of refactoring” Firstly, whenever I listen to a lecture about the code I become quite demanding with my expectations. Therefore, I was listening really carefully to all information related to “when”, “how”, and “how much” refactoring is necessary. I appreciate the work done by Stefan Koopmanschap because he outlined the basics of the refactoring and answered all the basic questions like “when to refactor?”, “who should refactor?” etc. One general question came to my mind during this presentation:”what is the biggest advantage of refactoring?” The answer is-it gives more clarity and better maintainability. It is also worth bearing in mind that if you want to establish whether you are rewriting or refactoring – simply check if the documentation of the code changed afterwards. If yes – it was rewriting. If not – it was refactoring. The second important thing is that we cannot call our work refactoring till we have test coverage of the code we have written. This is the only way to make sure that after our ‘improvements’ we did not damage anything. Thanks Stefan, and I wish you a good refactoring.

IT guy with head full of ideas, strongly oriented on achieving great goals in life. Currently working for Aspire Systems Poland, place where I grow.