Алексей Ященко и Ярослав Волощук "False simplicity of front-end applications"

Yaroslav Voloshchuk && Aleksey Yashchenko
Grammarly
False Simplicity
of Frontend Applications

• Who we are?
• Software Engineers @ Grammarly
• Working on …
• Past
• Browser Extension
• Present
• Web Editor
• Desktop Editor

Our Talk: Overview
• [Done] Who we are
• => Overview (this slide :D)
• Complexity assessment mistake: why it happens?
• How to get it right?
• How to deal with complexity on the code level?

Our Talk
• [Done] Overview
• => Complexity assessment mistake: why it happens?
• How to get it right?

1. Why and how it happens
• People don’t understand the problem they are solving
• Incomplete requirements
• Edge cases not taken into account
• 3rd party libraries/components are being used
• …

2. The process
• Planning and resource allocation
• Choosing approach, architecture, tools
• Coding
• Release :(
• …

2. The process
• …
• Details appear in the process ‘out of the blue’
• It’s a small change!
• Let’s add one `if`
• [Repeat]
• Code => Spaghetti
• Release?

2. The process
• …
• [Repeat]
• Release… :(
Can you just add this button please?
Shouldn’t be too hard!

2. The process
• …
• [Repeat]
• Eternal release… soon :( Release… :(

3.1. Technical Results
• Unsupportable, write-only code
• Instant legacy in a new product
• Undermining architectural effort; non-optimal solution
completely ruins the architecture

3.1. Product Results
• Bugs
• Unexpected behavior
• A lot of product areas are underdeveloped
• Team’s moral & spirit is affected

Okay, smarty, what to do?
• Get complexity right
• Address it on the code level

Our Talk
• [Done] Overview
• [Done] Complexity assessment mistake: why it
happens?
• => How to get it right?

Describe the problem in more details
• Talk to colleagues, specialists,  
non-specialists, and to the debug duck
• Run a requirements testing with QA engineers
• Ask how to break a feature before you write it,
brainstorm corner cases
• Ask how a feature will develop in 1-2 years from now
• Look how it’s done by competitors, think why

Describe the problem in more details:Tools
• => Design mockups & prototyping
• Build models
• Plain old multileveled list
• Mind maps
• Draw a state chart (state diagram) with events and
transitions
• User story mapping

• Design mockups & prototyping
• => Build models
• Mind maps
transitions

• Build models
• => Plain old multileveled list
• Mind maps
transitions

• Build models
• => Mind maps
transitions

• Build models
• Mind maps
• => Draw a state chart (state diagram) with events and
transitions

• Build models
• Mind maps
transitions
• => User story mapping (well, we don’t use it :))

• …
• You name it! 
 
 
 
Describe the problem in more details

Complexity Assessment:
But don’t go waterfall!

Okay…  
Houston, we have
a complex problem,
what now?

Our Talk
• [Done] Overview
• [Done] Complexity assessment mistake: why it happens?
• [Done] How to get it right?
• => How to deal with complexity on the code level?

–Edsger W. Dijkstra
“The art of programming is  
the art of organizing complexity”
–Anonymous
“Programming is all about composition”

Complexity?
• Wikipedia: In software engineering, programming
complexity is a measure of the interactions of the
various elements of the software.
• Level of entropy
• More: https://en.wikipedia.org/wiki/Complex_system

Where it came from?
• Essential complexity
• Input
• Output
• Accidental complexity
• Everything else we created 
 
- Brooks, Fred (1986).“No Silver Bullet”

• Coupling  
how tightly a module is related to others
• Cohesion  
how closely all the routines in a module support it’s
central purpose 
 
 
 
 
 
 
Characteristics

• Readability
• Maintainability
• Branching (Cyclomatic complexity)
• Size (LOC)
• More buzzwords:  
https://en.wikipedia.org/wiki/Programming_complexity 
Characteristics

It occurs at different levels
• Statements
• Methods
• Modules / Classes
• App / Subsystems
• Product / Requirements
Structural
Behavioral

1. Statements
• const vs let 
Use const everywhere
• for, while, if, break =>  
foreach, map, reduce, filter, find, ...
• Try, Option 
Idiomatic handling for empty values and errors
• With this you mostly don’t need defensive
programming

Idiomatic handling for empty values and errors
export function parseConfig(
base: AppConfig,
localConfig: Option<string>
): AppConfig {
return localConfig
.flatMap(config =>
Try.of(() => JSON.parse(config)).recover(() => window.atob(config)).toOption()
)
.flatMap(
parsedConfig =>
iots
.validate(parsedConfig, ConfigType)
.map(validConfig => merge(base, validConfig)) // Load app with custom config
)
.getOrElse(base)
}

2. Functions/Methods
• Prefer pure functions
• Prefer polymorphism to if statements
• Single responsibility
• Don’t break invariants
• Use composition with functions.  
They are ﬁrst class citizens (thus: memoization, strategy,
pipeline, etc)
• Make it understandable without reading the method body

Prefer polymorphism to if statements
////// Don’t
function logMessage(message: string) {
remoteLoggerSink.send(message)
if (Config.printToConsole) {
console.log('LOG: ' + message)
}
}
////// Do
function logToRemote(message: string) {
remoteLoggerSink.send(message)
}
function logWithConsole(message: string) {
logToRemote(message)
console.log('LOG: ' + message)
}
const logMessage = Config.printToConsole ? logWithConsole : logToRemote

Don’t break invariants
/// Don’t
const alert = Alerts.createAlert(alertData)
// ...
// then
alert.register(positionManager)
/// Do
const alert = Alerts.createAlert(alertData, positionManager)

Make it understandable without reading the
method body
// Don't
function parse(data) {
// 20 LOC body to read
}
// Do
function parseConfig(configJson: string): Try<Config> {
// Whatever
}

3. Modules/Classes #0
• Use Types
• Use Types
• Use Types
• If in doubt => Use Types

• Use Types
• Use Types
• Use Types
• If in doubt => Use Types 
 
Flow
TypeScript
Elm
PureScript
OCaml (BuckleScript)
…

• Liskov substitution principle

3. Modules/Classes #1: SOLID
• Single responsibility principle
• Open/closed principle
• Liskov substitution principle
• Interface segregation principle
• Dependency inversion principle

Single responsibility principle
const alerts: Alert[] = alertsManager.allAlerts()
// Don’t
const scoreString: string = calculateScore(alerts)
// Do
const score: Score = calculateScore(alerts)
const scoreString: string = jsonSerializer(score)

Open/closed principle
class TrackingClient {
// ...
track(event: TrackingEvent) {
fetch(this._endpoing, { /* payload */ })
}
}
class TrackingClient {
// ...
constructor(private _fetch = fetch) {
}
track(logEntry: TrackingEvent) {
this._fetch(this._endpoing, { /* payload */ })
}
}

Liskov substitution principle
interface ImmutablePoint {
readonly x: number
readonly y: number
}
// Wrong, violates contract
interface MutablePoint extends ImmutablePoint {
x: number
y: number
}

Dependency inversion principle
namespace Bad {
class A {}
class B {
// Direct dependency creates stronger coupling
constructor(param: A) {}
}
}
namespace Good {
interface A {}
class B {
// Dependency on abstraction, allows any impl here
constructor(param: A) {}
}
class AImpl implements A {}
}

• Data hiding/encapsulation
• Separation of concerns
• Composition over inheritance
• Invariance in types
• Algebraic data types

enum RequestState {
loading,
ready,
error
}
interface Loading {
state: RequestState.loading
}
interface Ready {
state: RequestState.ready
data: string
}
interface Error {
state: RequestState.error
error: any
}
type Request = Loading | Ready | Error
function proccesRequest(request: Request) {
switch (request.state) {
case RequestState.loading: return console.info('request in progress')
case RequestState.ready: return console.log('response', request.data)
case RequestState.error: return console.error('error =(', request.error)
default:
const state: never = request
throw new Error('Unexpected state')
}
}
Algebraic Data Types

buzzwords…
YAGNI
DRY
Stable Dependencies Principle
Stable Abstractions Principle
KISS
MDA
Monoids
GRASP
Code Generation
Currying
Continuations

4. Subsystems/Apps
• Don’t reinvent the wheel:There is an app library for that!
• Grab a good runtime library  
(ramda, immutable.js, lodash-fp, etc, still not clear for TS thou)
• Read more papers, e.g.  
https://github.com/papers-we-love/papers-we-love
• Use existing design patterns which address your problem
• Use suitable data structures instead of arrays/objects
• Use frameworks/libraries that ﬁt your task

Behavioral Complexity
• Callbacks hell
• PubSub aka Emitter hell
• FRP comes to the rescue!
• Event Streams (Signals/Observables) > Events
• RxJS, Bacon.js, Keﬁr, Highland

hoveredMarks = this.options.scrollContainer
.map(scroll => scroll.getOrElseL(() => this.quill.root))
.switchMap(container =>
Observable.merge(
Observable.fromEvent(container, 'mouseenter').mapTo(true),
Observable.fromEvent(container, 'mouseleave').mapTo(false)
)
)
.switchMap(
inside =>
inside
? Observable.merge(
this.options.contentUpdated.mapTo(None),
this.options.scrollPositionChanged.mapTo(None),
Observable.fromEvent<MouseEvent>(this.quill.root, 'mousemove')
.auditTime(50)
.map(e => {
const node = document.elementFromPoint(e.clientX, e.clientY)
const blot = Quill.find(node, true) as Blot
return !blot || blot instanceof Quill
? None
: this._getMarksByBlot(blot)
})
)
: Observable.of(None).delay(200)
)
.distinctUntilChanged(this._optionMarksEqual)
.share()
.startWith(None)

Yaroslav Voloshchuk
@wenqer
LI:yaroslavvoloshchuk
Aleksey Yashchenko
@tuxslayer
FB/LI:tuxslayer

Further reading  
Articles on Requirements & Complexity
• Programming complexity https://en.wikipedia.org/wiki/
Programming_complexity
• Cyclomatic complexity https://en.wikipedia.org/wiki/
Cyclomatic_complexity
• No Silver Bullet http://www.cs.nott.ac.uk/~pszcah/G51ISS/Documents/
NoSilverBullet.html
• SOLID https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
• The Coming Software Apocalypse https://www.theatlantic.com/
technology/archive/2017/09/saving-the-world-from-code/540393
• User story mapping https://www.scrumalliance.org/community/articles/
2013/august/creating-an-agile-roadmap-using-story-mapping

Further reading 
Useful papers, articles and tech
• Papers we love  
https://github.com/papers-we-love/papers-we-love
• FP vs OOP  
http://blog.cleancoder.com/uncle-bob/2014/11/24/
FPvsOO.html
• AirBnb Sketch App  
https://github.com/airbnb/react-sketchapp
• FSM  
https://en.wikipedia.org/wiki/Finite-state_machine

Further reading 
Books and stuff
• Code Complete
• FRP https://www.manning.com/books/functional-reactive-programming
• Refactoring: Improving the Design of Existing Code
• UML Distilled: A Brief Guide to the Standard Object Modeling Language
• Head First Design Patterns
• Learning JavaScript Design Patterns
• TypeScript Deep Dive https://www.gitbook.com/book/basarat/typescript/details
• Functional JavaScript http://shop.oreilly.com/product/0636920028857.do
• FP in Scala https://www.manning.com/books/functional-programming-in-scala
• PureScript https://leanpub.com/purescript/read
• Learn You a Haskell for Great Good http://learnyouahaskell.com

Алексей Ященко и Ярослав Волощук "False simplicity of front-end applications"

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Алексей Ященко и Ярослав Волощук "False simplicity of front-end applications"

Similar a Алексей Ященко и Ярослав Волощук "False simplicity of front-end applications" (20)

Más de Fwdays

Más de Fwdays (20)

Último

Último (20)

Алексей Ященко и Ярослав Волощук "False simplicity of front-end applications"