Guideline for SCJD2 Exam

Guideline for SCJD2 Exam
by our honor member, Sun cerified Java developer
Shashank Tanksali

Introduction

Sun Certified Developer for the Java?2 PlatFORM exam Number 310-027, available July 31, 1999

The Sun Certified Java developer examination is a practical exam rather than an objective exam.Given below are some of the dos and dont@#s of SCJD.

---

Who should take up SCJD

Technically speaking, only those who have completed their SCJP can take SCJD. Anybody who wants to go beyond mere programming skills and learn all aspec?ts of a complete development process can take up SCJD. SCJD is equally useful for both an experienced software professional, who wants to keep his knowledge level current. It is also useful for software professionals, who have non java related work experience, but would like to switch to Java. It is also extremely useful for people with no prior software development experience, as it gives them an opportunity to demonstrate their skills to prospective employers. For people, who want to experience the full software development process and who especially like perFORMance based exams, SCJD is ideal.

---

What will I get with SCJD

SCJD is a third party validation of your development skills, and who better than the originators of Java can validate your skills. Since SCJD is a complete project assignment and not just a knowledge based examination, the process matters more than the end result. With SCJD, a person refines his analytical skills, decision making skills and of course programming skills.Also since there is no time limit, anybody can take up SCJD to suit their own work schedules. Overall once you have completed SCJD, you will find yourself a better developer, who can use Java in conjunction with all the other skills required to develop great software.

---

Approach to SCJD

The objective of the SCJD exam is not to get the assignment working, but rather to enjoy the experience of learning new technologies, analyzing requirements,making suitable assumptions, designing a system,learning design patterns and in general developing an entire application alone. The good thing about the SCJD exam is that it is full of ambiguities, incomplete specifications etc, which force you to think and decide what needs to be done.It is this experience, which will be rewarding in the long run.
Many people cannot resist the temptation to start coding and directly jump to coding. Coding should be considered only after the entire design has been finalized, and it should be a mechanical process to translate a good design to Java code.

---

SCJD Checklist
This is not an exhaustive checklist, but it should give some inFORMation about what needs to be completed before the project submission.

　　
• 
  Are all the assumptions made in 　　　　the project clearly documented ?
  　　　　The examiner should not have to guess what assumptions 　　　　you made. If you made an assumption, it should be clearly 　　　　documented in the submitted document. It might be even 　　　　better to have an assumptions section in the document, so 　　　　that the examiner clearly knows what you had in mind, 　　　　when you designed the system. The best way to keep track 　　　　of assumptions made is to put them in a document, as and 　　　　when the assumptions are made. Documentation is not 　　　　something done at the end, rather it should be done in 　　　　parallel with development.　　

　　
• 
  Is a suitable package structure 　　　　used for the project assignment ?
  　　　　Java classes which logically belong together should go 　　　　into a separate package.　　
• 
  Is finally used in all the 　　　　appropriate places ?
  　　　　For example, if a client acquires a lock and then due to 　　　　some reason, there is an exception, the client should 　　　　release the lock before returning, immaterial of whether 　　　　there was an exception or not.　　
• 
  Are the Javadoc comments written 　　　　on the same lines as the api documentation ?　　
• 
  What is the exception handling 　　　　mechanism used ?
  　　　　Do exceptions cascade all the way to the top or are they 　　　　handled where they can potentially oclearcase/" target="_blank" >ccur ? An end user 　　　　should not be forced to handle an internal exception, if 　　　　it is of no interest to him.　　
• 
  Is the atomicity in the 　　　　application guaranteed ?
  　　　　Atomicity in short is either everything or nothing. So if 　　　　a booking is taking place for a flight and a record is 　　　　locked, either the booking should go through or if the 　　　　number of seats etc are not available, the entire 　　　　transaction should be rolled back. The database should 　　　　not be left in an inconsistent state even if the 　　　　application crashes.　　
• 
  Is the user documentation clear 　　　　enough to allow anybody to use the system ?
  　　　　The preferred way to package applications is by 　　　　using executable jar files. With executable jar files, 　　　　the classpath etc need not be set. Executable jar files 　　　　are a new feature in Java 2, and it makes sense to use 　　　　it.　　
• 
  Documenting design decisions
  　　　　Are all the design decisions clearly documented. 　　　　When a design decision is documented, the alternatives 　　　　considered, their relative merits and demerits need to be 　　　　also documented. Basically the examiner is interested in 　　　　knowing why you chose a particular approach over 　　　　another.Design decisions should be briefly and clearly 　　　　explained and should not run into several pages.　　
• 
  Use of standard design patterns
  　　　　Whereever possible, use design patterns. Design 　　　　patterns are tried and tested ways of accomplishing a 　　　　particular task. Using design patterns tells the examiner 　　　　that you have done your homework.　　
• 
  Error handling
  　　　　Do not expect sensible data to be provided to 　　　　your application always. How does the data converter 　　　　behave if the data supplied to it does not match the 　　　　schema supplied ? What happens if a negative number or a 　　　　non numberic value is entered for the number of seats ? 　　　　For example if the 20th row in the input data file for 　　　　the data converter is wrong,the data converter should 　　　　either skip the row, log an error and continue, or it 　　　　should give an option to the user to choose an action 　　　　(either abort entire conversion or skip bad record). The 　　　　data converter should not load 19 records, throw an 　　　　exception and exit.
  　　　　Also document clearly, the expected outcome in case of an 　　　　error. For example, you might document that the data 　　　　converter ignores bad data.　　
• 
  Code clarity
  　　　　The best comment you can write is readable code. 　　　　With readable code, there is no need to write comments.　　
• 
  Is the indentation uniFORM all 　　　　over the code and according to the java standards ?
  　　　　There is nothing more annoying than seeing 　　　　several files all using a separate coding style. Read the 　　　　java coding standards (as it will be enormously helpful 　　　　in the professional career as well) and ensure 　　　　indentation across all the java classes is consistent.　　
• 
  Testing the application
  　　　　Testing an application should start when 　　　　individual classes are developed. It is better to prepare 　　　　an entire suite of test programs (not to be included in 　　　　the submission) to test the application. Sometimes, it 　　　　might be useful to ask a friend etc to use the system to 　　　　uncover any possible faults in the system. For example, 　　　　when asked my friend entered the number of seats as 5 　　　　followed by a space. I was not doing a trim on the 　　　　entered value, which caused an exception to be thrown. 　　　　Asking others to use the system without an prior 　　　　knowledge can uncover bugs, which we might not have 　　　　thought of.　　
• 
  Use intuitive field names
  　　　　Except for loop indexes etc, intuitive field 　　　　names should almost always be used. originFlight gives a 　　　　lot more meaning than origFlt for example.　　
• 
  Ask yourself why this approach ? 　　　　What are the alternatives ?
  　　　　For every single design decision that you make 　　　　in the assignment, ask yourself what are the alternatives 　　　　? What are the advantages of the chosen approach over the 　　　　other approaches ? For example, why sub classing, why 　　　　RMI, why singleton etc　　
• 
  Make interfaces where appropriate
  　　　　Wherever possible, consider using interfaces 　　　　instead of classes. For example, consider if having a 　　　　DBInterface and a class which implements it is better, as 　　　　dealing with interfaces will allow you to change the 　　　　implementing class at any time. Similarly do not directly 　　　　refer to a Hashtable, instead refer to a Map with Map m = 　　　　new Hashtable() ; This allows you to switch from a 　　　　Hashtable to a HashMap at any time, without affecting 　　　　anything else.　　
• 
  If using Object serialization, 　　　　clearly document the serializable fields　　
• 
  Wherever possible, implement 　　　　Runnable instead of extending Thread.
  　　　　This allows you to keep the one chance that you 　　　　have to extend any class sometime later.　　
• 
  Sensible server output log
  　　　　Ensure that the output of the server is sensible 　　　　and does not include any output of no concern to a server 　　　　administrator, for example debug statements etc should 　　　　not be part of the server output. However critical errors 　　　　etc, should always be logged.　　
• 
  Write consistent code
  　　　　It should be obvious from the code, that it is 　　　　written by a single individual. Do not for example, use
  　　　　import java.util.* ; in a java file and import 　　　　java.util.Vector; in another file. It is recommended that 　　　　any classes used are explicitly imported, so that by 　　　　looking at the top of any java file, it is obvious, what 　　　　classes are used in that file. Also group together all 　　　　public members first, protected members next, package 　　　　members next and finally private members in all the java 　　　　files.　　
• 
  If there is any cleanup to be 　　　　done in any class, is finalize being used ?　　
• 
  Are all the server classes 　　　　threadsafe ?
  　　　　Write a multi threaded program to simulate several users 　　　　and connect to the database server with it to test if the 　　　　server is threadsafe.　　
• 
  Test separately in local mode and 　　　.network mode.　　
• 
  Look for the non obvious
  　　　　For example in the FBN assignment, deleted 　　　　records are just marked for deletion and are not actually 　　　　removed from the underlying database. What will happen if 　　　　an attempt is made to insert a record with a key 　　　　belonging to a record marked for deletion.　　
• 
  If any method like getRecord() 　　　　returns null, is it being appropriately handled ?　　
• 
  Consider using meaningful names 　　　　for boolean variables.
  　　　　For example, if you have a boolean record status 　　　　attribute in a lock class, a value of LOCKED and UNLOCKED 　　　　is more descriptive rather than true or false. These 　　　　variables can be defined as static final constants in an 　　　　interface or the class itself.　　
• 
  Ensure the method signatures are 　　　　the most restrictive.
  　　　　Changing a method signature from most 　　　　restrictive to less restrictive can be done at any time 　　　　without breaking any existing code, but the other way 　　　　cannot be done easily. Once a public interface is 　　　　exposed, making it more restrictive may break some 　　　　existing code. Never use public data members unless 　　　　absolutely necessary, instead use accessors.

原文转自：http://www.ltesting.net