-
Notifications
You must be signed in to change notification settings - Fork 0
Software Development Practices
This article documents Software Development practices in the context of Application Lifecycle Management (ALM) - specifically, the Research, Planning, Implementation, Deployment and Maintenance stages. Where appropriate, platform-specific needs and practices are called out separately (e.g. PHP, .NET, Wordpress)
TODO
Before starting the development process, a remote repository should be created to begin shared source control from the very start. All projects should use Git for source control.
If the project will be shared (with other colleges, etc.) a repository should be created on Github. Otherwise, contact @johannaAqui, @shawn-bellevuecollege or @jonathanwindle to have one created on our internal server.
Software Design refers not just to the User Interface (UI), or even the much broader User eXperience (UX) but also which components make up the overall solution and how they work together. For example, the following are all design considerations - along with UI and UX:
- Does the application need to store data? What will it use to do so? XML files? A database?
- Do users need to interact directly with this application? From where, and how will they do so?
- If the application is an unattended service, how will it be invoked? How will it communicate its status?
- Does the application need to interact with other services? How does it do so?
- Does the application rely on data from other systems? How does it get that data? How do we ensure that data is up to date?
- What platform will the application run on? Why?
Notice that these are mostly questions. When designing a software application, you should always be able to answer the question, "why are we using this technology/component/product/approach/etc.?" You don't necessarily have to defend the decision - "that's what we know", "all the other apps are on this server", etc. can be perfectly acceptable answers. The important thing is that somebody thought about it and made a decision rather than just letting the momentum of the status quo continue.
If ODS (private repo) data is going to be included directly in the application's database schema, do not query those views directly. Instead create a view in the application's database which returns only the columns you need. Every column included adds overhead to the final query.
-- Instead of the following call (e.g. in a stored procedure):
SELECT * FROM ODS.dbo.vw_Employee
-- Create your own view
CREATE VIEW vw_Employee
AS
SELECT e.AliasName, e.ADUserName
FROM ODS.dbo.vw_Employee e
-- And then use that view
SELECT * FROM vw_EmployeeFor software applications, implementation is the construction of the actual application - including writing code, implementing interfaces, etc.
| Type | Style | Notes |
|---|---|---|
| constants | ALL_CAPS | words separated by underscores |
| class/member/global variables | _leadingUnderscore | camel-cased |
| class/struct/enum/etc. | PascalCase | |
| members (method/property/etc.) | PascalCase |
DO
- use descriptive names.
DO NOT
- start a name with a number.
- use dashes in names.
(currently under review)
Whenever possible, each application should display its version in an unobtrusive location, where it does not interfere with the overall application design. If this is not possible, include the version in the web application's source - as an HTML comment.
Candidate releases are designated versions that are believed to be ready for deployment to production - pending approval from QA. To be designated as a Release Candidate all assigned bugs/tasks for the target milestone must be resolved/completed. If a release is being pushed to QA in order that recently fixed/implemented functionality can be tested, but there are still active work items in the release backlog, it should not be labeled as a Release Candidate.
The Release Candidate label is primarily internal terminology - for use when the team is discussing the different releases. It does not need to be included in the version information displayed within the application.
Avoid using the HTTP Session State to store large objects, or for long-term storage. Be mindful of the memory space Session State is using and that it does not always work well in a clustered environment.
When a release candidate has been approved and deployed to production, the master branch of the main repository should be updated with changes that were deployed. The following instructions assume that the release candidate changes have already been merged into the dev branch on the main repository and that you have configured a remote for this repository named bc.
From your local workstation...
- Ensure your local
masteranddevbranches match the (remote) main repository, usinggit reset. - Merge the local
devbranch into localmaster. - Push the updated
masterto the main repository.
(???)$ git checkout dev
(dev)$ git reset bc/dev
(dev)$ git checkout master
(master)$ git reset bc/master
(master)$ git merge dev
(master)$ git push bcAs a side benefit, your local dev and master branches are now also synchronized with the main repository, so you can create feature and hotfix branches knowning that you're working off the current code.
TODO