1 / 24

How to become a pragmatic programmer

daniel_millan
Download Presentation

How to become a pragmatic programmer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. How to become a pragmatic programmer By Rick Mason, BusinessGrade.com

    2. The book

    3. The Book and it’s lessons Set of principles Goal building better software While Improving productivity, accuracy and job satisfaction Write flexible, dynamic and adaptable code

    4. Agile is a set of principles not tools But there are specific tools that help Source control Frameworks and ORM Testing and automation tools Communication tools Bug tracking and project management

    5. The cat ate my source code Take responsibility for your code Don’t live with broken windows Put out fires

    6. Stone soup and boiled frogs The story of stone soup Don’t take support for granted Lead by example

    7. The D.R.Y. principle Don’t repeat yourself Write less code Have fewer problems

    8. Reasons for duplication Imposed – It’s the environment Inadvertent – Developers didn’t realize Impatient – Lazy developers Inter-developer duplication

    9. The orthogonality principle Geometry – Lines meet at right angles Agile - Write decoupled modules

    10. Is your program like a house of cards?

    11. Goal : Design components that are self contained Benefit: Small components easier to write Benefit: Code reuse

    12. Reduced risk from self contained components Diseased code is isolated Code is less fragile

    13. Tips for writing orthogonic code Write shy code – Don’t reveal anything unnecessary Avoid global data Avoid similar functions – one function called with parameter

    14. Principle of Reversibility Change happens so plan for it What if the database changes? Or a 3rd party library gets changed? Build a flexible architecture

    15. Use tracer bullets What’s a tracer bullet? If the project has unknowns Client isn’t sure what he wants Build a quick less than fully functional concept

    16. Use code generators Producing same code over and over again? Consider using a code generator For example CRUD model

    17. Design by contract Architect by contract Preconditions: What must be true to call the routine? Post conditions – What state has the routine returned? Class invariants – What is true from perspective of caller Share your assumptions with the client

    18. Use an information radiator Whiteboards Dashboards Wiki can function as a dashboard

    19. Decoupling and the law of Demeter The example of the terrorist cell Build modules that limit interaction If your module depends on three others And they each depend upon three more Any of them can blow up your module

    20. Rules for refactoring code Duplication – Violate DRY principle Non-orthogonal code – Reduce module dependence Outdated knowledge – Problem changes Performance

    21. The trouble with programmers is that you can never tell what a programmer is doing until it’s too late. - Seymour Cray, Cray Computer

    22. Testing Use your contract to test your assertions using code CFUnit and CFCUnit Justifying the time? Write the test, then fix the bug

    23. Rules for commenting code Why something is done, it’s purpose and goal Author and date Use descriptive variables SalesOrderDelete not SOD

    24. Questions? Rick Mason – RMason@BusinessGrade.com

More Related