Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

bringing modularity in the java project

 
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hello everybody ,

I and some of colleagues is assigned with one java projects which we have divided into modules like sales module, purchase module , reports module. however the problems is how to implement in practical the modularity. for eg. report section will need values coming from other modules however at the time of development that module is also in development.

So i want to know how each of us work independently on our module without affectiong from others work. and how concurrent versioning system can help it to us in this regard.. i haven't used it till now.
please tell me how to use cvs in the system.

Thanks

waiting for kind opinion

Gaurav Nigam
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One important aspect to design is to manage dependencies. Circular dependencies will kill you - team A needs B's code to compile and B needs A's code to compile. Look at your modules carefully and decide which way you want compile time dependencies to run. It's not necessarily the same direction as the flow of control or the flow of data.

To work in separate teams with separate code baselines you should try to aim for stable interfaces. Once you publish a method to another team, try hard not to change the signature. To really enforce discipline you might have each team make compiled jars available to the others, but no source code. Imagine you are separate companies selling shrink-wrapped products.

It's a neat strategy to implement the public API for each module in a 'facade' class that you can throw together very quickly so the other teams can compile. You can even stub out methods so other teams can call it and get some kind of hard-coded results. Then you can implement the real logic at your own pace. I worked on one project with this approach and we could call the ModuleX guys and say "Hey, I need a new getWidget method from you". They could add it to the interface and publish it with stub data in a matter of minutes. It might not actually do anything for a couple days, though.

Of course that sounded the opposite of stable interface, didn't it? If everybody is working closely together you can negotiate a change at any time.

Any of that sound useful? Scroll down to the OO, UML, etc forum to talk more about design ideas around dependencies and the facade concept.
[ October 06, 2005: Message edited by: Stan James ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Some additional strategies to reduce conflicts:

- use a good version control system. Modern systems are very effective at merging changes.
- integrate (that is, update and commit) several times a day. The more often you integrate, the less likely you get conflicts.
- collocate the developers. If they are all sitting in one room, it's easy to know who is working on what, and to resolve conflicts should they arise.
- daily stand up meetings increase the knowledge on who is working on what, and thereby makes it easier to prevent conflicts.
- pair programming does so even more, and additionally reduces the amount of parallel programming done, while at the same time increasing your productivity

In a small team, applying some of those strategies should suffice to make it save having all team members work on the same code base without being slowed down by regular code clonflicts. Which doesn't mean that managing your code dependencies becomes unimportant, of course...
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Moving to our Process forum...
 
Manish Sridharan
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks everybody for their kind advice . i will follow ur advice to the maximum.. one more thing i like to know about where do i find and versioning system and how to integrate into the project...
please help....

Thanks

Gaurav Nigam
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Gaurav Nigam:
one more thing i like to know about where do i find and versioning system and how to integrate into the project...



If you are searching for something free, I'd definitely go with Subversion. For more info, you should probably start a new thread in our "IDE's, Version Control and other Tools" forum...
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Note that Ilja and I gave pretty different answers. I was remembering prior school projects that I did online with partners all over the country. We never met face to face and rarely even got online at the same time to IM. He was talking about people in a room together or at least in very close contact.

Do you expect to be working in one of those styles or maybe some other?
 
it's a teeny, tiny, wafer thin ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!