En esta nueva entrega de Script Time enfrentamos a uno de los más grandes malentendidos de la programación: “Un desarrollador solo escribe código”. Este pensamiento suele ser recurrente en los principiantes dentro de este campos aunque no es raro que personas con experiencia lo piensen igual.
Los programadores generalmente emplean el ciclo de trabajo que consiste en escribir un código, compilarlo y corregir los errores que se van generando hasta lograr un resultado medianamente aceptable. Esta es la razón por la que ninguna compañía da una garantía sobre su software.
El trabajo de un desarrollador es crear herramientas que permitan resolver problemas mediante software. Para crearlas obviamente es necesario utilizar código pero una práctica es realizar otras tareas como la especificación antes de tratar siquiera escribir una sola línea.
Una de las formas recomendadas por la ingeniería de software (No la carrera) para hacer esta clase de trabajos es luego de tomar los requisitos de un cliente realizar una tarea conocida como especificación. Esta consiste en convertir algo ambiguo como la lengua en un lenguaje que no permite ambigüedades y sea abstracto a la vez. Entre los diversos métodos contamos con lenguajes como Z, Statecharts, entre otros. Dicha tarea no es realizada necesariamente por un desarrollador sino por un especificador (puede darse el caso que sean la misma persona). El desarrollador debe convertir esa especificación en código.
Aplicar este paso intermedio ayuda a eliminar grán cantidad de posibles errores y a diferencia de lo que puede parecer agregar estas tareas suele, en el peor de los casos, costar tanto económicamente como temporalmente lo mismo que el desarrollo estándar. A pesar de sus ventajas cabe remarcar que no muchos desarrolladores conocen esta técnica.
Por último podríamos comparar ambos métodos como una montaña. La cima es el punto de partida y la base el objetivo. De un lado tenemos una superficie totalmente lisa y una caída libre y por el otro un relieve similar a escalones. La primer ladera representa el desarrollo estándar mientras que la segunda a los pasos intermedios. Hacer estas reducciones no quita todos los inconvenientes pero bien que ayuda,

Este episodio es parte de la respuesta a un escucha del podcast. Si tu tienes algún tema que te interese no dudes en proponerlo. Con gusto lo trataremos.
**********************************
App de iOS: https://itunes.apple.com/us/app/code-time/id1435749618

**********************************

Para Contribuir
PAYPAL : davidgiordana@hotmail.com.ar
PATREON: https://www.patreon.com/codetime

**********************************

Curso completo de desarrollo en Swift 4 desde cero
https://www.udemy.com/curso-completo-de-swift-4-desde-cero/?couponCode=YOUTUBE_1

Curso de desarrollo de aplicaciones para iOS 11 desde cero
https://www.udemy.com/desarrollo-de-aplicaciones-para-ios-11-desde-cero/?couponCode=YOUTUBE_1

**********************************
Medios de contacto:
Twitter / Telegram: @DavidGiordana
Correo Electrónico: davidgiordana0@gmail.com
Grupo en Telegram: https://t.me/joinchat/C-YEzBGu5Jh-mu8ejM2toA

**********************************

Medios de Contacto

CANAL DE TELEGRAM: https://telegram.me/Code_Time
PODCAST: https://goo.gl/QUximq
ITUNES: https://goo.gl/XmDjX2

**********************************
Canciones Utilizadas

OP:
A Himitsu - Adventures: youtu.be/8BXNwnxaVQE

ED:
See You Tomorrow by GoSoundtrack http://www.gosoundtrack.com/
Music provided by Audio Library https://youtu.be/idlqqMHd0W4