Search

Why Architecture in Web Development matters

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

2 comments

Comments 1 - 2 of 2 previous next Post a comment

Post a comment
Embed Video
Edit your comment Cancel

Notes on slide 1















strong dependency -> „co-dependency“




\"if you want to serialize to xml do not create \"toxml\" Method, instead pass $this to the XMLExporter\"

think in advance but don‘t think too complex
before making any generalisation have at least two cases
the more abstractions the easier you can change it later

nobody said it will be easy

tightrope walk

























preparing fixtures/Mocks difficult

preparing fixtures/Mocks difficult

preparing fixtures/Mocks difficult

preparing fixtures/Mocks difficult

preparing fixtures/Mocks difficult













do not spread db calls through your code
one function or object generates one „business“ result
data access object

do not spread db calls through your code
one function or object generates one „business“ result
data access object

do not spread db calls through your code
one function or object generates one „business“ result
data access object






lazy loading ok

in Ruby all Variables from controller are accessable.

lazy loading ok

in Ruby all Variables from controller are accessable.

lazy loading ok

in Ruby all Variables from controller are accessable.

Do not reinvent the wheel. Use frameworks






at least daily

test a single class
do not touch database, network, (files)
use mocks/stubs and provide fast feedback

test several classes
test communication between classes/modules
they test full components

test functionality from „outside“
often build from „user stories“
usually done with Selenium -> not only selenium example openapi
























6 Favorites

Why Architecture in Web Development matters - Presentation Transcript

  1. Why Architecture Lars matters Jankowfsky, swoodoo.com
  2. Lars Jankowfsky • CTO and (Co-)Founder swoodoo AG • (Co-)Founder OXID eSales AG • XP, agile development fanatic • developing since 15+ years • php since php/fi • Software Architect > 10 years Lars Jankowfsky,
  3. Architectur e
  4. Zend Framework symfony cakePHP ezComponent s
  5. (c) istockphoto success (c) aboutpixel.de
  6. Scale!
  7. Speed!
  8. Deploy!
  9. long project lifetime
  10. (c) istockphoto code aging
  11. (c) istockphoto big ball of mud
  12. (c) istockphoto continuous maintenance
  13. „For us, it’s really about scaling horizontally - to that end, Rails and Ruby haven’t been stumbling blocks, compared to any other language or framework. The performance boosts associated with a “faster” language would give us a 10-20% improvement, but thanks to architectural changes that Ruby and Rails happily accommodated, Twitter is 10000% faster than it was in January.“ Blaine Cook, Twitter's lead architect Lars Jankowfsky,
  14. Principles of success
  15. D.R.Y. Do Not Repeat Yourself
  16. Single responsibility \"if it generates XML then it should not gene principle
  17. K.I.S.S. don‘t think too complex
  18. (c) spackletoe http://www.flickr.com/photos/spackletoe/90811910/) (c) aboutpixel.de
  19. (c) istockphoto (c) aboutpixel.de
  20. Developing
  21. Art
  22. (c) dasbeibi @ aboutpixel.de
  23. Evolving Architecture
  24. Y.A.G.N.I. You Ain‘t Gonna Need it
  25. No refactoring , no evolution.
  26. (c) istockphoto
  27. Principle of „bad smell“
  28. Bad smells? Lars Jankowfsky,
  29. Bad smells? • Do maintenance cost keep increasing? Lars Jankowfsky,
  30. Bad smells? • Do maintenance cost keep increasing? • Simple features need too long to be implemented Lars Jankowfsky,
  31. Bad smells? • Do maintenance cost keep increasing? • Simple features need too long to be implemented • Small changes ripple through your system Lars Jankowfsky,
  32. dead code
  33. dead code data classes
  34. comments „what not why“ dead code data classes
  35. comments „what not why“ long methods dead code data classes
  36. • http://martinfowler.com/bliki/CodeSmell.html • http://www.codinghorror.com/blog/archives/ 000589.html Lars Jankowfsky,
  37. Architecture?
  38. Layered Architecture Lars Jankowfsky,
  39. Layered Architecture • separation of concerns Lars Jankowfsky,
  40. Layered Architecture • separation of concerns • If they can live without each other - why to couple them? Lars Jankowfsky,
  41. Layered Architecture • separation of concerns • If they can live without each other - why to couple them? • Find the boundaries and cut mercilessly. Lars Jankowfsky,
  42. Layered Architecture • separation of concerns • If they can live without each other - why to couple them? • Find the boundaries and cut mercilessly. • Do not bypass any layer! Lars Jankowfsky,
  43. Layered Architecture • separation of concerns • If they can live without each other - why to couple them? • Find the boundaries and cut mercilessly. • Do not bypass any layer! • Separate modules/classes or go SOA Lars Jankowfsky,
  44. SOA Lars Jankowfsky,
  45. SOA • Pro: makes scaling very easy Lars Jankowfsky,
  46. SOA • Pro: makes scaling very easy • Pro: clear defined boundaries, no violations possible Lars Jankowfsky,
  47. SOA • Pro: makes scaling very easy • Pro: clear defined boundaries, no violations possible • Pro: perfect for refactoring Lars Jankowfsky,
  48. SOA • Pro: makes scaling very easy • Pro: clear defined boundaries, no violations possible • Pro: perfect for refactoring • Pro: Deployment benefits Lars Jankowfsky,
  49. SOA • Pro: makes scaling very easy • Pro: clear defined boundaries, no violations possible • Pro: perfect for refactoring • Pro: Deployment benefits • Con: integration testing gets more difficult Lars Jankowfsky,
  50. (c) istockphoto Extend!
  51. (c) istockphoto Scale!
  52. Database
  53. ZendDb ADOdb PDO doctrine propel
  54. Database Lars Jankowfsky,
  55. Database • you might use a database access layer Lars Jankowfsky,
  56. Database • you might use a database access layer • go ORM if you want (performance!) Lars Jankowfsky,
  57. Database • you might use a database access layer • go ORM if you want (performance!) • business layer - not abstraction layer Lars Jankowfsky,
  58. Database • you might use a database access layer • go ORM if you want (performance!) • business layer - not abstraction layer • let‘s call it Data Access Object Lars Jankowfsky,
  59. DB Abstraction Layer PDO, ADOdb, ZendDb....
  60. DB Abstraction Layer PDO, ADOdb, ZendDb.... Table Data Gateway Object Layer Pattern
  61. DB Abstraction Layer PDO, ADOdb, ZendDb.... Table Data Gateway Object Layer Pattern Data Access Object Business Layer
  62. DB Abstraction Layer PDO, ADOdb, ZendDb.... Table Data Gateway Object Layer Pattern Data Access Object Business Layer function giveMeMyData()
  63. MVC
  64. Controller Lars Jankowfsky,
  65. Controller • Common mistake: business logic in controller Lars Jankowfsky,
  66. Controller • Common mistake: business logic in controller • Keep it out! Otherwise you will end with SQL in controller Lars Jankowfsky,
  67. Controller • Common mistake: business logic in controller • Keep it out! Otherwise you will end with SQL in controller • I/O mapping to the model and view only Lars Jankowfsky,
  68. Controller • Common mistake: business logic in controller • Keep it out! Otherwise you will end with SQL in controller • I/O mapping to the model and view only • Kick Ass! Lars Jankowfsky,
  69. View Lars Jankowfsky,
  70. View • Use a template engine. Watch performance! Lars Jankowfsky,
  71. View • Use a template engine. Watch performance! • No business logic in the template/html Lars Jankowfsky,
  72. View • Use a template engine. Watch performance! • No business logic in the template/html • Kick Ass! Lars Jankowfsky,
  73. (c) istockphoto
  74. TDD
  75. Enforces layered Architecture
  76. use continuous integration e.g. cruise con
  77. Commit frequently.
  78. Unit Tests
  79. Integration Tests Unit Tests
  80. Acceptance Tests Integration Tests Unit Tests
  81. what if fixture/mock preparation are much larger than tests?
  82. what if your tests run for hours ?
  83. (c) istockphoto
  84. framework !== software architecture
  85. evolve your architecture
  86. split your application into layers
  87. enforce proper usage of MVC
  88. wrap database access
  89. utilize test driven development
  90. (c) dasbeibi @ aboutpixel.de
  91. lars.jankowfsky@swoodoo.com Lars Jankowfsky / Thorsten all pictures (c) iStockPhoto if not stated different
  92. C M V
  93. C M V
  94. C M V
  95. C M V
  96. Project structure • Remember? Find Boundaries and cut. • \"Services/Layers\" - at least on a directory level • use Framework structure • more ??? Lars Jankowfsky,
  97. identify important decisions
  98. scaling? Lars Jankowfsky,
  99. scaling? • web Lars Jankowfsky,
  100. scaling? • web • database Lars Jankowfsky,
  101. scaling? • web • database • services (ext./int.) Lars Jankowfsky,

+ dodgerisdodgeris, 6 months ago

custom

2019 views, 6 favs, 6 embeds more stats

Choosing the right software architecture for your p more

More info about this document

© All Rights Reserved

Go to text version

  • Total Views 2019
    • 1665 on SlideShare
    • 354 from embeds
  • Comments 2
  • Favorites 6
  • Downloads 72
Most viewed embeds
  • 242 views on http://www.frontalaufprall.com
  • 94 views on http://www.planet-php.net
  • 9 views on http://planet-php.org
  • 6 views on http://www.planet-php.org
  • 2 views on http://lj-toys.com

more

All embeds
  • 242 views on http://www.frontalaufprall.com
  • 94 views on http://www.planet-php.net
  • 9 views on http://planet-php.org
  • 6 views on http://www.planet-php.org
  • 2 views on http://lj-toys.com
  • 1 views on http://www.netvibes.com

less

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

Cancel
File a copyright complaint
Having problems? Go to our helpdesk?

Categories

Tags

more
-->
Search
RSS Feed
What's new?

© 2009 SlideShare Inc. All Rights Reserved