Lo que todo programador
debe saber

Historia

¿Cuál fue el primer computador eléctrico?

Colossus - 1942

¿Cómo se llama
esta arquitectura?

Arquitectura Von Neumann - 1945

¿Cómo se veía el
código de los
primeros computadores?

B8 22 11 00 FF
01 CA
31 F6
53
8B 5C 24 04
8D 34 48
39 C3
72 EB
C3

¿Cómo se veía el
código en ensamblador?

foo:
movl $OxFF001122, %eax
addl %ecx, %edx
xorl %esi, %esi
push1 %ebx
movl 4{%esp}, %ebx
leal (%eax, %ecx, 2), %esi
cmpl %eax, %ebx
jnae foo
retl

¿Cuáles fueron los primeros lenguajes de alto nivel?

  • FORTRAN - 1957 (John Backus)
  • ALGOL - 1958
  • Copias Isomórficas
    de la arquitectura
    Von Neumann

¿Por qué debían
ser copias isomórficas?

Desempeño -
"Close to the hardware"

¿Cuál fue el primer lenguaje de programación funcional?

LISP - 1958 (John McCarthy)

LISP - Un lenguaje que un matemático pudiera amar

¿Cómo se llama el primer lenguaje que usó objetos?

Simula - 1967 (Ole-Johan Dahl y Kristen Nygaard)

Simula - Permite una abstracción sobre
el hardware.
Bajo desempeño.
Interés académico.

¿Qué lenguaje popularizó
la programación?

C - 1972 (Dennis Ritchie)

C - Creado para diseñar sistemas operativos
"Close to the hardware"

¿Cuál fue el primer lenguaje orientado por objetos?

Smalltalk - 1972 (Alan Key)

Modelo de Actores - Modelo matemático
para la computación concurrente
- 1973 (Carl Hewitt)

Influído por Smalltalk

"Can Programming Be Liberated from the von Neumann Style?"

John Backus - 1977

Llamado a no usar copias isomórficas del hardware. Alrededor de ese paper se acuñó el término FP

Dado que no era
"Close to the Hardware"
la industria desestimó
la FP como de puro
interés académico

Características de la
FP que la hacían de
"bajo" desempeño

  • Garbage Collector
  • Dynamic Typing
  • Recursion
  • etc

Hoy día todas son características estándar
de lenguajes exitosos

¿Qué lenguaje
popularizó la OOP?

C++ - 1983
(Bjarne Stroustrup) 

Década de los 90
Backus tenía razón
 Dificultad para Programación de GUI's

C++

  • Se volvió un estándar
    de facto por GUI's
  • Abstracción sobre el hardware
  • "Close to the hardware"
    porque se implementó sobre C

¿Cuál fue el primer lenguaje FP exitoso de la industria?

Erlang - 1986

Erlang - Creado para diseñar el SO para Ericsson. Basado en el
modelo de Actores

¿Cuál es el lenguaje
FP por excelencia?

Haskell - 1990

¿Cuál es el primer lenguaje en abiertamente mezclar
la FP y la OOP?

Scala - 2004

El catalizador de la FP
fue la programación
en múltiples núcleos

Hoy en día, todos los lenguajes de programación populares, tienen características de FP

La historia nos muestra que usualmente no hay ideas "superiores" a otras. Unas se complementan a otras.

Sacar lo mejor de
las ideas disponibles

Lenguajes de Programación

¿Cuántos?

Expertos coinciden en ~5

¿Cuáles?

  • Diferentes Paradigmas
  • Diferentes Sintáxis
  • Diferentes Audiencias

¿Cuál es el primero?

El que use en su trabajo

Lenguaje Actual

  • Pasado
  • Presente
  • Futuro

LISP

  • FP
  • Sintaxis extraña
  • Activo

C

  • Imperativo
  • El padre de los lenguajes

C++

  • OOP
  • Sin Garbage Collector
  • Pionero en muchas ideas

Java

  • Lenguaje OOP más usado
  • Comunidad muy grande
  • JVM

C#

  • OOP
  • Microsoft
  • LINQ

JS

  • Lenguaje FP más usado
  • Comunidad muy grande

Koitlin

  • Lenguaje JVM
  • OOP + FP
  • Android

Go

  • Sistemas embedidos
  • Imperativo
  • Google
  • Simplista

Clojure

  • Dialecto LISP
  • Lenguaje JVM, JS y CLR

Python

  • OOP + FP
  • Data Science
  • Muy usado por Google

Swift

  • OOP + FP
  • iOS

Groovy

  • OOP + FP
  • Lenguaje JVM
  • Muy cercano a Groovy

Otros

  • Scala
  • Ruby
  • PHP
  • etc

¡Aprenda un lenguaje nuevo cada año!

OOP

OOP

  • Clases, Objetos, Tipos de Datos
  • Encapsulamiento
  • Herencia: Interfaces y Clases Abstractas
  • Polimorfismo

Frameworks

¡NINGUNO!

Si usted conoce los principios de programación, un FW se aprende rápidamente

Principios de Programación

Principios SOLID

  • SRP
  • OCP
  • LSP
  • ICP
  • DIP

Single Responsibility

  • Una clase debe tener una
    sola razón para cambiar
  • Alta Cohesión
  • No abusar de static

Open Close

  • Una clase debe estar abierta a la
    extensión pero cerrada a la modificación
  • Agregar funcionalidad sin
    romper código ya existente
  • Patrones de Diseño

Liskov Substitution

  • Un método que recibe un parámetro
    de tipo T debería funcionar correctamente
    con cualquier subtipo de T
  • No abusar de la herencia
  • Preferir substitución
    (delegación) sobre herencia

Interface Segregation

  • Una clase que implementa una
    interface no debería estar forzada
    a usar métodos que no necesita
  • Las interfaces deberían ser pequeñas
  • Cada interface representa una "vista"
    sobre una característica de un objeto

Dependency Inversion

  • Los módulos de alto nivel no deberían
    depender de módulos de bajo nivel
  • Use interfaces en: valores de retorno,
    parámetros y atributos

Dependency Injection

  • Una clase no debería instanciar un "colaborador"
  • Esas dependencias deberían ser inyectadas
  • Diferencias en: Constructor, setter y atributo
  • NO depende de un FW

Don't Repeat Yourself - DRY

  • Evitar la repetición del código
  • Evita sistemas inconsistentes

You Aren't Gonna Need It - YAGNI

  • Implementar solo lo
    que se nos impide
  • Optimizar recursos

Patrones de Diseño

Los Patrones de Diseño
NO están obsoletos.
La FP NO los reemplaza

Template

  • Representa un algoritmo
    expresado con métodos abstractos
  • Implementa un proceso con
    pasos que pueden ser especializados
  • Muy útil en el mundo web
    y diferentes usuarios

Factory Method

  • Un método que
    construye un objeto
  • Esconde la implementación
    de una interface
  • Versión lite

Command

  • Encapsula una acción
    para ser ejecutada después
  • Las expresiones lambda
    muestran su poder,
    pero no lo reemplazan
  • Útil para operaciones
    de "deshacer"

Strategy

  • Modifica el comportamiento
    de un método en tiempo de ejecución
  • Útil para implementar algoritmos resilentes

State

  • Modela clases que cambian
    su comportamiento según su "estado"
  • Modelan naturalmente "máquinas de estado"

Builder

  • Separar el código de construir
    un objeto de sus métodos
  • Permite construir un
    objeto de muchas maneras
  • Evita listas de parámetros confusas

Decorator

  • Agrega funcionalidad a
    un método existente sin modificarlo
  • Varios ejemplos en API's muy usados

Observer

  • Establece una relación
    1 a muchos entre clases
  • Desacopla la clase donde ocurre
    un "evento" y la clase que
    reacciona a este evento
  • Base de Programación Reactiva

Visitor

  • Separa un algoritmo de las clases sobre las que opera
  • Muy parecido a Pattern Matching

Singleton

  • Permite asegurar que solo se crea
    una instancia de una clase
  • Fácil de abusar...
  • ... pero útil en otros casos
  • Sepa cuándo usarlo

Pruebas Unitarias

La utilidad de las pruebas unitarias no debería ser discutida ¿por qué no hacemos más de ellas?

Excusas para no usar pruebas unitarias

  • No me lo permiten
  • Toma el doble del
    tiempo escribirlas
  • Es muy difícil

No deberíamos pedir "permiso", ¡es nuestra responsabilidad escribir código que funcione!

Y no, no toma el doble
de tiempo escribir código con pruebas unitarias,
si no las has escrito entonces llevas la mitad
de lo que deberías hacer

¡Las pruebas unitarias
son en primera instancia para la tranquilidad
del programador!

¡Escribir pruebas
unitarias es una habilidad que se debe practicar!

¡Pedir ayuda está bien!

@Test
public void unStringVacioEsPalindrome() {
   assertThat(esPalíndrome(""), is(true));
}

¿Cómo debe verse la prueba unitaria perfecta?

Prueba Unitaria

  • Simple
  • Expresiva
  • Ofrecer un buen
    mensaje si falla

Las pruebas unitarias son igual de importantes, o más, que el código que se ejecuta en producción

¡Las pruebas unitarias también son documentación!

TDD

Es un proceso de codificación en que escribimos pruebas unitarias que son ayuden
a "descubrir" el diseño
de nuestra solución

3 pasos para TDD

  • Red - Se escribe una prueba unitaria que falle 

  • Green - Se escribe apenas lo necesario

    para que la prueba unitaria pase
  • Blue - Se refactoriza el código

    para hacerlo limpio

    Las pruebas se escriben de
    menor a mayor complejidad

Ventajas

  • El código suele ser más simple
  • El diseño del código es mejor
    porque se puede probar
  • Las pruebas ofrecen amplias cobertura
    y son excelentes como documentación

¿Todo debería ser TDD?

TDD es una herramienta, úsela a su discreción

Effective Programming

Kill Null

  • Nunca use Null para indicar la ausencia de un valor, use otras opciones como Optional
  • Nunca inicialice una variable con Null, sólo inicialícela cuando sepa el valor que deba tener. Siempre hay una opción (usualmente involucra crear un método)
  • Si es definitivamente imposible, trate de encapsular null detrás de una clase / librería

¿Cuándo está
bien usar null?

  • En OOP como un detalle de implementación,
    pero este no puede salir del objeto,
    p.j. retornarlo en un método

Inmutabilidad

  • Un objeto cuyo estado no puede
    modificarse una vez creado, es inmutable
  • Un objeto inmutable se puede compartir tranquilamente entre métodos / hilos
  • Así como los miembros deberían
  • "Mutability in the inside": la mutabilidad no
    es mala per se, pero lo es cuando la compartimos

La suma del costo de
bugs producidos por null
y por compartir objetos mutables debe ser del orden del billón de dólares

Todos los lenguajes populares, tienen
partes peligrosas

Ser un buen programador implica conocer este sub conjunto del lenguaje que permite escribir código seguro y expresivo

Effective <lenguaje/>

  • Effective Java
  • JavaScript: The Good Parts
  • C# in Depth
  • etc.

Clean Code

Conjunto de buenas prácticas; la más importante: los métodos deben tener un solo
nivel de abstracción

Hábitos

Hábitos

  • Usar Twitter
  • Suscribirse a blogs
  • Leer un libro cada mes
  • Ver conferencias
  • Hacer cursos en MOOC's

"No hay ningún problema que sea de alguien más"

"La regla del Boy Scout: has push de código que esté más limpio que como estaba cuando hiciste pull"

Contexto

Hoy en día hay, probablemente, cien millones de
programadores
en el mundo

Y las vacantes de trabajo sobrepasan los programadores disponibles

Y las vacantes de trabajo sobrepasan los programadores disponibles

Por eso, la cantidad de programadores se duplica cada 5 años(*)

La industria está perpetuamente en
estado de "inmadurez" (personas con menos
de 5 años de experiencia)

¿Cuántas personas
han muerto por culpa
de software?

¡Cuando el CEO de Volkswagen testificó por el escándolo de las emisiones, culpó a los desarrolladores!

No está bien que un programador diga "... es que mi jefe me dijo que tenía que hacerlo rápido"

Tenemos que aprender
a decir "NO", que no es
lo mismo que implicar
que siempre esta
bien decir "NO"

El Juramento del Programador

  1. No escribiré código maligno
  2. El código que escriba siempre
    será el producto de mi mejor esfuerzo
  3. Haré pequeños incrementos frecuentes,
    no impediré el progreso de los demás
  4. De manera implacable mejoraré el código
    a cada oportunidad, nunca haré el código peor
  5. Constantemente me aseguraré de alguien
    pueda reemplazarme y que yo pueda
    reemplazar a alguien más
  6. Haré estimados que son honestos en magnitud
    y precisión. No haré promesas sin certeza.
  7. Nunca dejaré de aprender
    y mejorando mis habilidades

Q&A

Gracias

@gaijinco

Lo que todo programador debe saber

By Carlos Obregón

Lo que todo programador debe saber

Una opinión sobre los conceptos, lenguajes y FW que todo programador, independiente de su área, debería saber

  • 176
Loading comments...

More from Carlos Obregón