Comments on: Is Your Code Worthy Of Being Improved http://www.skorks.com/2009/08/is-your-code-wthy-of-being-improvedor/ For the betterment of the software craft... Mon, 21 Nov 2011 13:57:06 +0000 hourly 1 http://wordpress.org/?v=3.1.2 By: Alan Skorkinhttp://www.skorks.com/2009/08/is-your-code-wthy-of-being-improvedor/comment-page-1/#comment-2062 Alan Skorkin Sat, 15 Aug 2009 01:53:07 +0000 http://www.skorks.com/?p=1008#comment-2062 I'll have a look at autowiring for demarcating transactions, always happy to give my 'prejudices' a once over :). And you're right judicious use is the order of the day, don't walk blindly into using any non-trivial library, know why you need it and how to apply it. Funny you should mention new people, I started drafting up some of my thoughts regarding that last night :). You're right though, new people will tend to always question everything, but you expect that to settle down to manageable levels eventually, if it doesn't something is wrong either with the people or with the team/environment (it is a distinct possibility). I’ll have a look at autowiring for demarcating transactions, always happy to give my ‘prejudices’ a once over :).

And you’re right judicious use is the order of the day, don’t walk blindly into using any non-trivial library, know why you need it and how to apply it.

Funny you should mention new people, I started drafting up some of my thoughts regarding that last night :). You’re right though, new people will tend to always question everything, but you expect that to settle down to manageable levels eventually, if it doesn’t something is wrong either with the people or with the team/environment (it is a distinct possibility).

]]> By: Markhttp://www.skorks.com/2009/08/is-your-code-wthy-of-being-improvedor/comment-page-1/#comment-2061 Mark Sat, 15 Aug 2009 01:44:45 +0000 http://www.skorks.com/?p=1008#comment-2061 Try using Transaction Demarcation without Autowiring. I hardly use autowiring, but I do in this instance. It removes tons of config info. I currently only use it for Services (injecting the repositories) and Repositories (injecting the persistance manager). It is pretty obvious what is going on because I am using Annotations. As for AOP - yes use it wisely. Same for IoC. These are powerful concepts. ORM is about the same. The problem is that in not using them the result is code bloat and thus reduces maintainability. Other than that, I totally agree. I think you'd be fine with the Autowiring the things i mentioned. Funny how I spent the last few days making up a list of things we need to cover in walkthroughs (no, we don't have them NOR pair programming) for my new team. It matches a bunch of what you said. As for new people - they don't like anything. And if they always remain new people ... time for new people. LOL. Try using Transaction Demarcation without Autowiring. I hardly use autowiring, but I do in this instance. It removes tons of config info. I currently only use it for Services (injecting the repositories) and Repositories (injecting the persistance manager). It is pretty obvious what is going on because I am using Annotations.

As for AOP – yes use it wisely. Same for IoC. These are powerful concepts. ORM is about the same. The problem is that in not using them the result is code bloat and thus reduces maintainability.

Other than that, I totally agree. I think you’d be fine with the Autowiring the things i mentioned.

Funny how I spent the last few days making up a list of things we need to cover in walkthroughs (no, we don’t have them NOR pair programming) for my new team. It matches a bunch of what you said.

As for new people – they don’t like anything. And if they always remain new people … time for new people. LOL.

]]> By: Alan Skorkinhttp://www.skorks.com/2009/08/is-your-code-wthy-of-being-improvedor/comment-page-1/#comment-2060 Alan Skorkin Sat, 15 Aug 2009 01:19:09 +0000 http://www.skorks.com/?p=1008#comment-2060 I don't have anything against dependency injection in general, it is only the autowiring aspect that I have a problem with. When you're trying to figure out what a piece of code is doing, if everything is autowired, you have to carefully trace what what is actually occurring, if everything is explicit your configuration becomes a great help rather than a useless file. I don’t have anything against dependency injection in general, it is only the autowiring aspect that I have a problem with. When you’re trying to figure out what a piece of code is doing, if everything is autowired, you have to carefully trace what what is actually occurring, if everything is explicit your configuration becomes a great help rather than a useless file.

]]> By: Greghttp://www.skorks.com/2009/08/is-your-code-wthy-of-being-improvedor/comment-page-1/#comment-2059 Greg Sat, 15 Aug 2009 01:06:33 +0000 http://www.skorks.com/?p=1008#comment-2059 Other than your ill thoughtout rant against spring and aspectj I completely agree with you about code "style". When ever you have an object that needs to access an application scope resource then it is bad for that object to know too much about how to get that object, or even to have some knowledge of how it is created. Most people use singletons or factory classes for these cases. Using spring, aspectj, and Autowiring are perfect for these situations. The Object just knows it needs an X and when it gets created it has an X. The creation and configuration of X is done completely independently from any of the objects that depend on it, and this makes your code much easier to read, write, and debug. And if you use Interfaces properly and have a well designed API then you can swap out implementations of X seamlessly. Thats just one situation, that from what I have seen happens quite often. Other than your ill thoughtout rant against spring and aspectj I completely agree with you about code “style”. When ever you have an object that needs to access an application scope resource then it is bad for that object to know too much about how to get that object, or even to have some knowledge of how it is created. Most people use singletons or factory classes for these cases. Using spring, aspectj, and Autowiring are perfect for these situations. The Object just knows it needs an X and when it gets created it has an X. The creation and configuration of X is done completely independently from any of the objects that depend on it, and this makes your code much easier to read, write, and debug. And if you use Interfaces properly and have a well designed API then you can swap out implementations of X seamlessly. Thats just one situation, that from what I have seen happens quite often.

]]> By: Daily Links for Thursday, August 13th, 2009http://www.skorks.com/2009/08/is-your-code-wthy-of-being-improvedor/comment-page-1/#comment-2029 Daily Links for Thursday, August 13th, 2009 Thu, 13 Aug 2009 11:32:35 +0000 http://www.skorks.com/?p=1008#comment-2029 [...] Is Your Code Worthy Of Being Improved [...] [...] Is Your Code Worthy Of Being Improved [...]

]]> By: Alan Skorkinhttp://www.skorks.com/2009/08/is-your-code-wthy-of-being-improvedor/comment-page-1/#comment-2025 Alan Skorkin Thu, 13 Aug 2009 10:45:01 +0000 http://www.skorks.com/?p=1008#comment-2025 Excellent advice, and whenever you do encounter nice code, always remember to take something away from it, don't just admire and go back to doing things the way you always have. Excellent advice, and whenever you do encounter nice code, always remember to take something away from it, don’t just admire and go back to doing things the way you always have.

]]> By: Travis Dunnhttp://www.skorks.com/2009/08/is-your-code-wthy-of-being-improvedor/comment-page-1/#comment-2023 Travis Dunn Thu, 13 Aug 2009 10:35:47 +0000 http://www.skorks.com/?p=1008#comment-2023 > The way to get others to leave your code in a better state than they found it, is to make it worthy of improvement in the first place! i.e. lead by example, and allow yourself to be shamed (I mean "inspired") into improvement whenever you encounter elegantly structured code. > The way to get others to leave your code in a better state than they found it, is to make it worthy of improvement in the first place!

i.e. lead by example, and allow yourself to be shamed (I mean “inspired”) into improvement whenever you encounter elegantly structured code.

]]> By: Dew Drop – August 12, 2009 | Alvin Ashcraft's Morning Dewhttp://www.skorks.com/2009/08/is-your-code-wthy-of-being-improvedor/comment-page-1/#comment-2011 Dew Drop – August 12, 2009 | Alvin Ashcraft's Morning Dew Wed, 12 Aug 2009 12:43:23 +0000 http://www.skorks.com/?p=1008#comment-2011 [...] Is Your Code Worthy Of Being Improved (Alan Skorkin) [...] [...] Is Your Code Worthy Of Being Improved (Alan Skorkin) [...]

]]> By: Alan Skorkinhttp://www.skorks.com/2009/08/is-your-code-wthy-of-being-improvedor/comment-page-1/#comment-2008 Alan Skorkin Wed, 12 Aug 2009 12:27:02 +0000 http://www.skorks.com/?p=1008#comment-2008 I've got my copy :). I’ve got my copy :).

]]> By: andhapphttp://www.skorks.com/2009/08/is-your-code-wthy-of-being-improvedor/comment-page-1/#comment-2007 andhapp Wed, 12 Aug 2009 10:48:58 +0000 http://www.skorks.com/?p=1008#comment-2007 I would recommend reading Clean Code by Uncle Bob. I would recommend reading Clean Code by Uncle Bob.

]]>