bundle-audit check
Thursday, November 30, 2017
Sunday, November 26, 2017
Strip trailing whitespace on Save with …callbacks! in Textmate
Open the bundle editor (⌃⌥⌘B) and open “Text” → “Menu Actions” → “Converting / Stripping” → “Remove Trailing Spaces in Document / Selection”.
Then in the drawer put callback.document.export
Hooray! From now on each time you’ll save a document all trailing space will be stripped!
Sunday, November 12, 2017
Software Quality Attributes Rating Tool
www.gettingagile.com/wp-content/uploads/2009/05/softwarequalityattributes-ratingtool.xls
Notes from Software Debt Book
Leave the campground cleaner than you found it.
Always leave the code in better shape than when you started.
The following questions should help you decide whether to start refactoring when you see an opportunity for it:
1. Does this change directly affect the feature I am working on?
2. Would the change add clarity for the feature implementation?
3. Will the change provide automated tests where there currently are none?
4. Does the refactoring look like a large endeavor involving significant portions of the application components?
Refactor if the answer to the first three questions is an yes. If the answer to the fourth question is yes. Then I use experience as a guide to help me produce a relative size estimate of the effort involved in this refactoring compared to the initial estimate of size for the feature implementation. If the size of the refactoring is significantly larger than the original estimate given to the Product Owner, I will bring the refac- toring up to the team for discussion. Bringing up a large refactoring to the rest of the team will result in one of the following general outcomes:
The team thinks it is good idea to start the large refactoring because its estimated size does not adversely affect delivery of what the team committed to during this iteration.
The team decides that the refactoring is large enough that it should be brought up to the Product Owner. The Product Owner could add it to the Product Backlog or decide to drop scope for the current iteration to accommodate the refactoring.
Another team member has information that will make this refactor- ing smaller or not necessary. Sometimes other team members have worked in this area of code or on a similar situation in the past and have knowledge of other ways to implement the changes needed.
Simplicity — the art of maximizing the amount of work not done—is essential.
Design Review
Design review sessions are periodic meetings where team members are able to share and get feedback on design decisions. Effective design reviews involve the development team members. The design review provides a forum for the team to converge on common design decisions and ultimately clarity in the application’s structure. The typical design review session involves all development team members. The agenda for the meeting is sent out to the team beforehand and includes the one or more design decisions that will be discussed. At the meeting, each design decision is presented while the rest of the team asks questions and dis- cusses the merits and challenges they see. Through this discussion the devel- opment team captures action items to take into the software construction process.
Always leave the code in better shape than when you started.
The following questions should help you decide whether to start refactoring when you see an opportunity for it:
1. Does this change directly affect the feature I am working on?
2. Would the change add clarity for the feature implementation?
3. Will the change provide automated tests where there currently are none?
4. Does the refactoring look like a large endeavor involving significant portions of the application components?
Refactor if the answer to the first three questions is an yes. If the answer to the fourth question is yes. Then I use experience as a guide to help me produce a relative size estimate of the effort involved in this refactoring compared to the initial estimate of size for the feature implementation. If the size of the refactoring is significantly larger than the original estimate given to the Product Owner, I will bring the refac- toring up to the team for discussion. Bringing up a large refactoring to the rest of the team will result in one of the following general outcomes:
The team thinks it is good idea to start the large refactoring because its estimated size does not adversely affect delivery of what the team committed to during this iteration.
The team decides that the refactoring is large enough that it should be brought up to the Product Owner. The Product Owner could add it to the Product Backlog or decide to drop scope for the current iteration to accommodate the refactoring.
Another team member has information that will make this refactor- ing smaller or not necessary. Sometimes other team members have worked in this area of code or on a similar situation in the past and have knowledge of other ways to implement the changes needed.
Simplicity — the art of maximizing the amount of work not done—is essential.
Design Review
Design review sessions are periodic meetings where team members are able to share and get feedback on design decisions. Effective design reviews involve the development team members. The design review provides a forum for the team to converge on common design decisions and ultimately clarity in the application’s structure. The typical design review session involves all development team members. The agenda for the meeting is sent out to the team beforehand and includes the one or more design decisions that will be discussed. At the meeting, each design decision is presented while the rest of the team asks questions and dis- cusses the merits and challenges they see. Through this discussion the devel- opment team captures action items to take into the software construction process.
Subscribe to:
Posts (Atom)