|
Now Joe says "Instead, all requirements should be given to the class's owner, who should implement them." Well, no. That would mean I could only give the new programmer complete classes to write, which is too much for a beginner to attempt. In most development environments, requirements for changes often arise that are reasonably simple for anyone to implement; there should be no management rule that requires the class owner to implement them. VAJ Enterprise does require the class owner to approve them, and that's a perfectly reasonable rule. ----- Sorry, but this doesn't change the point: you should never have two programmers in the same class at the same time. In your case, you are temporarily transferring ownership to the new guy, not opening it up for both of you to be making modifications at the same time. Allowing one programmer to temporarily own a class is fine. Having two programmers working in the same class at the same time is bad. You're doing the former (I hope). If, however, you're making changes in a class at the same time that the "new programmer" is, you're defeating the purposes of sound development, and sound teaching. Anyway, this example does not, in my mind, argue for concurrent development. However, we're treading dangerously close to the opinion neighborhood, where all viewpoints are valid, so I'm content to let this drop. If you ask me, there is no good reason for two developers in a single class at the same time, ever. There are occasionally reasons of expedience that require this, but never, never should it be part of the regular development. If you want to argue this in more detail, feel free to drop me an email. Also, this argument may not hold depending on your design philosophy. My largest class is 500 lines long, with some 200 lines of that as comments. My median class size is under 100 lines of code. This makes it almost silly for two developers to ever be inside one of my classes. If your class size is regularly 1000's of lines, then you will have a different development methodology. However, any Java class over 1000 lines of code needs to be carefully reviewed. Take as an example IBM's Java Toolbox for the AS/400: though it has some 1500 or so classes, only about 50 (or 3%) have over 1000 lines of code (including lots of comments). Interestingly, the majority of those classes are either JDBC support or visual access. And even with those huge classes, the median class size in the tool box is around 150 lines (again, including comments). Joe +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.