1. My experience with managing chaos in a large project By Daniil Kigelman

2. Vlab portal

3. What is VLab? Don’t ask me--I’m just a developer I’ve heard it has to do with chemistry and planetary materials My work with VLab has been focused around portlets –Portlets: small little creatures that live inside a portlet container they sit behind the portal login mechanism –The concept of a portal and its portlets is quite simple--its implementation.. Not so much. The VLab portal aids the user in creating PWscf input, submitting jobs, monitoring the progress, and viewing the results http://www.vlab.msi.umn.edu

4. My visible work

5. Difficulties 30,000+ lines of code Outdated code –Some need to be deleted, some changed/updated Overgrown code –Large objects, long methods Volatile code –A small change in a name, version, or in the code may break the portal Numerous technologies used –Web services –Castor –Gridsphere –JSF, JSP –Java Database Connectivity (JDBC) –Hibernate –Connection Pooling –Subversion, maven, ant, etc…

6. Priceless tool: Eclipse IDE Rapid development Code search, highlighting, code insight Refactoring, code generation tools Much, much more

7. Attempted Solution : using more of maven 2’s features “ Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.” (maven.apache.org) Only for java-based projects.. Benefits: divide, conquer, and reuse: –vlab-portal |- vlab-base |- vlab-common |- vlab-portlets |- pseudo-potential-webapp `- input portlet –(vlab-common and vlab-base are reused by other modules) Explicitly defines dependency versions Transitive dependency management Site generation

8. Another solution: asking for advice from co-workers Benefits: – More fun to work ^ much –More insight into design (I don’t know which parts are confusing—I wrote them) –More wisdom Relevant eXtreme Programming principles: –Work together –Pair programming –Code review

9. Better Objects, cleaner code Assertion: good object- oriented code saves sanity Tool: Refactoring by Martin Fowler –Objects and complexity naturally grow to difficult proportions –The original design, more often than not, does not satisfy the need of the growing code –Hence, refactor as you code rename method rename class extract method extract class

10. Examples in context Idioms: –small method sizes with descriptive names –focus on readability, not efficiency Assumption: test suite present

11. Testing Unit testing –code that tests the smallest unit's proper functionality –increases confidence in code, trust –facilitates refactoring and other changes Acceptance / functional testing –manual: go to website, click through pages—is anything broken? –automated: execute test suite, take coffee break. Is anything broken?

12. –copied from: http://xprogramming.com/xpmag/testFirstGuidelines.htm Test-first development The name of the test should describe the requirement of the code There should be at least one test for each requirement of the code. Each possible path through of the code is a different requirement Only write the simplest possible code to get the test to pass, if you know this code to be incomplete, write another test that demonstrates what else the code needs to do If you are unsure about a piece of code, add a test you think might break it Do not fix a bug until you have written a test that demonstrates the bug

13. Incremental Changes Refactor, test, code, test Small changes first Refactor to understand

14. Overview The following I found helpful in keeping my sanity: –Eclipse IDE –Maven (project organization) –Refactoring –Testing (especially automated) –Small, incremental changes –Co-workers Source forget project: http://sourceforge.net/projects/vlab svn repository url https://vlab.svn.sourceforge.net/svnroot/vlab/br anches/demo_with_maven2 Beck, Kent. Extreme Programming Explained: Embrace Change. Addison-Wesley. Second Edition 2005 with Cynthia Andres. Fowler, Martin. Refactoring: improving the design of existing code. Addison-Wesley, 1999. Shubin, Sean. Test First Guidelines. XProgramming.com: an Agile Software Development Resource. 2002. http://www.xprogramming.com/xpmag/testFirstGuidelines.htm http://www.xprogramming.com/xpmag/testFirstGuidelines.htm