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.
Software Engineering
Best Practices
Ben Gotow (@bengotow)
Computer Science ≠ Software Engineering
• Clean
• Predictable
• Maintainable
• Extensible
• Fast & Efficient
• Mathematical...
Essentials
• The Mafia Model
• Design Patterns
• Building a Shared Language
• Exceptions aren’t evil
• Anti-patterns
“Design software like
you’re running a mafia.”
• Has one well defined job. Doesn’t ask
questions.
• Has limited knowledge of the rest of the
operation. Others don’t know ...
• Single Responsibility Principle 

(Robert C. Martin)
• Separation of Concerns 

(Dijkstra)

• Avoid Side Effects

• “Pro...
Design Patterns
Patterns make it easy to communicate abstract
ideas about software.
Design Patterns
Command EmitterSingleton
Design Patterns
Command
Encapsulate a request as an object, thereby letting users
parameterize clients with different requ...
Anti-Patterns (“Code Smells”)
- Copying code into more than three places
- Calling private methods on other classes
- Insp...
Anti-Patterns (“Code Smells”)
Ex: Adding optional parameters that change the behavior of
existing code slightly. “Don’t do...
Naming Conventions
Naming things is hard, and really important
when building software on a team.
• Functions that return a value should indicate how costly that
value is to retrieve:
thread() // easy
getThread() // hmm,...
• Names should reflect intended use and give you an idea what
is returned:
onClicked() // called in response to an event
ne...
• Functions with many parameters should use named hashes:
_onComposeReply: ({thread, message, popout, behavior}) =>
• Lead...
Exceptions aren’t Evil
Throw exceptions aggressively to protect the
code you write from things it wasn’t intended for.
• I...
Exceptions aren’t Evil
😍
Code Review
https://paper.dropbox.com/doc/Code-Reviews-using-Phabricator-
LdupUMb1X9SWMyrShmhQB
Write better code, learn n...
Code Review
Code Level:
• Clarity
• Function / variable naming
• Test coverage
Architectural Level:
• Does this fit perform...
Further Reading
- Design Patterns: Elements of Reusable Object-Oriented
Software (Gang of Four)
- Clean Code: A Handbook o...
ben@nylas.com
Software Engineering Best Practices @ Nylas
Software Engineering Best Practices @ Nylas
Software Engineering Best Practices @ Nylas
Upcoming SlideShare
Loading in …5
×
Upcoming SlideShare
Best Practices - Software Engineering
Next
Download to read offline and view in fullscreen.

1

Share

Download to read offline

Software Engineering Best Practices @ Nylas

Download to read offline

Part of an introductory series given to new hires and interns, this talk is a crash course in design patterns and engineering best practices for new-grads with mostly academic computer science experience. Focuses on the things they don't teach you: naming things, working on a team, optimizing for maintainability.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Software Engineering Best Practices @ Nylas

  1. 1. Software Engineering Best Practices Ben Gotow (@bengotow)
  2. 2. Computer Science ≠ Software Engineering • Clean • Predictable • Maintainable • Extensible • Fast & Efficient • Mathematically Optimal • Uses latest language features
  3. 3. Essentials • The Mafia Model • Design Patterns • Building a Shared Language • Exceptions aren’t evil • Anti-patterns
  4. 4. “Design software like you’re running a mafia.”
  5. 5. • Has one well defined job. Doesn’t ask questions. • Has limited knowledge of the rest of the operation. Others don’t know or care how he gets the job done. • Has no secret dealings with others, clean cut actor. • Can be replaced—others could do this specific job if he was “removed.”
  6. 6. • Single Responsibility Principle 
 (Robert C. Martin) • Separation of Concerns 
 (Dijkstra)
 • Avoid Side Effects
 • “Program to an interface, not an implementation.” (Erich Gamma)
  7. 7. Design Patterns Patterns make it easy to communicate abstract ideas about software.
  8. 8. Design Patterns Command EmitterSingleton
  9. 9. Design Patterns Command Encapsulate a request as an object, thereby letting users parameterize clients with different requests, queue or log requests, and support undoable operations. (Tasks in N1 are an implementation of the Command pattern.)
  10. 10. Anti-Patterns (“Code Smells”) - Copying code into more than three places - Calling private methods on other classes - Inspecting state which was not designed to be observed - Waiting for something to happen using the wall clock setTimeout I’m looking at you. 😒
  11. 11. Anti-Patterns (“Code Smells”) Ex: Adding optional parameters that change the behavior of existing code slightly. “Don’t do this, this one time.” thread.save({tellUser: true}) thread.save().then(() => { this.tellUser(); }); Take a break, think about refactoring, explain the problem to someone else.
  12. 12. Naming Conventions Naming things is hard, and really important when building software on a team.
  13. 13. • Functions that return a value should indicate how costly that value is to retrieve: thread() // easy getThread() // hmm, probably not O(1) fetchThread() // better cache the result of this! Naming Conventions
  14. 14. • Names should reflect intended use and give you an idea what is returned: onClicked() // called in response to an event newWindow() // always returns a new object isSending() // always returns a boolean ensureReady() // may or may not do anything • Long names are almost always worth it: finalizeAndPersistNewMessage() // shit is going down Naming Conventions
  15. 15. • Functions with many parameters should use named hashes: _onComposeReply: ({thread, message, popout, behavior}) => • Leading (or trailing) underscores denote private members: _doInternalFileWrite myInstanceVar_ this._onComposeReply({
 thread: A, behavior: reply-all, popout: true }) Naming Conventions
  16. 16. Exceptions aren’t Evil Throw exceptions aggressively to protect the code you write from things it wasn’t intended for. • If your code makes assumptions, make assertions. • If you ever have the option of crashing now, or / probably/ crashing later downstream, crash now.
  17. 17. Exceptions aren’t Evil 😍
  18. 18. Code Review https://paper.dropbox.com/doc/Code-Reviews-using-Phabricator- LdupUMb1X9SWMyrShmhQB Write better code, learn new tricks, avoid shipping mistakes, develop a shared understanding of the codebase.
  19. 19. Code Review Code Level: • Clarity • Function / variable naming • Test coverage Architectural Level: • Does this fit performance requirements? • Does this follow conventions and patterns used elsewhere? • Are we comfortable with the limitations of this approach? • Are changes well contained?
  20. 20. Further Reading - Design Patterns: Elements of Reusable Object-Oriented Software (Gang of Four) - Clean Code: A Handbook of Agile Software Craftmanship (Bob Martin) - https://sourcemaking.com/design_patterns - http://en.clouddesignpattern.org
  21. 21. ben@nylas.com
  • personalBeing

    Jul. 7, 2020

Part of an introductory series given to new hires and interns, this talk is a crash course in design patterns and engineering best practices for new-grads with mostly academic computer science experience. Focuses on the things they don't teach you: naming things, working on a team, optimizing for maintainability.

Views

Total views

266

On Slideshare

0

From embeds

0

Number of embeds

0

Actions

Downloads

9

Shares

0

Comments

0

Likes

1

×