O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Software Engineering Primer

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 72 Anúncio
Anúncio

Mais Conteúdo rRelacionado

Mais recentes (20)

Anúncio

Software Engineering Primer

  1. 1. Software engineering essentials A primer
  2. 2. Bio ● 16+ years IT stuff ● 1981 - 2011 in Germany ● since 21.07.2011 in Brazil, married, 2 sons Currently ● Head of Innovation, Dafiti ● IT Consultant, independent Contact ● Twitter (follow me for mostly geek stuff): https://twitter.com/georg.buske echo -n $(whoami); Georg.Buske
  3. 3. Today’s topics (not agenda) ● Process and team organization ○ Agile - what's all about? ○ Small projects VS. large scale projects ○ Real world examples of important IT guidelines in an enterprise ● Software Design & Architecture ○ Clean Code - an evergreen in Software Development ○ abbreviations you need to know: DDD, TDD, KISS, DRY, YAGNI, SOLID ○ A deeper look into the meaning of…
  4. 4. Disclaimer(s) ● Slides in english, talk in portuguese ● This is in no means a deep dive - a primer ○ We will cover a lot of stuff ○ Each topic could easily fill its own talk (or workshop) ○ There is no shortcut ● Slides will be available afterwards
  5. 5. Process and team organization
  6. 6. Fact: There is no real difference Everything of the talk can be applied to small and big [software] projects [and products] Wait, there is “really small”: ● < 3 developers on a private project or something you own ● then it is OK to ignore a lot of topics ● Use at least a VCS, like Git (even you are working alone, source control makes your life easier) Small projects VS. large scale projects
  7. 7. Try to split large projects into a lot of small ones! E.g. Amazon has 2 Pizza teams Average team size in other tech companies is between 3 - 10 (which is already a lot!)
  8. 8. Communication paths by team size Source: https://www.solutionsiq.com/learning/blog-post/lines-of-communication/
  9. 9. Agile - what's all about?
  10. 10. Agile Manifesto
  11. 11. Different ways of being agile: Scrum Scrum, quite old: 1993 “Real scrum” has more than 30 rules Because of this technically a lot of companies are doing “ScrumBut” But this is fine, as long as we are efficient Some important aspects of Scrum: Prioritized Backlog Timeboxed Sprints (Work organized and delivered in Sprints, e.g. always 2 weeks, no changes) -> deliver value
  12. 12. Scrum Roles: ● scrum master ● product owner ● participants (qa, devs) Meetings: ● Daily (same place, same time, everyday) ● Retrospective (what was good, what was bad in the last Sprint) ● Planning (what we can accomplish next Sprint)
  13. 13. Different ways of being agile: Kanban ● part of lean movement (popularized by toyota, 1940s/1950s) ● Less rules than Scrum, important aspects: ○ Visualize (KanbanBoard) ○ limit WIP ○ optimize value streams ○ Implement Feedback loops
  14. 14. Different ways of being agile: XP ● extreme programming framework ● by Kent Beck (also creator of TDD) ● First used in C3 (Chrysler Comprehensive Compensation project) - Kent Beck, Martin Fowler ● “XP was one of the first agile methods, indeed XP was the dominant agile method in the late 90s and early 00s before Scrum became dominant” ● Contains: ○ Continuous Integration ○ Refactoring
  15. 15. Real world examples of important IT guidelines in an enterprise
  16. 16. Why is it important? ● Consistency ● Best practices (we know it works) ● blueprint / howto for everyone (new and old), everybody knows how to do something ● Standard (from Wikipedia): established norm, specification, system of market dominance ● Guideline (from Google search): a general rule, principle or piece of advice
  17. 17. Dafiti’s IT Docs... ● General development workflow ● Architecture guidelines ● Ticket guidelines ● Coding standards ○ Style Guide templates ● Logging guidelines ● Commit message standard ● Pull request guidelines
  18. 18. Dafiti’s IT Docs... ● Post-mortem template ● DevOps best practices and failure mode ● Change requests ● POCs ● RFCs ● Service guidelines ● Component integration guidelines ● Component testing best practices
  19. 19. Examples We will opensource our Docs, follow @Dafiti_Tech or me (@georgbuske) on Twitter if you are interested ;-)
  20. 20. Feedback and Deliver Value
  21. 21. Software Design & Architecture
  22. 22. Design VS. Architecture
  23. 23. Definition If the Design is the interior, the architecture is the building Therefore: Design: The API (how to open the door) how looks the dining room) Architecture: The Big Picture, high level (this is how the house [or city] looks like) So in short, Software architecture is more about the design of the entire system, while software design emphasizes on module / component / class level. (Source: https://stackoverflow.com/questions/704855/software-design-vs-software-architecture)
  24. 24. Avoid Ivory Tower Architecture Should there be a dedicated team of Software architectures? No! Better: ● committee of senior technologists ● clear set of allowed technologies (tools like Technology Radar: https://www.thoughtworks.com/radar )
  25. 25. Clean Code - First things first ● Clean Code Book, by Robert “Uncle Bob” Martin ● “Programs must be written for people to read, and only incidentally for machines to execute.” ○ ― Harold Abelson, Structure and Interpretation of Computer Programs ● “No surprises” ○ ― Ward Cunningham ● “Clean code is a code that is written by someone who cares” ○ ― MIchael Feathers
  26. 26. Clean Code characteristics ● is language independent ● method length ● I should be able to read and understand ● Interfaces ● Error handling ● Boy Scout Rule ○ Always leave the campground cleaner than you found it. ● Unit and acceptance tests
  27. 27. Naming is hard
  28. 28. There are only two hard things in Computer Science: cache invalidation and naming things. -- Phil Karlton
  29. 29. An extension
  30. 30. My personal extension
  31. 31. Naming ● this applies to everything: variables, classes, functions, interfaces - even repository names ● Rule: Use Intention-Revealing Names ● Rule: Avoid Disinformation ○ E.g. IP as variable name for Identity Provider ● Rule: Make meaningful Distinctions ○ ProductInfo and ProductData ● Classes: Nouns
  32. 32. Naming Examples
  33. 33. SOLID ● subset of clean code ● 5 principles ○ Single Responsibility Principle ○ Open Close Principle ○ Liskov Substitution Principle ○ Interface Segregation Principle ○ Dependency Inversion Principle
  34. 34. Single Responsibility Principle Cohesion, a class should have only a single responsibility Should be changed for only one reason minimal and does one thing good (cf. Unix philosophy) and least possible dependencies
  35. 35. Open Closed Principle software entities should be open for extension, but closed for modification
  36. 36. Liskov Substitution Principle Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program
  37. 37. Interface Segregation Principle Many client specific interfaces are better than one big one
  38. 38. Dependency Inversion Principle One should depend upon abstractions, not concretions A.High-level modules should not depend on low-level modules. Both should depend on abstractions. B.Abstractions should not depend on details. Details should depend on abstractions. Example Patterns: Plugin, ServiceLocator, Dependency Injection -> Inversion of control
  39. 39. KISS = Keep it simple, stupid ● no overly complex solutions ● straightforward is often easier, cleaner and better to understand ● if you do TDD, this helps
  40. 40. ● code duplication is bad [copy paste] ● now, this can conflict with microservices (more on microservices later) DRY = Don’t repeat yourself
  41. 41. YAGNI = You ain’t gonna need it very close related to KISS For example: unnecessary complexity Except you are writing library code probably don't need to add 4 different types of authentication methods (Strategies, Adapters) - if there is the requirement to change, it is often long-term
  42. 42. DDD = Domain Driven Design ● term coined by Eric Evans ● focus on problem domain ● Combines lots of best practices and patterns ○ Refactoring ○ Continuous Integration
  43. 43. Context mapping & bounded contexts ● Core domain, generic subdomain, supporting domain ○ Best forces on most important part of the system (your product’s USP), core domains ○ Generic subdomains could be bought off-the-shelf
  44. 44. Ubiquitous language ● Everyone in team has the same vocabulary
  45. 45. Tactical Patterns ● Entities ○ Has identity ● Aggregate Roots ○ Are the entry points ● Value Objects ○ Immutable ● Repositories ○ Data Layer
  46. 46. TDD = Test Driven Development
  47. 47. Test Driven Development ● Red - green - refactor ● test first development (unit testing) ● write failing test, implement, refactor, iterate ● you can certainly test after, but advantages for test first are focus on features ● evolving and iterative design, to achieve KISS, DRY and YAGNI
  48. 48. Bonus: SOA = Service Oriented Architecture
  49. 49. SOA is a kind of 20 year old concept ● Boundaries are explicit ● Services are autonomous (Microservice extension: Can be deployed independent) ● Services share schema and contract, not class ● Service compatibility is based on policy And nowadays, everybody calls it “Microservices” This is now not 100 % accurate, but generally speaking Microservices are an old SOA and Microservices
  50. 50. A deeper look into the meaning of: make it work make it right make it fast
  51. 51. What does it mean? ● Remember TDD Cycle: make it work, make it right ○ test pass - refactor - nice API ● And then: performance (make it fast) ○ profiling bottlenecks, optimize code ● And sometimes this is not enough... ● make it work, make it right, make it fast, make it scale, make it again - lifecycle in #softwaredevelopment ○ Google: Design for 10fold, rewrite for 2 orders of magnitude...
  52. 52. Anti patterns
  53. 53. ● Big Ball of Mud: A system with no recognizable structure ● Cargo Cult Programming: Using patterns and methods without understanding why ● Accidental complexity: Programming tasks which could be eliminated with better tools (as opposed to essential complexity inherent in the problem being solved) ● Dependency hell: Problems with versions of required products And much more: https://en.wikipedia.org/wiki/Anti-pattern ● I found the silver bullet: There is no silver bullet ● The wrong abstractions: Better RY than the wrong abstraction! ● Being “too clever”: Better clear than clever (sometimes weird and
  54. 54. Communication and maintainability
  55. 55. Final thoughts
  56. 56. Life is about trade-offs ● Do you test? How much do you test? ○ Good discussion about TDD and trade-offs Kent Beck, David Heinemeier Hansson, and Kent Beck (Is TDD Dead? https://martinfowler.com/articles/is-tdd-dead/ ) ● We need to refactor X, but we need feature Y. ● This won’t perform good when we have more users. ● As technologists we want to use cool tech, as employees we need to deliver value as well
  57. 57. Language recommendations ● Master at least one language ● proficiency (Dreyfus) in a language is nothing one can accomplish in a month or a year ○ 10 years to learn a language is a good time frame (Peter Norvig): http://norvig.com/21- days.html ● Stay up-to-date and look into new languages and paradigms: TIOBE Top 50 ( https://www.tiobe.com/tiobe-index/ ) is a good place to look for ● Read papers about algorithms and concepts that matter to you (good sources are Google Scholar, https://arxiv.org/ or https://blog.acolyer.org/ )
  58. 58. Book recommendations ● Coders at Work (Peter Seibel) ● Clean Code (Robert Martin) ● Working Effectively with Legacy Code (Michael Feathers) ● Domain Driven Design (Eric Evans) ● The Phoenix Project (Gene Kim, George Spafford, and Kevin Behr) ● Mythical Man Month (Fred Brooks) ● Release It! (Michael T. Nygard) ● Building Microservices: Designing Fine-Grained Systems (Sam Newman)
  59. 59. Book recommendations ● Design Patterns (GoF) (Erich Gamma, John Vlissides, Ralph Johnson, and Richard Helm) ● Enterprise patterns for Application Architecture (Martin Fowler) ● How Google Tests Software (James A. Whittaker, Jason Arbon, and Jeff Carollo) ● Implementing Domain Driven Design (Vaughn Vernon) ● Beyond Blame (Dave Zwieback) ● 7 languages in 7 weeks (Bruce Tate)
  60. 60. Book recommendations ● 97 Things Every Software Architect Should Know (Richard Monson-Haefel) ● Data Science from Scratch (Joel Grus) ● Building Scalable Websites (Cal Henderson) ○ Some topics might be a bit outdated in the era of Cloud and SaaS, though a lot of good topics if you are working on websites ● Pragmatic Thinking and Learning: Refactor Your Wetware (Andy Hunt) ● Introduction to Algorithms (Charles E. Leiserson, Clifford Stein, Ronald Rivest, and Thomas H. Cormen) ● Refactoring (Martin Fowler)
  61. 61. Recap Communication Fast Feedback Continuous Improvement (also live-long learning)
  62. 62. Every Rule has its exception your mileage may vary
  63. 63. @Dafiti_Tech is hiring… Want to work in Sao Paulo? Or know some friend?
  64. 64. Thank you! Q & A

×