Jose Armando Cetzal Cruz

Grupo 604

202860287-4

Informática

Jenny parrao duran

Anotaciones legibles al programador en el código fuente de un Programa informático.[2] Estas

anotaciones son potencialmente significativas para los programadores, pero usualmente
ignorados por los compiladores e intérpretes.[3][4] Los comentarios son añadidos usualmente con
el propósito de hacer el código fuente más fácil de entender con vistas a su mantenimiento o
reutilización. La sintaxis y reglas para los comentarios varía

<resource id=”ProcessDiagram000”>

<![CDATA[

HostApp (Main_process)

Script.wsf (app_cmd) → ClientApp (async_run, batch_process)

Mru.ini (mru_history)

]]>

</resource>

Depuración

Editar

Una práctica común entre programadores es comentar un fragmento de código, es decir, agregar
delimitadores de modo que un bloque de código se convierta en un comentario, y por tanto no se
ejecutará en el programa final. Esto podría hacerse para excluir algunas piezas del código del
programa o, de manera más común, para encontrar la causa de un error. Comentando
sistemáticamente y ejecutando partes del programa, la causa del error puede ser determinada,
permitiendo su corrección. A continuación un ejemplo de cómo comentar código con el propósito
de excluirlo:

If (opt.equals (“e”))

Opt_enabled = true;

/*

If (opt.equals (“d”))

Opt_debug = true;

// */

//*

If (opt.equals (“v”))

Opt_verbose = true;

// */

Estilos de los comentarios se agregan apenas comienzan el proyecto. Normalmente los

programadores prefieren estilos que son consistentes, no obstructivos, fáciles de modificar, y
difíciles de romper.

Los siguientes fragmentos de código en C son solo un ejemplo de como los comentarios pueden
variar de estilo, mientras todos contienen la misma información básica:

/*

Este es el cuerpo del comentario.

Variante 1

*/

/***********************************\

**

* Este es el cuerpo del comentario. *

* Variante 2. *
**
\************************************/

Comentario

Java

Editar

//comentario de línea

Que la línea son instrumentos que utilizamos en una variante de series

/*comentario

De bloque*/

/**

Comentario que será usado por javadoc

*/

Delphi

Editar

//comentario en línea

{ comentario

En bloque }

(* comentario

En bloque *)

En delphi se pueden anidar comentarios de bloque siempre que no usen el mismo delimitador,
e.g.

(*

Comentario en bloque

Que contiene otros

Comentarios en bloque

}
// o de fin de línea
Y que es perfectamente

Válido

*)

Lua

Editar

—Un comentario de línea

--[[

Un comentario de bloque

]]—

Ruby

Editar

#comentario

=begin

Comentario de bloque

=end

Python

Editar

#comentario#comentario

“””

Comentario

En bloque

“””

Perl

Editar

#comentario

Javascript
Editar

En archivo.js pueden darse las siguientes formas:

//comentario en línea

/* comentario

En bloque */

Código HTML

Editar

En las páginas webs .html se introduce el comentario entre

<!-- →

<!—

Esto es un comentario en código HTML

// →

SQL

Editar

//esto es un comentario—este también

/* y este

En bloque */

Visual Basic

Editar

‘comentario

‘’’comentario XML

Pascal

Comentarios en las pruebas para desactivar algunas líneas de código; sin embargo, para esto es
mejor utilizar directivas de preprocesador #if/#endif porque se puede incluir entre ellas código
que contiene comentarios, pero no se pueden anidar comentarios.
Los comentarios de C++ se escriben de una de las maneras siguientes:
Los caracteres /* (barra diagonal, asterisco), seguidos de cualquier secuencia de caracteres
(incluidas nuevas líneas), seguidos de los caracteres */. Esta sintaxis es la misma que para ANSI
C.

Los caracteres // (dos barras diagonales), seguidos de cualquier secuencia de caracteres. Una
nueva línea que no va precedida inmediatamente de una barra diagonal inversa finaliza esta forma
de comentario. Por tanto, normalmente se denomina “comentario de una sola línea”.

Los caracteres de comentario (/*, */ y //) no tienen ningún significado especial dentro de una
constante de caracteres, un literal de cadena o un com

Estar sentado en el puesto largas horas

Estar al día con la tecnología

ILa comunicación

El problema

Como nuevo programador en la empresa, seguramente no conozcas a nadie en tu nuevo

lugar de trabajo. Puede que conozcas al compañero que te habló de la vacante, pero no a los
miembros de tu equipo ni al jefe de proyecto con el que vas a trabajar. Y si no los conoces,
puede que no quieras hablar con ellos sobre algunos temas, como por ejemplo, temas
relacionados con el código o el orden jerárquico de la empresa.

La mala comunicación es un problema al que la mayoría de los programadores principiantes

se enfrentan en algún momento. Y lo peor es que puede causar conflictos en el lugar de
trabajo. Si no tienes claro cuáles son los problemas relacionados con un proyecto, es posible
que no sepas cómo solucionarlos o cómo conseguir ayuda si no consigues hablar con tus
compañeros de equipo.
Por ejemplo, puedes enfrentarte a problemas de integración de código si no te coordinas con
los miembros de tu equipo. Esto es algo que pasa en muchas empresas de desarrollo. Todos
en tu equipo siguen una estrategia de programación con la que tú no estás familiarizado.
Como resultado, te encontrarás con muchos problemas de integración e incluso te verás en
situaciones de enfrentamiento con los miembros de tu equipo.

La culpa de las malas comunicaciones recae sobre ti, porque está en tu poder controlarlo. Si
no intentas establecer una buena comunicación con tu equipo, en última instancia eres el
responsable del problema.

Qué hacer

En el ámbito del desarrollo de software, las habilidades de comunicación son tan

importantes como las habilidades técnicas. A continuación te explicamos cómo puedes
mejorar estas habilidades:

• Proactividad: comunicarse sólo cuando se necesita algo o cuando se hace una

pregunta no es suficiente en el lugar de trabajo. Interactúa con tus colegas y
no tengas miedo de hacerles preguntas, especialmente sobre cualquier
problema que estés enfrentando en la oficina. Puedes acostumbrarte más
rápido a la cultura de la empresa si te abres a las demás personas. Y si eres
una persona tímida tendrás que esforzarte más que los demás.
• Sé constante: a veces, es posible que no seas lo suficientemente claro o
coherente en lo que dices y esto causa problemas. Acepta que habrá
momentos como estos, aprende de ellos y hazlo mejor la próxima vez.
Practica hasta que seas capaz de expresarte con mayor fluidez.
4 – Depuración de errores

El problema

Imagínate este escenario. Después de trabajar durante días para perfeccionar un programa,
te vas a casa satisfecho de que funcionará como debería. Cuando llegas al día siguiente, tu
compañero de control de calidad te da una larga lista de errores que tienes que solucionar. El
botón "Cancelar" en el formulario web no se puede pulsar, los mensajes de error no son
correctos y el software tiene otros fallos que provocan problemas en la experiencia del
usuario.

Depurar todo esto parece abrumador, ¿no? Y lo es aún más para los nuevos programadores.
Algunos errores son fáciles de depurar, pero muchos no lo son, lo que puede llevar a una
gran pérdida de tiempo de desarrollo y a una frustración desmedida para un nuevo
programador.

Pero la buena noticia es que los bugs son muy comunes en programación. Incluso el mejor
código puede tenerlos y los programadores con más experiencia provocan bugs también. Y
se pueden arreglar.

Qué hacer

En el fútbol profesional, se dice que la mejor defensa es un buen ataque. Si lo aplicamos a la

programación, la mejor defensa contra los errores es una buena estrategia de depuración.
Como nuevo programador, la incorporación de estrategias de depuración también te puede
ayudar. Estos son algunos de los pasos a seguir:

• Intenta reproducir el error: pasar incontables horas tratando de arreglar un

problema que no entiendes puede ser agotador. Para arreglar tus bugs, debes
entender por qué ocurrieron. ¿Cómo? Empieza por intentar reproducirlos. Si
lo consigues, tendrás al menos unas buenas pistas de cómo arreglarlos.
• Consigue ayuda: este consejo puede resultar obvio, pero cuando los
proyectos tienen una fecha límite crítica, la mayoría de los programadores
nuevos tienden a entrar en pánico primero y a pensar después. Si no puedes
reproducir un error, busca ayuda. El tester que encontró el error puede
ayudarte a reproducirlo.

5 - La estimación de plazos

El problema

Quizás no sabías cómo hacer una buena estimación. O tal vez diste un plazo, pero no lo
cumpliste. Al final, no pudiste seguir el ritmo del resto del equipo y tu proyecto se pasó de
la fecha prevista.
Como profesional que trabaja en una industria que está sometida a un control de plazos, es
posible que se te pida que indiques el tiempo que tardarías en completar una tarea, como la
depuración de código o la realización de ciertas funciones en un sprint.

La estimación de plazos es un factor muy importante en el desarrollo de software. Pueden

ser la base de las ofertas de presupuestos y calendarios de proyectos. Las demoras en los
plazos causan problemas y pueden poner en peligro la confianza.

Como nuevo programador, es posible que caigas en la tentación de invertir más tiempo del
necesario en una tarea, con la creencia de que hacerlo podría impresionar a tu jefe y ser
mejor para el proyecto. Pero hacer esto se puede volver en tu contra. Puede retrasarte
mucho y retrasar a tu equipo, lo que te hace quedar mal.

Qué hacer

Para resolver este problema:

 • Divide las tareas: la mejor manera de hacer que las tareas sean más
manejables es dividirlas en una serie de tareas más pequeñas. ¿Tu compañero
que revisa tu código acaba de identificar una decena de errores en tu trabajo?
Contempla cada corrección como una minitarea y calcula el tiempo que te
puede llevar completar cada una de ellas. Descomponer la carga de trabajo de
esta manera evitará que las actividades se vuelvan abrumadoras.
• Calcula bien tu tiempo: concédele a cada tarea un plazo de tiempo para
completarla, pero también date a ti mismo un colchón. Por ejemplo, si crees
que una tarea te va a llevar aproximadamente 1 hora, establece un espacio
para imprevistos de 30 minutos más. Nunca se sabe qué tipo de alteraciones
pueden ocurrir.

Con el tiempo irás afinando cada vez más y te resultará menos complicado acertar.
6 - No entender al usuario final

El problema

En el desarrollo de software, el papel central que tiene el usuario final del software no es
una opción, sino una prioridad. Como es lógico, para que cualquier software se enfoque en
el usuario, hay que saber antes qué es lo que quieren éstos.

Tus usuarios pueden tener opiniones acerca de cómo debería funcionar una aplicación y
muchas veces, estas opiniones pueden diferir de las de tu equipo de desarrollo. Otras veces
un usuario te dice lo que quiere que haga la aplicación, pero en realidad no es la solución
correcta a su problema y lo que debería transmitir es el objetivo, no la forma de llegar a él.

Para los nuevos programadores suele ser difícil entender lo que quieren los usuarios, ya que
rara vez pueden interactuar con ellos directamente.

Ciertamente, las técnicas de gestión de proyectos como Agile/Scrum hacen que sea más
fácil para los equipos de desarrollo actualizar el software a medida que las demandas de los
usuarios cambian a lo largo del ciclo de desarrollo, pero para los programadores noveles
(que aún están en fase de aprendizaje) puede ser todo un reto compatibilizar conocer bien
las necesidades del usuario con la falta de comunicación con los mismos.

Es lógico que la empresa de desarrollo no permita a los nuevos programadores tener acceso
directo con los clientes finales al principio y hay que saber cómo saltar este obstáculo para
empezar bien en la empresa.
Qué hacer

En última instancia, las personas que utilizarán el producto serán los usuarios finales.

No obstante, los usuarios pueden saber qué es lo que quieren que el sistema haga, pero no
las funcionalidades. Tu trabajo consiste en averiguarlo. Como dijo Henry Ford una vez: "Si
les hubiera preguntado a mis clientes qué querían, habrían dicho un caballo más rápido".
 • Habla con las personas que sí tienen acceso directo a los usuarios: no, no
con los responsables de proyecto. Si realmente quieres saber lo que quieren
los usuarios, consulta con los expertos en experiencia de usuario o con los
diseñadores de interfaz. A ellos se les exige que piensen cada producto con
un enfoque de diseño centrado en el ser humano y a ellos sí se les da acceso
directo a las personas que realmente van a utilizar el producto final. Su
conocimiento servirá de guía para tus desarrollos.
• Pon a prueba la aplicación: si realmente quieres saber lo que piensan tus
usuarios sobre tu producto, ponlo a prueba. Es habitual que las empresas
lancen versiones "beta" de sus productos para ver cómo reaccionan los
usuarios antes de lanzarlos de manera definitiva. Esto les ayuda a corregir
cualquier error y cualquier problema que los usuarios puedan apuntar. Pues tú
lo mismo, aunque si tu empresa tiene cierto tamaño seguramente ya
dispondrá de testers que la pongan a prueba inmediatamente y te pasen
información sobre los resultados.

7 - Riesgos para la seguridad de los datos

El problema

Los datos son un bien muy valioso. Y algunas personas están dispuestas a pagar mucho por
ello, incluyendo a los competidores de tu cliente que puede que quieran curiosear en un
proyecto de alta confidencialidad (como un software de marketing o empresarial) en el que
podrías estar trabajando.
Esto opinan nuestros alumnos

¿Vale la pena invertir en aprender con campusMVP?

Los clientes confían en que tú protegerás su información frente a estas amenazas. Eso es
mucha presión. Desafortunadamente, los novatos con frecuencia pasan por alto las lagunas
de seguridad en su código y no se dan cuenta de las repercusiones hasta después de que
ocurre
una vulneración de la seguridad. La seguridad no es solo cosa de los de sistemas: los
programadores tienen un papel incluso mayor y la mayor parte de los problemas de
seguridad que surgen en las aplicaciones tienen más que ver con el código que con las
comunicaciones.

Como programador novato es posible que pases por alto muchos detalles relacionados con
la seguridad, especialmente si te concentras más en entregar un código libre de errores que
en comprobar si es seguro. Los hackers buscan constantemente estas vulnerabilidades y las
formas de penetrar en el código de las aplicaciones.
Qué hacer

No puedes impedir que alguien intente hackear tu código, pero puedes hacer que sea más
difícil hacerlo si lo proteges contra las vulnerabilidades más comunes.

Esto es una disciplina en sí misma que se tarda en dominar, pero solo como ejemplos te daré
dos consejos:

• Vigila muy de cerca cualquier dato que introduzcan los usuarios: esta es
una máxima de cualquier programador: nunca, jamás de los jamases, te fíes
de nada que llegue desde el lado cliente. Aunque hagas validación en la
interfaz de usuario, una vez que los datos lleguen al servidor debes validarlos
de nuevo. Y cualquier cadena de texto que llegue que luego deba mostrarse
en algún momento en la interfaz de usuario, debes "sanitizarla" antes de
mostrarla.
• Usa consultas parametrizadas para evitar inyecciones SQL: un intruso
puede utilizar inyecciones de SQL para robar datos como por ejemplo los
datos de acceso de un usuario. Para evitar este tipo de ataques, se pueden
utilizar consultas parametrizadas en el lenguaje de programación que se
utilice o algún ORM que tenga esto controlado.

8 - No planificar bien la programación de tu código

El problema

Las primeras impresiones importan, sin duda. Pero también lo es una planificación
concienzuda.

En un nuevo puesto de trabajo quieres probarte a ti mismo, lo cual es totalmente

comprensible. Pero para lograr una buena primera impresión, puede que caigas en la
tentación de apurarte al escribir tu código y además dejar ya determinada la estrategia que
deberá tomar el código más adelante.
Sin embargo, este método de trabajo se puede volver contra ti. Tu código puede tener
sentido en tu cabeza, pero luego toma una orientación totalmente contraria a la que se
supone que debería haber tomado.

Qué hacer

El tiempo invertido en un código sin planificar es tiempo perdido. Para evitar una situación
así, pon tus ideas sobre el papel en lugar de tenerlas en la cabeza. A continuación se
presentan una serie de consejos que puedes probar:
 • Empieza con una idea: todo programa de software comienza con una idea.
Por ejemplo, tu idea para una aplicación puede consistir en una herramienta
que permita a los usuarios recordar citas. Con este paso puedes concentrarte
en lo que estás a punto de programar.
• Usa un mapa mental para resolver los problemas de los usuarios: una vez
que hayas desarrollado y trabajado tu idea, el siguiente paso es planificarla.
Empieza con los problemas que tu producto tratará de solucionar. Escribe tu
idea en papel y crea subtemas para ella. Por ejemplo, si tu idea es una
aplicación de recordatorio de citas para profesionales de la venta, un subtema
podría ser la razón por la cual un usuario podría necesitarla (por ejemplo,
hacen demasiadas citas para hacer un seguimiento de ellas).
• Busca posibles soluciones: una vez que hayas mapeado los problemas que tu
producto tratará de resolver, piensa en posibles soluciones para esos
problemas. Por ejemplo, si un usuario necesita que tu software realice un
seguimiento de múltiples citas, las posibles funcionalidades podrían ser un
sistema de notificación o una alerta por correo electrónico o por SMS que le
recuerde cualquier cita que tenga durante el día.
9 - El trabajo con el código de otra persona

El problema

Los nuevos empleados muchas veces tienen que trabajar en proyectos realizados por otra
persona en algún momento. De hecho es habitual porque te ayuda a ponerte al día con la
base de código y a coger experiencia a partir del código de los demás (¡y aprender sobre lo
que se debe hacer y lo que no!). Es una situación que puede causar muchos problemas.

El programador que originalmente programó el código puede que ya no trabaje allí y que no
haya informado a nadie sobre todo su trabajo antes de marcharse y que no haya
documentado convenientemente el código ni siquiera con buenos comentarios. O bien, si
todavía están en tu lugar de trabajo, es posible que estén demasiado ocupado para responder
cualquier consulta que tengas.

En el peor de los casos, podría haber problemas mayores propios del mal ambiente de la
oficina. Por ejemplo, tal vez tus compañeros de trabajo no se llevaban bien con el
programador anterior y podrían mostrarse reacios a ayudarte a descifrar su código. Esto es
una realidad.

Qué hacer

Trabajar sobre código de otro programador puede ser un inconveniente, pero es un

obstáculo salvable. La mejor manera de abordarlo es tomárselo como un reto. Puedes
empezar por aquí:
• Asimila cuanto antes que ahora es tu código: corregir esta situación significa
 cambiar tu actitud al respecto. Si alguien te dejó el código a ti, ya no es su
código. Ahora es tuyo. Asumir la responsabilidad desde el principio te
quitará el miedo a la tarea.
• Pasa más tiempo leyendo código: pasa algún tiempo averiguando cómo
trabajaba el otro desarrollador, tanto su enfoque como su estilo. Te resultará
más fácil adaptarte al código una vez hayas hecho eso.

10 - La necesidad de producir constantemente (y el estrés que

conlleva) El problema

Debido a que la programación es un sector tan atractivo para entrar a trabajar en él, también
se convierte en un espacio extremadamente competitivo.

Si no es capaz de producir desarrollos de calidad, siempre existirá la inminente sensación de

que alguien más puede asumir tu puesto y realizar tu trabajo mejor de lo que tú puedes
hacerlo.