Code Craftsmanship Checklist<br />Ryan Polk<br />
The List<br />Intended as a checklist for further research.<br />Not a comprehensive list.<br />If your not thinking about...
Code Craftsmanship Topics<br />SOA (Service Oriented Architecture)<br />Paired Programming<br />UML / Object Modeling<br /...
Continuous Delivery
Refactoring
Design Patterns
Emergent Design
SOLID Principles
Misc. Code Craftsmanship
Error Handling
Code Smells and Heuristics
Etc…</li></li></ul><li>Continuous Delivery<br />4<br /><ul><li>Principles and technical practices that enable rapid, incre...
Upcoming SlideShare
Loading in …5
×

Code Craftsmanship Checklist

1,701 views

Published on

Code Craftsmanship Checklist

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,701
On SlideShare
0
From Embeds
0
Number of Embeds
140
Actions
Shares
0
Downloads
21
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Code Craftsmanship Checklist

  1. 1. Code Craftsmanship Checklist<br />Ryan Polk<br />
  2. 2. The List<br />Intended as a checklist for further research.<br />Not a comprehensive list.<br />If your not thinking about these subjects your not moving your development career forward.<br />What Else / How can we do it better?<br />The items presented are intended to give a selection of ideas for consideration in any Code Quality training agenda. <br />It is understood that one training would not be capable of covering all subjects listed. The decision that needs to be made by any organization is what topics are of most value to the teams.<br />
  3. 3. Code Craftsmanship Topics<br />SOA (Service Oriented Architecture)<br />Paired Programming<br />UML / Object Modeling<br />3<br /><ul><li>TDD / Automated Unit Tests
  4. 4. Continuous Delivery
  5. 5. Refactoring
  6. 6. Design Patterns
  7. 7. Emergent Design
  8. 8. SOLID Principles
  9. 9. Misc. Code Craftsmanship
  10. 10. Error Handling
  11. 11. Code Smells and Heuristics
  12. 12. Etc…</li></li></ul><li>Continuous Delivery<br />4<br /><ul><li>Principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users.
  13. 13. Taking the next step beyond Continuous Integration is essential in all development originations that produce highly integrated and complex systems.
  14. 14. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers, and operations, delivery teams can get changes released in a matter of hours sometimes even minutes no matter what the size of a project or the complexity of its code base.</li></li></ul><li>Refactoring<br />5<br /><ul><li>Code refactoring is the process of changing a computer program's source code without modifying its external functional behavior in order to improve some of the nonfunctional attributes of the software.
  15. 15. Advantages include improved code readability and reduced complexity to improve the maintainability of the source code.
  16. 16. Techniques that allow for more abstraction
  17. 17. Encapsulate Field – force code to access the field with getter and setter methods
  18. 18. Generalize Type – create more general types to allow for more code sharing
  19. 19. Replace type-checking code with State/Strategy
  20. 20. Replace conditional with polymorphism
  21. 21. Techniques for breaking code apart into more logical pieces
  22. 22. Extract Method, to turn part of a larger method into a new method. By breaking down code in smaller pieces, it is more easily understandable. This is also applicable to functions.
  23. 23. Extract Class moves part of the code from an existing class into a new class.
  24. 24. Techniques for improving names and location of code
  25. 25. Move Method or Move Field – move to a more appropriate Class or source file
  26. 26. Rename Method or Rename Field – changing the name into a new one that better reveals its purpose
  27. 27. Pull Up – in OOP, move to a superclass
  28. 28. Push Down – in OOP, move to a subclass</li></li></ul><li>Design Patterns<br />6<br /><ul><li>In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design.
  29. 29. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.
  30. 30. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.
  31. 31. Design Patterns provide a common language and structure to the overall design and architecture of software systems. This common language gives us the ability to talk about the parts of a system as a simple conglomerate of patterns instead of a list of random parts.
  32. 32. Patterns are a basic building block of code re-use and code extensibility.</li></li></ul><li>Emergent Design<br />7<br /><ul><li>Is a principle of software adaption over time, espousing the principle that software should grow better over time and not degrade as many systems do.
  33. 33. This system combines many different methodologies including the other topics listed with other solid practices in software development to create a comprehensive system for the maintenance and support of software systems.
  34. 34. Topics Covered:
  35. 35. How to design software in a more natural, evolutionary, and professional way
  36. 36. How to use the “open-closed” principle to mitigate risks and eliminate waste
  37. 37. How and when to test your design throughout the development process
  38. 38. How to translate design principles into practices that actually lead to better code
  39. 39. How to determine how much design is enough</li></li></ul><li>SOLID Principles<br />8<br />S - Single Responsibility Principle (SRP) the notion that an objects should have only a single responsibility. <br />O - Open / Closed Principle (OCP) the notion that “software entities … should be open for extension, but closed for modification”. <br />L - Liskov Substitution Principle (LSP) the notion that “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”. See also design by contract. <br />I - Interface Segregation Principle (ISP) the notion that “many client specific interfaces are better than one general purpose interface.”<br />D - Dependency Inversion Principle (DIP) the notion that one should “Depend upon Abstractions. Do not depend upon concretions.”Dependency injection is one method of following this principle.<br />
  40. 40. Service Oriented Architecture (SOA)<br />9<br /><ul><li>In computing, a service-oriented architecture (SOA) is a flexible set of design principles used during the phases of systems development and integration.
  41. 41. A deployed SOA-based architecture will provide a loosely-integrated suite of services that can be used within multiple business domains.
  42. 42. Providing Training on the Basic Principles of SOA will give all participants a better understanding of best practices needed to create loosely coupled systems with greater amounts of system re-use and higher flexibility.
  43. 43. Currently we are proficient at implementing some of the practices of SOA but our understanding of the principles and the orchestration of systems needs guidance.</li></li></ul><li>Paired Programming<br />10<br />Pair programming is an agile software development technique in which two programmers work together at one work station. One types in code while the other reviews each line of code as it is typed in. The person typing is called the driver. The person reviewing the code is called the observer (or navigator). The two programmers switch roles frequently.<br /><ul><li>Some studies have found that programmers working in pairs produce shorter programs, with better designs and fewer bugs, than programmers working alone.
  44. 44. Studies have found reduction in defect rates of 15% to 50%, varying depending on programmer experience and task complexity.</li></ul>Topics to Discuss & Variants:<br /><ul><li>Paired Programming Mechanics
  45. 45. Remote pair programming
  46. 46. Ping pong pair programming
  47. 47. The fusing of pair and solo programming</li></li></ul><li>UML / Object Modeling<br />11<br /><ul><li>Unified Modeling Language (UML) is a standardized general-purpose modeling language in the field of software engineering.
  48. 48. UML includes a set of graphical notation techniques to create visual models of software-intensive systems.
  49. 49. Like Design Patters UML provides developers with a standard form of communication that allows everyone to understand architectural patterns and how systems work.
  50. 50. By providing training on this subject we provide the structure for visual comprehension of systems.</li></li></ul><li>Miscellaneous Code Craftsmanship<br />12<br />A general section of miscellaneous code craftsmanship tutorials with distinct examples from code in our environment. This session would be run as a best practices code review teaching each attendee all of the following and more. <br /><ul><li>Clean Code
  51. 51. Meaningful Names
  52. 52. Functions
  53. 53. Comments
  54. 54. Formatting
  55. 55. Objects and Data Structures
  56. 56. Error handling
  57. 57. Boundaries
  58. 58. Classes
  59. 59. Systems
  60. 60. Concurrency
  61. 61. Code Smells and Heuristics
  62. 62. About 10 others…</li>

×