Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Responsive Design One Day


Published on

켄트백이 강의했던,
Responsive Design강의자료

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Responsive Design One Day

  1. 1. Responsive Design Kent Beck Three Rivers Institute
  2. 2. Responsive Design Project <ul><li>Study design </li></ul><ul><ul><li>Introspectively </li></ul></ul><ul><ul><li>Empirically </li></ul></ul><ul><ul><li>Quantitatively </li></ul></ul>
  3. 3. Why now? <ul><li>Design has leverage at times of change </li></ul><ul><ul><li>End of free Moore’s Law </li></ul></ul><ul><ul><li>Scale </li></ul></ul><ul><ul><li>Cloud </li></ul></ul><ul><ul><li>Re-client </li></ul></ul>
  4. 4. Leverage <ul><li>It is not a: </li></ul><ul><ul><li>Configuration </li></ul></ul><ul><ul><li>Testing </li></ul></ul><ul><ul><li>Reliability </li></ul></ul><ul><ul><li>Build time </li></ul></ul><ul><ul><li>Deployment </li></ul></ul><ul><li>problem, it is a design problem </li></ul>
  5. 5. Goal of Development Steady Flow of Features
  6. 6. Design? <ul><li>Adding features should be straightforward </li></ul>
  7. 7. Dilemma Less Later Cost More Sooner Revenue Options Time
  8. 8. Efficiency <ul><li>Initial work </li></ul><ul><li>+ </li></ul><ul><li>Cost of features </li></ul><ul><li>+ </li></ul><ul><li>Cost of changes </li></ul><ul><li>+ </li></ul><ul><li>Cost of mistakes </li></ul><ul><li>+ </li></ul><ul><li>Opportunity cost </li></ul>* risk
  9. 9. Latency, Throughput, Variance
  10. 10. Challenges <ul><li>Human </li></ul><ul><li>Social </li></ul><ul><li>Sensitivity </li></ul><ul><li>Succession </li></ul><ul><li>Uncertainty </li></ul>
  11. 11. Uncertainties <ul><li>Value </li></ul><ul><li>Means </li></ul><ul><li>Technology </li></ul><ul><li>Team </li></ul>
  12. 12. Values <ul><li>Feedback </li></ul><ul><li>Humanity </li></ul><ul><li>Courage </li></ul><ul><li>Ambiguity </li></ul>
  13. 13. Design <ul><li>Beneficially </li></ul><ul><li>Relating </li></ul><ul><li>Elements </li></ul>
  14. 14. Coupling <ul><li>The probability that a change in one element will require a change in another </li></ul>
  15. 15. Cohesion <ul><li>The probability that a change in one sub-element will require a change in all others </li></ul><ul><li>Inversely related to coupling </li></ul>
  16. 16. Safe Steps <ul><li>Balance </li></ul><ul><ul><li>Efficiency </li></ul></ul><ul><ul><li>Risk </li></ul></ul><ul><ul><li>Feedback </li></ul></ul><ul><ul><li>Teamwork </li></ul></ul>
  17. 17. Strategies <ul><li>Can see? </li></ul><ul><ul><li>Leap </li></ul></ul><ul><ul><li>Parallel </li></ul></ul><ul><li>Can’t see? </li></ul><ul><ul><li>Stepping Stone </li></ul></ul><ul><ul><li>Simplification </li></ul></ul>
  18. 18. Leap <ul><li>If </li></ul><ul><ul><li>You can imagine what you want </li></ul></ul><ul><ul><li>You can build it </li></ul></ul><ul><ul><li>You can install it </li></ul></ul><ul><li>Efficiency </li></ul><ul><li>Risk </li></ul>
  19. 19. Parallel <ul><li>If </li></ul><ul><ul><li>You can imagine what you want but </li></ul></ul><ul><ul><li>You can’t build it or install it safely </li></ul></ul><ul><li>Support two designs simultaneously </li></ul><ul><ul><li>Gradual migration </li></ul></ul><ul><ul><li>Forwarding both ways </li></ul></ul><ul><li>Safety </li></ul><ul><li>Scaffolding </li></ul>
  20. 20. Stepping Stone <ul><li>If </li></ul><ul><ul><li>You can’t imagine exactly what you want to build but </li></ul></ul><ul><ul><li>You can imagine what would make the end easier/safer to reach </li></ul></ul><ul><li>Build a platform from which your goal is easier to reach </li></ul><ul><li>Some well-known components </li></ul><ul><li>Risk of over-engineering </li></ul><ul><li>Lack of feedback </li></ul>
  21. 21. Simplification <ul><li>If </li></ul><ul><ul><li>You can’t imagine exactly what you want to build </li></ul></ul><ul><ul><li>Getting to the end is too expensive </li></ul></ul><ul><li>Eliminate requirements until you reach a safe step </li></ul><ul><li>Gradually re-introduce requirements </li></ul><ul><li>Almost always possible </li></ul><ul><li>Establishes initiative </li></ul><ul><li>Non-linearities in cost depending on requirements ordering </li></ul>
  22. 22. Four Strategies Leap Parallel Stepping Stone Simplification
  23. 23. …and One More <ul><li>If </li></ul><ul><ul><li>You can’t see how to make adding the feature straightforward </li></ul></ul><ul><li>Add it anyway </li></ul><ul><li>Expect to pay the price later </li></ul>
  24. 24. Refactoring <ul><li>Bi-directional </li></ul><ul><li>Isolate change </li></ul><ul><li>Interface or implementation </li></ul>
  25. 25. Isolate change <ul><li>Before making a change, reduce risk by isolating the area that will need to be changed </li></ul>
  26. 26. Design is an island <ul><li>No “best” design </li></ul><ul><li>Improvement </li></ul><ul><li>Deterioration </li></ul><ul><li>Sea level </li></ul><ul><li>Change in basis </li></ul>
  27. 27. Observations <ul><li>Power laws </li></ul><ul><li>Fractal </li></ul><ul><li>Symmetry </li></ul><ul><li>Punctuated equilibrium </li></ul>
  28. 28. Power Laws Source: Power Laws in Software, Spinellis, et. al.
  29. 29. Fractal
  30. 30. Symmetry
  31. 31. Punctuated Equilibrium Source:
  32. 32. Psychology <ul><li>Confidence </li></ul><ul><li>Initiative </li></ul><ul><li>Creativity </li></ul>
  33. 33. Ask the system <ul><li>Visualization </li></ul><ul><li>Debugger </li></ul>
  34. 34. Recovery <ul><li>Broken windows </li></ul><ul><li>Site repair </li></ul>
  35. 35. Design for testability
  36. 36. Timing
  37. 37. Least commitment