Friday, June 14, 2013

Best Practices for Developer Coding skills and Naming convention:


Best Practices for Developer Coding skills and Naming convention: 
 
1.) Project name and application name must discuss with PM and Client .It’s not contains like example, test like etc..


2.) Package name must not contains Android market keywords or Google api keywords. It’s must be com.<Companyname>.<Application Name>.
Eg.
Com.halosys.tvanytime
com.adobe.reader (Adobe Reader)
com.adobe.photoshop (Adobe Photoshop)

(3.)Class name must start with its own core functionality like HomeActivity.
If class contains it’s subclasses in it’s stack then child class name must be
HomeActivity1, HomeActivity2 ….
HomeActivity2 (Not use name like home_detail_screen etc.)

(4.) variable name must contains functionality of it’s own use case.
Eg. Boolean activityFlag;
String usernametf1;
Float submitcal;
Button submitbtn,
ImageButton imgShowbtn;

(5.) Functions / Methods name must be contains with basic functionality name:
SubscriptionCalculation()
LocationCalculation() 
 
(6.)Always try to use concept of OOPs. Basically method-reusability, class reusability.

(7.)Not use more static variables , if using in java then must release them.

(8.) if you inhering the code from web then need to change the naming convention of variables, classes and methods for that particular block.

(9.)Try to use Async task classes always Private mode.

(10.)Need to commented each method of block with that basic functionality.

(11.)Always try to best way for file handling in java. Always close the stream or refresh them also.Try to free gc also when finishing the activity.

(12.) Try to put block of code with one module package.

Com.halosys.tvanytime.facebook

(13.)Must import think in case of sqlite, always close the database and cursor.try to always use finally statement.

(14.) Image name must contains with that function name:

Eg. Submitimg.png

(15.)In case of java, one work have different ways of solution here always try to use best one alternate solution like case of :
Dbhandling
ApiFramework
Native Interface
Etc.

(16.)Event Listener contains four types of handling try to always access ui-thread for access ID.

(17.)Always try to run a thread in save mode in coding, otherwise app crash.

(18.)Always use Stack concept for handling view stack.


Thanks,
Naveen Kumar




















Software Development Life Cycle (SDLC)

SOFTWARE DEVELOPMENT LIFE CYCLE [SDLC] Information:
Software Development Life Cycle, or Software Development Process, defines the steps/stages/phases in the building of software.
There are various kinds of software development models like:
  • Waterfall model
  • Spiral model
  • Iterative and incremental development (like ‘Unified Process’ and ‘Rational Unified Process’)
  • Agile development (like ‘Extreme Programming’ and ‘Scrum’)
Models are evolving with time and the development life cycle can vary significantly from one model to the other. It is beyond the scope of this particular article to discuss each model. However, each model comprises of all or some of the following phases/activities/tasks.
SDLC IN SUMMARY
  • Project Planning
  • Requirements Development
  • Estimation
  • Scheduling
  • Design
  • Coding
  • Test Build/Deployment
  • Unit Testing
  • Integration Testing
  • User Documentation
  • System Testing
  • Acceptance Testing
  • Production Build/Deployment
  • Release
  • Maintenance
SDLC IN DETAIL
  • Project Planning
    • Prepare
    • Review
    • Rework
    • Baseline
    • Revise [if necessary] >> Review >> Rework >> Baseline
  • Requirements Development[Business Requirements and Software/Product Requirements]
    • Develop
    • Review
    • Rework
    • Baseline
    • Revise [if necessary] >> Review >> Rework >> Baseline
  • Estimation[Size / Effort / Cost]
    • <same as the activities/tasks mentioned for Project Planning>
  • Scheduling
    • <same as the activities/tasks mentioned for Project Planning>
  • Designing[ High Level Design and Detail Design]
    • <same as the activities/tasks mentioned for Requirements Development>
  • Coding
    • Code
    • Review
    • Rework
    • Commit
    • Recode [if necessary] >> Review >> Rework >> Commit
  • Test Builds Preparation/Deployment
    • Build/Deployment Plan
      • Prepare
      • Review
      • Rework
      • Baseline
      • Revise [if necessary] >> Review >> Rework >> Baseline
    • Build/Deploy
  • Unit Testing
    • Test Plan
      • Prepare
      • Review
      • Rework
      • Baseline
      • Revise [if necessary] >> Review >> Rework >> Baseline
    • Test Cases/Scripts
      • Prepare
      • Review
      • Rework
      • Baseline
      • Execute
      • Revise [if necessary] >> Review >> Rework >> Baseline >> Execute
  • Integration Testing
    • <same as the activities/tasks mentioned for unit testing>
  • User Documentation
    • Prepare
    • Review
    • Rework
    • Baseline
    • Revise [if necessary] >> Review >> Rework >> Baseline
  • System Testing
    • <same as the activities/tasks mentioned for Unit Testing>
  • Acceptance Testing[ Internal Acceptance Test and External Acceptance Test]
    • <same as the activities/tasks mentioned for Unit Testing>
  • Production Build/Deployment
    • <same as the activities/tasks mentioned for Test Build/Deployment>
  • Release
    • Prepare
    • Review
    • Rework
    • Release
  • Maintenance
    • Recode [Enhance software / Fix bugs]
    • Retest
    • Redeploy
    • Rerelease
Notes:
  • The life cycle mentioned here is NOT set in stone and each phase does not necessarily have to be implemented in the order mentioned.
  • Though SDLC uses the term ‘Development’, it does not focus just on the coding tasks done by developers but incorporates the tasks of all stakeholders, including testers.
There may still be many other activities/ tasks which have not been specifically mentioned above, like Configuration Management. No matter what, it is essential that you clearly understand the software development life cycle your project is following. One issue that is widespread in many projects is that software testers are involved much later in the life cycle, due to which they lack visibility and authority (which ultimately compromises software quality).