Вы находитесь на странице: 1из 5

Cristhian Camilo Gomez Neira

Parte 1

a.

Spartan programming strives for simultaneous minimization of several measures of code complexity. What do you think is the impact of each one of these metrics on understandability and quality?

1.

Horizontal complexity: Una complejidad horizontal elevada reduce el entendimiento del código y obliga a los programadores a pensar de mas al momento de leer código que no sea de ellos. Siempre es necesario minimizar el numero de caracteres por línea, ya que, al salir del campo de la pantalla, se pierde el entendimiento y la simplicidad del código.

2.

Vertical complexity: Al tener un numero grande de líneas por clase, se vuelve totalmente tedioso buscar algún método y mantener el hilo lógico de lo que se esta haciendo.

3.

Number of Tokens: Tener artos tokens hace que para el programador sea realmente complicado entender el código, adicionalmente entre mas grande sea el numero de tokens es mas probable que algún método este haciendo cosas de mas o que la clase no este haciendo lo especificado y que sea necesario subdividir el problema.

4.

Parameters: El generar parámetros que tengan la menor variabilidad e interacción con otros componentes eleva la modularidad del sistema, propiedad que jamás se debe dejar a un lado en cualquier desarrollo de software.

5.

Varables: Las variables hacen que el programador tenga que hacer un esfuerzo mental muchas veces innecesario para descubrir que hace cada pieza en el software, adicionalmente las variables tienden a cambiar, es por esto que es necesario eliminarlas siempre que sea posible.

6.

Loops: Los ciclos usualmente tienen un nivel de complejidad elevado, así que evitarlos ayudara a los programadores a ahorrarse tiempo entendiendo el código.

7.

Conditionals: Al igual que los ciclos el entender los condicionales se puede convertir en una tarea realmente tediosa, es por esto que cuando sea posible es mejor evitarlos.

b.

In your own words explain the Babylonian Tower principle. What is your opinion about it?

El principio de la torre de Babiliona afirma que existen niveles de abstracción para los cuales los lenguajes de programación actuales son insuficientes, es decir los

niveles de abstracción a los que podemos llegar actualmente con el software tienen un limite, no se extienden hacia el infinito. Opino que es un principio muy acertado y del cual todo desarrollador debe ser consiente, debido a que muchas veces caemos en el error de pensar que podemos llegar a abstracciones inimaginables, siendo esto irrealista y una perdida total de tiempo, cuando la abstracción llega a limites inimaginables es mejor tomar realizar soluciones especificas pero realistas.

c. Discuss at least three of the rules listed as “Minimal use of control”. Give short examples of Java code that exemplify the use of each rule.

1. Minimizing the use of conditionals by using specialized constructs such ternarization, inheritance, and classes such as Class Defaults, Class Once and Class Separator. El uso excesivo de condicionales no permite una clara lectura del codigo, ejemplo.

El siguiente código calcula el mínimo entre dos números.

No es correcto,

lectura del codigo, ejemp lo . El siguiente código calcula el mínimo entre dos números. No

Es correcto,

lectura del codigo, ejemp lo . El siguiente código calcula el mínimo entre dos números. No

2. Simplifying conditionals with early return. Existen partes en los condicionales donde en vez de sobrecargar con else o if else, podemos tener returns que hagan el trabajo que buscamos, ejemplo.

El siguiente código calcula la raíz cuadrada de un numero entero.

No es correcto,

que buscamos, ejemplo. El siguiente código calcu la la raíz cuadrada de un numero entero. No

Es correcto,

que buscamos, ejemplo. El siguiente código calcu la la raíz cuadrada de un numero entero. No

3. Simplifying logic of iteration with early exits (via return, continue and break statements). Al simplificar la logica de iteración de manera rapida, es mas sencillo leer el código y mantener un hilo lógico de lo que se esta haciendo, ejemplo

El siguiente código suma un valor entero a un arreglo de números reales, excluyendo una posición de este.

No es correcto,

reales, excluyendo una posición de este. No es correcto, Es correcto, d. What is the relationship

Es correcto,

una posición de este. No es correcto, Es correcto, d. What is the relationship between Spartan

d. What is the relationship between Spartan Programming and two well-known design rules: The Law of Demeterand The KISS principle?

Spartan programming aplica estos dos principios de forma efectiva, debido a que Spartan mantiene cada estructura de forma minimal y modular como lo busca la ley de Demeterand, y evade complejidades innecesarias como lo estipula el principio KISS. Así usar Spartan programming es una buena alternativa para mantener las buenas practicas en un equipo de software.

Parte 2

e. Make a report (it could be a table) of five type of tips reported by the plugin. For each type of tip, report your agreement/disagreement, and in case you don’t agree,explain your reasons.

Description

Resource

Path

Location

Type

Comment

Tip: Abbreviate parameter pasajes to ps in method setPasajes

Vuelo.java

/aero/src/data

line 107

Abbreviation

Corrección aceptada, debido a que es mas que claro que al usar ps se refiere a los pasajes

Tip: Abbreviate parameter vuelos to vs in method setVuelos

Aerolinea.java

/aero/src/data

line 27

Abbreviation

Corrección aceptada, debido a que es mas que claro que al usar vs se refiere a los vuleos

Tip: Convert post-increment of numero to pre-increment

Pasaje.java

/aero/src/data

line 12

Idiomatic

Corrección no aceptada, en muchas ocasiones es necesario el post increment

Tip: Inline variable line into next statement

Starter.java

/aero/src/businessLogic

line 18

Inlining

Corrección aceptada, es innecesario el uso de la variable

Tip: Inline variable v into next statement

Starter.java

/aero/src/businessLogic

line 19

Inlining

Corrección aceptada, es innecesario el uso de la variable

Tip: Remove vacuous 'super()' invocation

Aerolinea.java

/aero/src/data

line 10

SyntacticBaggage

Corrección aceptada, el llamado a super() no esta haciendo nada

Tip: Remove vacuous 'super()' invocation

Pasaje.java

/aero/src/data

line 10

SyntacticBaggage

Corrección aceptada, el llamado a super() no esta haciendo nada

Tip: Remove vacuous 'super()' invocation

Vuelo.java

/aero/src/data

line 18

SyntacticBaggage

Corrección aceptada, el llamado a super() no esta haciendo nada

Tip: Reorder operands of -

Vuelo.java

/aero/src/data

line 27

Idiomatic

Corrección aceptada, siempre es preferible ordenar las variables a operar por orden alfabetico

Tip: Reorder operands of *

Vuelo.java

/aero/src/data

line 25

Idiomatic

Corrección aceptada, siempre es preferible operar primero numeros y luego variables

Tip: Reorder operands of *

Vuelo.java

/aero/src/data

line 26

Idiomatic

Corrección aceptada, siempre es preferible operar primero numeros y luego variables

f. After performing the entire analysis, do you think programmers should adopt the Spartan Programming practices and use tools like the Spartan plugin?Explain your answer.

Si los programadores deberían adoptar este plugin, debido a que las buenas practicas se deben mantener siempre en cualquier equipo de trabajo, personalmente estoy acostumbrado a usar Ruby Rubocop, plugin especializado en mantener buenas practicas en Ruby on Rails, realmente como programadores miles de veces pensamos solamente en la parte funcional del código y no en el estilo de este, cosa que es totalmente incorrecta, debido a que en un grupo de desarrolladores la mayor perdida de tiempo se da al intentar entender el código de otros o el propio, es necesario inculcar la enseñanza de estas buenas practicas y procurar estudiar cada día libros como CleanCode.