Skip to content

Latest commit

 

History

History
116 lines (92 loc) · 3.89 KB

Software Engineering.page

File metadata and controls

116 lines (92 loc) · 3.89 KB
Raw

TODO merge in notes from sweng class

game development

  • asm is still freq used
  • c++ is the de facto std bc of physical memory control (rather than raw perf)
  • often have heavy duty scripting infrastructure
  • equal numbers of engineers/artists, with slightly fewer designers (scripters)

concepts

  • scrum
  • dependency injection: a way of structuring your code for testability
    • banish global state/singletons
    • explicitly pass objects/object factories around to ctors
    • ctors are very simple
    • initialize object/object factory graph at startup
    • easy to substitute different implementations for testing

characterizing and predicting which bugs get fixed: emp study of ms win (philip guo)

  • bug fixing is imp; triaging is hard
  • ms emp data on vista/7: bug lifetime, employee info
  • qualitative survey to win devs with 20% response rate
  • main question: how do factors related to ppl and bug report edits affect whether bug is fixed?
    • reputation, interest, reassignments, distance
  • prev paper on bug triaging: bug opener reputation = |opened cup fixed| / (|opened| + 1)
    • +1 encourages more bug reports
  • built predictive model: logistic regression with 7 factors
    • source, rep of opener, rep of first assignee, severity, opened by temp?, opener/assignee in same team?, same bldg?
    • 68% prec 64% recall (.5 cutoff)

anecdotes

  • oopsla09: nasa jpl uses model checking (heavy duty theory) and static analyses (less theoretical but still highly useful)

Exploding Software-Engineering Myths

  • http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx
  • code coverage is not a good metric
  • TDD team 60-90% better in terms of defect density than non-TDD
  • assertion/verification count negatively correlated with bug count
  • org structure matters a lot: org metrics can predict SW failure-proneness with precision & recall of 85%
  • geo distance doesn't matter much

writing solid code

  • use warnings, static checkers, unit tests
  • use assertions and debug-only backup algos
  • use subsystem integrity checks: dangling ptrs, lost mem blocks, use of uninitialized mem
  • use debugger and step
  • use good design to create simple single-purpose functions
  • use safer alternatives to risky algos/lang idioms
  • avoid bad practices
  • attitude & habits

companies

facebook software engineering

facebook release engineering (chuck rossi)

  • releng team has 2-3 ppl
  • no QA team
  • push 2x/day
  • fb used svn (now hg)
  • branches: commit to trunk. on sun, trunk -> latest. on tue, latest -> release.
  • dogfooding: all fb employees forced to use latest
  • each weekday has different volume/nature of pushes (i assume meaning into release branch). this seems cultural. enforced using his feedback/karma system.
    • mon: few pushes
    • tue: big release push
    • wed: many pushes (fixing up tue things)
    • thu: med pushes
    • fri: few pushes (weekend approaching)
  • tries to prevent multiple large changes from going in the same time.
  • tools: gatekeeper, bittorrent
  • http://www.infoq.com/presentations/Facebook-Release-Process
  • https://vimeo.com/56362484

google chrome

  • trybot farms; can submit your changelists
  • use gtest, gmock, valgrind, thread sanitizer

linux

formal methods