Ingredients for Masala
- Apply Header docs
- Define constants for literals
- Apply Localization
- Remove white spaces even unnecessary tabs
- Memory management (including didReceiveMemoryWarning and viewDidUnload)
- Notifications handling
Ingredients for Masala
When the project first started, the development team attempted to adopt some (though not all) of the concepts of the Scrum framework, an agile process based on empirical process control theory that focuses on transparency, inspection, and adaptation. The team implemented daily stand-up meetings and burndown charts, but chose not to adopt components to enable inspection, such as sprint planning, sprint review, and retrospective meetings.
As the project moved into the waterfall qualify phase — in which the development team needed to handle a constant stream of testing defects — the team’s scrum process ended. They would have to pick it back up when the next release started its development phase. This failure of the initial Scrum attempt was ultimately a consequence of not having adopted the processes of inspection; this lesson learned helped the team in their follow-on Scrum efforts.
In the development phase of a more recent release, the development team decided to start fresh and introduce the complete agile process based on the Scrum concepts and hallmarks. The team established a commitment to sprint planning, sprint review, and retrospective meetings. More importantly, they committed to process inspection and self-governance.
To fully adopt the Scrum way of doing things, the team needed to identify who on the scrum team would assume the three required roles of Product Owner, ScrumMaster, and Team. Initially, the development project manager was positioned as the primary Product Owner. The Team consisted of the existing development team members. A ScrumMaster was selected who established a sprint calendar of three- to four-week cycles, with start and end dates that didn’t necessarily line up with the waterfall process milestones; the team learned that sprint meetings scheduled close to waterfall milestones result in the team focus being shifted to one of these events, but not both, leaving an unfavorable result for the one that became neglected.
For the sprint planning meeting, the development team started with the product backlog of candidates that the client had identified (in the concept and plan phases) for future release of the application. The Product Owner selected a subset of these items, which constituted the possible product backlog to be considered for the sprint. During the sprint planning meeting, the development team committed to the product backlog items they believed they could complete during the sprint, and from that built the sprint backlog, which was the tasks, task estimates, and assignments that the team would actually work on during the sprint.
At the end of each sprint, the development team held a sprint review meeting. The purpose of this meeting was to demonstrate to the stakeholders what had been completed in the sprint, and provide a timely opportunity for the stakeholders to comment and ask questions, possibly resulting in a list of desired changes. Such changes and any missing or incorrect functionality were added to the product backlog for the next sprint.
At the end of each sprint, the development team also held a sprint retrospective meeting to review what went well during the sprint and what could be improved upon. Based on this feedback, they changed their processes as appropriate and added non-functional action items to the product backlog.
The typical schedule was to hold the sprint review and sprint retrospective meetings on the same day at the end of the sprint, followed by the sprint planning meeting for the next sprint on the following day. These meetings were conducted within the Scrum time-boxing guidelines.
Client representatives (solution leaders) attended the sprint planning and sprint review meetings. Initially, the client’s interests were represented by the development project manager, but in later sprints, the development team was able to pull in the solution leaders and get direct client input and feedback through these key participants. This approach was purposeful; the team wanted to understand the processes and methodology well before expanding the circle of participants to include the solution leaders.
The development team also incorporated user stories into their planning. Although the client representatives (solution leaders) should be responsible for creating user stories, the development team did this instead, based on existing requirements, because the greater project was not yet committed to agile processes. The team then engaged the solution leaders in validating the user stories, collaborated to refine them and gain a greater understanding of the requirements. This practice has greatly improved the understanding and accuracy of the requirements, and greatly reduced rework after the fact.
While the development team has long used continuous integration, they recently incorporated automated testing into the development process. Work items were not considered complete until an automated test was available and merged into the testing tool. Daily builds and automated testing ensured that the code base was not broken as code was checked in. This resulted in higher quality code and fewer defects being found in the qualify phase. Coding items were not considered complete until the functionality could be demonstrated on a live server. Non-coding items, such as new processes or documentation, were published on the development team’s internal wiki and distributed to the team for review prior to being presented as complete at a sprint review meeting.
WebKit C++ Coding Style Guidelines
Cited from: http://webkit.org/coding/coding-style.html
C++ is the main development language used by many of Google’s open-source projects. As every C++ programmer knows, the language has many powerful features, but this power brings with it complexity, which in turn can make code more bug-prone and harder to read and maintain.
The goal of this guide is to manage this complexity by describing in detail the dos and don’ts of writing C++ code. These rules exist to keep the code base manageable while still allowing coders to use C++ language features productively.
Style, also known as readability, is what we call the conventions that govern our C++ code. The term Style is a bit of a misnomer, since these conventions cover far more than just source file formatting.
One way in which we keep the code base manageable is by enforcing consistency. It is very important that any programmer be able to look at another’s code and quickly understand it. Maintaining a uniform style and following conventions means that we can more easily use “pattern-matching” to infer what various symbols are and what invariants are true about them. Creating common, required idioms and patterns makes code much easier to understand. In some cases there might be good arguments for changing certain style rules, but we nonetheless keep things as they are in order to preserve consistency.
Another issue this guide addresses is that of C++ feature bloat. C++ is a huge language with many advanced features. In some cases we constrain, or even ban, use of certain features. We do this to keep code simple and to avoid the various common errors and problems that these features can cause. This guide lists these features and explains why their use is restricted.
Open-source projects developed by Google conform to the requirements in this guide.
Note that this guide is not a C++ tutorial: we assume that the reader is familiar with the language.
These are the things need to consider for further improvement in project development.
1. Team members should not have access to Basecamp.
2. Should not work on new features on build(release) day, just concentrate on stabilizing the existing features.
3. There should be internal technical forum (for technical help) organization level. There should be categories like google groups.
4. The skill sets of all employees should be available to all, so that we can consult the particular people for suggestions or help.
5. Team lead should be there with build master while releasing the build to client, otherwise there is change to release wrong build.
6. Team members should not contact external persons (other teams) on project work with out prior notice to Team lead.
7. Team members should post their technical issues on multiple chat (like Skype), so that every one will be aware of the type of issues.
8. Team members should obey their superior orders strictly.
9. Be aware while uploading the build to App Store.
a. The app store will read the info plist (preferences) file from the build and act according to it. For example, if you remove glossy effect from app icon by setting UIPrerenderedIcon to true, then app store will automatically removes the glossy effect from the application Icon it shows in info section.
b. The app store will read the release build for localizations and append them in the localizations section in app info section. It will automatically shows the supported localizations instead of what you configured while uploading.
10. Modules should be segregated in such way that there is no dependability on each other.But at the same time make sure that each team member is aware of each other’s modules and the way the implementation is been done.
11. Certain instances it’s been seen that there is some technical differences. I would suggest in those moments its better we sort the help of someone else who is technically sound.
12. Do lot of commits to svn with less files than one commit with more files, because its a time consuming process to figure out the buggy file (one exists) in the commit.
Code reviews are a powerful practice for improving software quality. The strategies are:
If you have any additional strategies you have found particularly useful, please let me know.