I have found that if you try to be lazy then you would use AOP and annotations more. I try to be lazy and my blood boil when DRY being violated in the code. My goal is to how to make code simple yet powerful and try to hide complexity from an average developer and if the complexity cant be avoided then keep it in a single layer as much as possible.
AOP allows you to hide the compexity in a single layer transparent to an average junior developer. For e.g.
1) I was given a requirement to allow X no of Read and Y no of Write request per node as Berkely db couldnt handle >X+Y requests. So AOP helped me sort it out. I created an interceptor MetadataThrottlingInterceptor and created two annotations @MetadataWriter and @MetadataReader. So I just annotated the methods in the storage layer with these annoatations and used a threadpool in the Interceptor class to limit the read/write request. This allowed me to hide the complexity in a layer and transparent to the developer. A junior developer now has to only annotate new methods with read/write and if he is not curious he wouldnt even know what these are for.
2) I was given a requirement to track performance of methods of a particular class in Graphite. The problem was that in future developers can add more methods and add more code and what if they move code around and that can lead to wrong numbers being reported. So I just created a PerfInterceptor and added @PerfIntercepted annotation to every method that we wanted to track. Again being lazy helped me to hide the complexity.
3) I added sharding to our storage layer and again I wanted to hide the complexity of sharding to an average developer so I created a MetadataShardingInterceptor and it automatically handles selection of shard. The sql is assumed to written like
select * from ${SCHEMA_NAME}.files_${SHARD_NUMBER}.
The assumption is that every method would contain a customer argument and the AOP layer derives the shard metadata and does replacement transparent to junior developer.
So as you start to think in direction of making life easy for your team or be lazy to avoid DRY violation you tend to use more of AOP and annotation.
AOP allows you to hide the compexity in a single layer transparent to an average junior developer. For e.g.
1) I was given a requirement to allow X no of Read and Y no of Write request per node as Berkely db couldnt handle >X+Y requests. So AOP helped me sort it out. I created an interceptor MetadataThrottlingInterceptor and created two annotations @MetadataWriter and @MetadataReader. So I just annotated the methods in the storage layer with these annoatations and used a threadpool in the Interceptor class to limit the read/write request. This allowed me to hide the complexity in a layer and transparent to the developer. A junior developer now has to only annotate new methods with read/write and if he is not curious he wouldnt even know what these are for.
2) I was given a requirement to track performance of methods of a particular class in Graphite. The problem was that in future developers can add more methods and add more code and what if they move code around and that can lead to wrong numbers being reported. So I just created a PerfInterceptor and added @PerfIntercepted annotation to every method that we wanted to track. Again being lazy helped me to hide the complexity.
3) I added sharding to our storage layer and again I wanted to hide the complexity of sharding to an average developer so I created a MetadataShardingInterceptor and it automatically handles selection of shard. The sql is assumed to written like
select * from ${SCHEMA_NAME}.files_${SHARD_NUMBER}.
The assumption is that every method would contain a customer argument and the AOP layer derives the shard metadata and does replacement transparent to junior developer.
So as you start to think in direction of making life easy for your team or be lazy to avoid DRY violation you tend to use more of AOP and annotation.
Comments
Post a Comment