Diferencia entre revisiones de «Solución ejercicio Fibonacci»

Revisión del 22:16 24 oct 2013

Preparación

Empecemos primero haciendo una copia del proyecto: git clone https://github.com/bitsandbooks/py-fibonacci.git Una vez ya clonado, vamos a la carpeta donde se ha descargado cd py-fibonacci y abrimos el archivo gedit fibonacci.py para analizarlo con detalle.

Identificación y Análisis del Problema

Hacemos unas cuantas pruebas para verlo funcionar:

 
>>python fibonacci.py
Traceback (most recent call last):
  File "fibonacci.py", line 11, in <module>
    sys.argv[1] # The first argument after the program name.
IndexError: list index out of range

>>python fibonacci.py 8
[0, 1, 1, 2, 3, 5, 8, 13]

>>python fibonacci.py 8 9 10
[0, 1, 1, 2, 3, 5, 8, 13]

Como podemos ver, el problema es que no se controla el número de parámentros de entrada, simplemente lee el primer parámetro que recibe.

 
times = int(  # Force the parameter to be an integer.
  sys.argv[1] # The first argument after the program name.
)

Reporte en Mantis

Ahora que ya ha sido identificado el problema es momento de reportarlo en Mantis. Vamos a la sección de Report Issuesy seleccionamos el proyecto Fibonacci. Luego rellenamos la plantilla y para generar el reporte le damos a Submit Report.

Como bien sabemos, mientras más información aportemos sobre un problema, será mucho más rápido poder encontrarle una solución. Pero tengamos en cuenta también que la información debe de ser clara, precisa y concisa. Una buena práctica es incluir capturas de pantalla en ella.

Solución del problema

Una vez ya visto cuál es el problema, planteemos soluciones a este problema y busquemos cuál sería la más indicada.

Una posible e intuitiva solución sería añadir en un condicional al inicio, es decir, si se recibe un único parámetro, la ejecución continúe normalmente, en caso contrario, si no recibiera parámetros o si recibe más de uno, se mostraría un mensaje de error indicando que debe sólo funciona con un sólo parámetro.

if len(sys.argv)!=2 :
  print "Sorry, it works only with one paremeter."
else :
  times = int(  # Force the parameter to be an integer.
    sys.argv[1] # The first argument after the program name.
  )

  # Define a function (fib) which takes one parameter (t).
  def fib(t):
    f = [ 0, 1 ]

    for i in range(len(f),t): 
      fn = f[len(f)-1] + f[len(f)-2]
      f.append(fn)
  
    print f

  fib(times) # Call function fib and pass the value of times as its parameter.

Otra posible solución sería incluir un condicional donde si no se cumple la condición de recibir un único parámetro, muestre un mensaje de error informando al usuario de las restricciones y luego abortar la ejecución.

if len(sys.argv)!=2 :
  print "Sorry, it works only with one parameter"
  sys.exit()

times = int(  # Force the parameter to be an integer.
  sys.argv[1] # The first argument after the program name.
)

# Define a function (fib) which takes one parameter (t).
def fib(t):
  f = [ 0, 1 ]

  for i in range(len(f),t): 
    fn = f[len(f)-1] + f[len(f)-2]
    f.append(fn)
  
  print f

fib(times) # Call function fib and pass the value of times as its parameter.

Obteniendo en ambas la funcionalidad esperada:

Para poder elegir qué solución es la más adecuada para tener un buen seguimiento, veremos el impacto que tiene cada una usando git.

Realizamos el commit de la primera solución con: git commit fibonacci.py y explicamos qué es lo que hicimos.

Ahora veremos el registro de cambios en git, usando git log , ubicamos el identificador del commit que hicimos según el título que pusimos al realizar el commit. Luego usando git show TU_IDENTIFICADOR podemos ver qué cambios se han efectuado en el commit.

Como podemos ver, hay demasiados cambios aunque a simple vista el código parecía haberse mantenido, esto es debido a que el lenguaje python exige tener un estructura de jerarquía en el código y para tenerlo había que modificar todas las líneas que tenían que ir dentro del if y else . Esto no quiere decir que la solución sea incorrecta, sino que al momento de revisar los cambios se vuelve demasiado engorroso para la vista.

Hacemos lo mismos pasos con la segunda solución y obtenemos:

A esta solución es mucho más fácil seguirle sus cambios, ya que presenta menos cambios y sobre todo no tiene cambios redundantes como la primera solución.

Concluimos en que hay que buscar siempre una solución la cual involucre muy pocos cambios sintácticos en el código, los justos y necesarios, ya que de esta forma estaremos aprovechando mucho mejor el seguimiento de cambios usando git.