Object Oriented Software Engineering   View all facts   Glossary   Help

subject > person or group > person > stakeholder > software developer > programmer

programmer
subject			fact

programmer	can write comments before writing the code
	is responsible for anticipating things that can go wrong and writing exception handling code in preparation
	is a subtopic of 1.7 - Activities Common to Software Projects
	is a subtopic of Programming Style Guidelines
	is a kind of software developer
	may also design the system
	may have difficulty thinking at the level of abstraction needed to create effective models
	must ensure that the code she writes based on a UML diagram always respects the constraints imposed by each OCL statement
	must learn documentation navigation, which includes looking up the methods available to achieve some objective
	often uses glass-box testing informally when he is verifying his own code
	should adhere to object oriented principles
	should apply the 'isa' rule religiously
	should avoid duplication of code
	should avoid over-use of class variables or class methods
	should choose alternative that makes code simpler over more complicated one
	should comment any changes to the code so that it is easy to see what has changed from one version to the next
	should comment whatever is non-obvious
	should create several small classes, rather than one big, complex class
	should ensure that anything that is true in a superclass is also true in its subclasses
	should follow consistent guidelines that make programs easy to read when writing programs
	should group classes into logical sections with a clear comment separating each section if a class has many methods
	should keep related methods together inside a class
	should keep the number of instance variables small. If this number exceeds 10, then consider splitting the class into separate classes - e.g. a superclass and a subclass
	should not comment obvious things since they add clutter
	should not use tab characters in code - use two spaces for indentation instead because when code is printed on certain printers, or displayed in certain editors, the width of the indentation resulting from the tab can vary and make the code hard to read
	should pay attention to to the documentation describing which features of Java are deprecated
	should reject 'clever' or 'cool' coding techniques unless they make the code simpler to understand
	should remember that shorter code is not necessarily better code but unnecessarily long code is also bad
	should restructure code to make it simpler if necessary
	should take advantage of polymorphism, inheritance, abstract classes, and methods
	should use consistent code layout style
	should write comments at the same time as writing code , and perhaps even before writing the code
	writes program
software developer	asks several evaluators to independently perform heuristic evaluations
	develops software
	has goal rewarding career, recognition, or the challenge of solving difficult problems or by being a well-respected 'guru' in a certain area of expertise
	is part of software development team
	maintains software
	may be judged on when they deliver product, not on its quality level
	may be reluctant to develop new libraries, APIs and frameworks because developing anything reusable is seen as not directly benefiting the current customer If a developer has painstakingly developed a high-quality reusable component, but management only rewards the efforts of people who create the more visible 'final product', then that developer will be reluctant to spend time on reusable components in the future Efforts at creating reusable software are often done in a hurry and without enough attention to quality. People thus lose confidence in the resulting components, and in the concepts of reuse and reusability
	may refuse to reuse components in which they lack confidence
	most often works on custom software
	must inform the project manager about any problems
	must understand the customer's business environment, their problems and the available technology which can be used to solve the problems
	often fails to adequately involve users in the development process
	often has significantly less knowledge about modelling than about design and programming
	often underestimates software development time because it is very hard for people to assess the quality of software or to appreciate the amount of work involved in its development
	performs cost estimation
	reuses libraries and APIs delivered with a programming language
	should be rewarded for developing reusable components
	should emphasize the use case or use cases which are central to the system, which represent a high risk because of problematic implementation, or which have high political or commercial value
	should identify all the use cases associated with the software product
	should not document a design only after it is complete
	should not omit design documentation
	should only reuse technology that others are also reusing
	should realize that attention to quality of reusable components is essential so that potential re-users have confidence in them
	should realize that developing and reusing reusable components improves reliability, and can foster a sense of confidence
	should realize that developing reusable components will normally simplify the resulting design, independently of whether reuse actually occurs
	should work for several months on a testing team; this will heighten her awareness of quality problems she should avoid when she returns to designing software
	wants software that is easy to design and maintain and which has parts that are easy to reuse
stakeholder	must agree on requirements

Kinds of programmer :

• coder (4 facts) - A programmer who limits their work to programming (i.e. who do no higher-level design or analysis)
• Java programmer (5 facts)
• novice programmer (3 facts)
• skilled programmer (3 facts)

Next software developer: requirements specialist    Up: software developer    Previous software developer: modeller