Technology for reduce of mistakes - うっかりをなくす技術
6 likes9,748 views
The talk by Kenta Sato at YAPC::Asia focuses on reducing human error in software development through engineering techniques. It emphasizes understanding human factors, identifying near-misses, and adopting strategies like code readability, documentation, and automated testing to prevent mistakes. The conclusion encourages developers to consider the perspective of others, streamlining processes, and create a safer coding environment.
Technology for reduce of mistakes - うっかりをなくす技術
- 1. Technology for reduce of mistakes id:karupaneura YAPC::Asia 2015 #yapcasiaD
- 2. Oops.. I forgot AC adaptor..
- 3. Thank you very very much!!!!
- 5. About me • Kenta SATO (id:karupanerura) • Perl/XS/Swift/Kotlin/Java/Crystal/C99/etc.. • Gotanda.pm Author • Senior Engineer at Mobile Factory, Inc. • WebApp/iOS/Android/Operation/etc..
- 6. CPAN (PAUSE: KARUPA) • Time::Strptime • Geo::Hex::V3::XS • Test::SharedObject • Plack::App::Vhost • etc..
- 7. Gotanda.pm #6 • at 9/17(Tue) GaiaX Inc. • Join us! • http://gotanda.pm.org/
- 8. YAPC::Asia with me • 2011: LT (My first attend to YAPC::Asia) • 2012: LT + Individual Sponsor • 2013: 20min Talk + individual sponsor • 2014: 40min Talk + individual sponsor + volunteer staff • 2015: 60min Talk + individual sponsor + core staff • 2016: ???
- 9. Summary of this talk
- 10. Summary of the talk • About of human error. (human factors) • How to reduce human error? • The hint for reducing of human error factors • by technology/technic
- 11. Agenda 1. Human Error 2. How to notice human error factors? 3. How to reduce factors by engineering? 4. Approaches by engineering 5. Conclusion
- 12. Human Error
- 13. We need safe code • Don’t want to crash application • Don’t want to mistake the code operation • Don’t want to destroy data • Don’t want to break code when modified
- 14. What is human error?
- 15. Human error ≒ mistake
- 16. Human error is … • The word of human factors field • David Meister defined: • “a deviations from the requested performance by system.” • source: “Human factors: theory and practice”
- 17. POINT: Human error is … • In our context: operator = another developer • It’s defined in a operator’s context • Engineers create a system and operate it ourself. • So we should think that a developer and a operator are different person.
- 18. POINT: Human error is … • “System” means … • a infrastructure • a application • a source code • etc…
- 19. Why happen a human error?
- 20. Factor of human error • grouping by factor: • Human factor • Management factor • Environment factor
- 21. Human factors • Direct factor: • A carelessness • A mistake
- 22. Approach for human factors • Control arousal level • Pointing confirmation • Accident prediction training • NKY Training
- 23. Management factors • Indirect factor: • Not enough direction • Not enough review
- 24. Approach for management factors • Work flow improvements • Simplification of proces • Code review • Documentation • Automation
- 25. Environment factors • Indirect factor: • Difficult to understand • Complex ways • Tend to overlook a mistake • Tend to make mistakes
- 26. Approach for environment factors • Make it easy to understand • Simple ways • Tend to notice a mistake • Prevent/Safe a mistake
- 27. CONCLUSION of this section • Human error ≒ mistake • Think in another developer's point of view • Is it difficult to understand? • Are there complex ways? • Is it be tend to overlook a mistake?
- 28. Agenda 1. Human Error 2. How to notice human error factors? 3. How to reduce factors by engineering? 4. Approaches by engineering 5. Conclusion
- 29. How to notice mistake factors?
- 30. near-miss • In Japanese “ヒヤリ・ハット” • Accidents that cause no loss/injuries/damage
- 31. Heinrich's law “that in a workplace, for every one major injury accident there are 29 accidents that cause minor injuries and 300 accidents that cause no injuries (what are often termed “incidents”), roughly a 1-30-300 proportioning.”
- 32. Heinrich's law serious accident slight accident near-miss frequency
- 33. POINT: Heinrich's law A mistake factor makes many near-misses
- 34. Be careful near-miss! • Tend to overlook • because not loss/injuries/damages • Resolving near-misses prevents incidents
- 35. How to find near-misses factors?
- 36. Collect the case of near-misses
- 37. How to collect the case of near-misses?
- 39. Github issue is awesome • Tag is awesome • CRITICAL/LITE/ARCH/CODE/etc.. • Engineer friendly • Easy to link with code
- 40. Code review • Get a operator points of view • Find a factor of near-miss • Create issue soon • Analyze and fix it
- 41. CONCLUSION of this section • Resolving near-misses prevents incidents • Should collect the case of near-misses • GitHub issue is good • Code review is good approach • for finding a factor of near-misses
- 42. Agenda 1. Human Error 2. How to notice human error factors? 3. How to reduce factors by engineering? 4. Approaches by engineering 5. Conclusion
- 43. How to reduce mistake factors by engineering?
- 44. Environment factors can be reduced by engineering
- 45. How to reduce environment factors?
- 46. Approaches • Easy to understand • Simple ways • Tend to notice a mistake • Prevent/Safe a mistake
- 47. break..
- 48. Agenda 1. Human Error 2. How to notice human error factors? 3. How to reduce factors by engineering? 4. Approaches by engineering 5. Conclusion
- 51. Easy to understand • Readable code • Descriptive naming • Code document/comment • Less side effects
- 52. Readable code • Read it!!!!!!!!!!!!!
- 58. Code document/comment • This does know you(developer) only! • ”Why this approach is used?" • "Why this workaround is needed?" • etc.. • But, Operator needs this information.
- 59. Less side effects • No any side effects is best. • But, we uses ... • database • view • and ...
- 60. Less side effects • Approach: • (Don't use global variable) • Shorten object lifecycle • Immutable(Readonly) object/value • Functional programming
- 61. Shorten object lifecycle • Less status changes reduces side effects • Object has statuses • Make object in a minimum of scope
- 63. Immutable object/value • Immutable object don't have any statuses • It reduces side effects • No logic depend on mutable status • It makes many side effects in many cases • Immutable object makes immutable status
- 64. Immutable object/value • Immutable variable: • Swift:let / Java:final / Kotlin:val / Scala:val • Perl: (Library makes readonly value) • Readonly.pm/Const.pm • Internals::SvREADONLY
- 65. Immutable object/value • Immutable object: • Value object pattern
- 66. Functional programming • This is one approach for that the status is closed in minimal scope • The status is closed in function • The side effect is close in monad • (But, I don’t know too much this field.)
- 67. Simple ways
- 68. Simple ways • Immutable object/value • Shallow nested code • Modularization
- 69. Shallow nested code • Don't write deeply nested code • Deeply nested code has many statuses • It’s not simple • Solution: structured programming • Split code to other function
- 70. Modularization • Operation of the procedure should be a simple. • Operator need High-Level API • Practice structured programming
- 71. Tend to notice a mistake
- 72. Tend to notice a mistake • Type restriction/checking • strict.pm / warnings.pm (Perl) • Static code analysis (Perl::Critic/Perl::Lint) • Optional • Assertion • Automated test
- 73. Type restriction // Java package org.yapcasia.app; public class DB { public Prepare select (Query query) { // … } }
- 74. Type checking ## Perl use Smart::Args; sub select { args my $class => ‘ClassName’, my $sql => ‘FooDBI::Query’; … }
- 75. What's the good point of type restrict/checking? • Checks type at compile-time or run-time • Notices that type is incorrect • When type is incorrect • Operator probably made a mistake
- 76. strict.pm ## Perl (no strict.pm) $foo = 1; # it pass ## Perl (enabled strict.pm) use strict; $foo = 1; # compile time error # my $foo = 1; # *MUST* declare `my` variable # $foo = 2; # can use declared variable *ONLY*
- 77. What's the good point of strict.pm? • Notices the typo at compile-time • Difficult to use is a bad way in strict mode • e.g.) soft reference • SEE ALSO: perldoc strict
- 78. warnings.pm ## Perl (no warnings.pm) my $answer = ‘3:’ + 2; # => 5 (!?) ## Perl (enabled warnings.pm) use warnings; my $answer = ‘3:’ + 2; # => 5 (!?) # WARN: Argument "3:" isn't numeric in addition (+) at …
- 79. What's the good point of warnings.pm? • Notices the incompatible implicit type conversion at run-time • and some warnings are available • SEE ALSO: perldoc warnings
- 80. Static code analysis • Finds popular mistakes. • in Perl: Perl::Critic/Perl::Lint • in JavaScript: ESLint/JSLint/JSHint/etc.. • in Java: FindBugs/etc.. • in Swift: (I’m needing it, but not found yet..)
- 81. Optional // Swift var foo : Int? = someNilableLogic() if let notNilFoo : Int = foo { // notNilFoo is not null } println(“(foo + 1)”) // it makes compile-time error
- 82. What's the good point of Optional • Ensures the safety of access to nullable value • in compile-time • not need to check null manually • Maybe monad can also be used as well • .. maybe :p
- 83. Assertion /*** C ***/ int i = 1; i = add(i, 2); assert(i == 3); /* abort when `add` is broken */
- 84. What's the good point of Assertion • Prerequisites becomes clear • Notices when the precondition is lost • in run-time • C++11: static_assert • checks assertion at compile-time
- 85. Automated test • No explanation needed :)
- 87. Prevent/Safe a mistake • defer, guard object, try-with-resources • Max reqs per child • Poka-yoke
- 88. defer // Swift 2.0 (XXX: not checked yet) let fd = open(filename, O_RDONLY) defer { close(fd) } … // Go fh, err := os.Open(filename) if err != nil { panic(err) } defer f.Close()
- 89. guard object ## Perl use Guard; my $sock = IO::Socket::INET->new(…); my $guard = guard { close($sock) }; …
- 90. try-with-resources ## Java7 try (FileReader r = new FileReader(filename)) { // … }
- 91. What's the good point of defer, guard object? • Auto release the resources • at appropriate timing • in appropriate scope • not need to release the resources manually
- 92. Max reqs par child • “Limit on the number of requests that an individual child server will handle during its life” (Apache) • When the memory leak occurs • The problem is reduced
- 93. Poka-yoke • In Japanese “ポカヨケ” • The gimmick prevents mistake physically • Example: Operator need shutdown a server • When that the target server is used: • Cannot shutdown
- 94. CONCLUSION of this section • There is engineering approaches for • notice/reduce/prevent near-misses • run-time check is good • compile-time check is very good • Static typing language is awesome
- 95. Agenda 1. Human Error 2. How to notice human error factors? 3. How to reduce factors by engineering? 4. Approaches by engineering 5. Conclusion
- 96. CONCLUSION
- 97. Conclusion • Think in another developer's point of view • “Is it easy to understand?”, “Is it simple?” • Resolving near-misses prevents incidents • Should store the case of near-misses • GitHub issue is good
- 98. Conclusion • Good approach: • Easy to understand • Simple ways • Tend to notice a mistake • Prevent/Safe a mistake
- 99. TMTOWTDI :)
- 100. Let’s find the new safety approach!
- 101. Please vote me!
- 102. Thank you for listening
- 103. Any questions?