REUSE GOOD IDEAS

An extensive industry-based studies investigating the use of creative stimuli

during a brainstorming session at the conceptual stages of design. The creative
stimuli tool is then compared to other creative stimuli tools using objective,
industrially grounded performance criteria. This study provides an arguably
much needed real, industrially-based experiment regarding brainstorming. The
results and observations suggest that having a guided approach to sourcing
creative stimuli is very beneficial. The use of the TRIZ contradiction matrix and
inventive principles is also shown to be a good example of a guided approach
in terms of increasing creative performance. However, the Sweeper tool using
internally sourced stimuli provides a method that is useful and more a practical
alternative, as it is based firmly in the domain of activity.

”.

Tips for writing reusable code

1. Keep the code DRY. Dry means "Don't Repeat Yourself":- This is one of the
main changes I have tried to bring in. Always try to eradicate
duplication and if you find any then move removes the duplication of a
relevant place. Sometimes this has to lead me to create Static Helper
classes or sometimes move it to the class it makes most sense to have
it.
2. Make a class/method did just one thing:- This is along the lines of the advice
of giving the class only one reason to change. This often means
creating methods that other methods use but this helps to make the
methods/classes simple and less coupled.
3. Write unit tests of your classes AND make it easy to test classes:- Writing code that
is easy to test is decoupled. If you write code and are thinking about
writing a unit test of it then you tend to split up the code into
smaller testable chunks.

4. Remove the business logic or main coding away from any framework code:- Following
the rules for will help this. An example I have seen is coding that is
inside Struts Actions classes, this code is practically impossible to
reuse because of all the Struts dependencies that it now linked with.
5. Try to think more abstractly and use Interfaces and Abstract classes:- Try to hide
dependencies on code in a more Generic interface/abstract class. The
benefit this gives the code is it creates a flexible point to the code
where you can then hide future changes behind.
6. Code for extension. Write code that can easily be extended in the future:- This is
particularly true to the above point. If you write code that uses
interfaces then you can extend that interface with a later point.

7. Don't write code that isn't needed:- Do the simplest thing possible. Don't
waste your time adding methods and classes that might be used in the
future. Keep the code simple and focused on what you are trying to
deliver. I think me read/heard Josh Bloch says once that "if in doubt,
leave it out". Basically who wants to write code that no one (including
yourself) is going to use again.
8. Try to reduce coupling:- When writing code think about the links and
coupling the code is creating, does it need to be linked to those other
classes.

9. Be more Modular:- make your code more modular, think modular, be modular.
10. Write code like your code is an External API:- Imagine the code you are
writing is a self contained component.

It wasn't going to be ten until I got to 8 and then thought no one writes 8 tips, lets
add two more on. It isn't really a list but it's sort of aims and mental notes I try tell
myself when writing code. They are more small bits of code I have written recently
that have helped. I would like to hear people's comments and especially their tips for
writing reusable code.
.
Code reused is the use of existing software to deliver
functionality. Code is expensive and time consuming to develop
and code to reuse is considered a
fundamental productivity strategy for information
technology intensive businesses. The following are common
types of code reuse.
1.Off The Shelf
Using commercial or non-commercial products that exist as
opposed to reinventing them.
2.Extension
Extending your current systems, applications, services and
libraries as opposed to doing something completely new.
3.Components
Designing systems and applications to maximize reuse by
dividing functionality into useful components that hide
complexity behind an interface.
4.Libraries
Packages of reusable components designed to be reused by
multiple systems and applications.
5.Services
Wrapping reusable components in service that can be deployed
and operated separately on the rest of your system and
applications. Services reuse both the code and the operational
aspects of a technology. For example, one team can operate
a market data service to a bank as opposed to having 50
systems and applications that connect to market data feeds.
6.Platforms & Frameworks
Environments of developing functionality that may include a
large number of APIs offered as libraries or services.
7.Cut & Paste
It is common for developers to copy code with which they are
familiar and change it to be something new.
8.Forking
Officially taking code and changing it to be something new by
creating a fork in a version control system. For example, a
code base for a scientific calculator might be forked to
create a financial calculator.

The Benefits and Costs of Code Reuse

 Code reuse is often seen as a method to save development time by
cutting project costs and shortening time to market, but it has
several benefits of saving time.
 It allows multiple developers to integrate IP into their code
using similar styles and programming conventions.
 For every application you do you can reuse the generic functions
that you created for the one before. This saves time, improves
the features of your program, and generally makes for more cost-
effective programming. As your libraries grow it becomes easier
and easier to lay the framework of more sophisticated
applications, without any effort at all.
 Integrating IP, whether developed internally or externally,
should never be considered a silver bullet. Code should be
evaluated in terms of being the best solution for a problem and
should not be reused in unintended ways or for the sake of
reusing IP. IP should be assessed on its existing capabilities
and not on the ability to modify its usage, which may result in
productivity losses.