Superar la resolución lenta de problemas debido a un mayor conocimiento de lo que podría salir mal [cerrado]

443

Esto me ha estado preocupando por un tiempo, y realmente agradecería la opinión de otros profesionales.

Información breve: comencé a programar cuando mis padres me compraron mi primera computadora en 1988 (a los 14 años, ahora tengo 39 años). Seguí un par de otras carreras profesionales antes de convertirme finalmente en un programador profesional en 1997. Posiblemente tarde, tal vez, pero así fue. Todavía estoy contento con mi elección, me encanta la programación y me considero bueno en lo que hago.

Últimamente, he notado que cuanto más experiencia adquiero, más tiempo me lleva completar proyectos o ciertas tareas en un proyecto. Todavía no me voy senil. Es solo que he visto tantas maneras diferentes en que las cosas pueden salir mal. Y los posibles escollos y errores que yo conozco y recuerdo son cada vez más y más.

Ejemplo trivial: solía ser simplemente "bueno, escribe un archivo aquí". Ahora me preocupo por los permisos, bloqueos, concurrencia, operaciones atómicas, direccionamiento indirecto / marcos, diferentes sistemas de archivos, número de archivos en un directorio, nombres de archivos temporales predecibles, la calidad de la aleatoriedad en mi PRNG, falta de energía en medio de operación, una API comprensible para lo que estoy haciendo, documentación adecuada, etc., etc., etc.

En resumen, los problemas hace tiempo que pasaron de "cómo hago esto" a "cuál es la forma mejor / más segura de hacerlo".

El resultado final es que me lleva más tiempo terminar un proyecto que un novato. Mi versión puede ser sólida como una roca, y tan impenetrable como sé cómo hacerlo, pero toma más tiempo.

El ejemplo de "crear archivo" anterior fue solo eso, un ejemplo. Las tareas reales son obviamente más complejas, pero menos adecuadas para una pregunta genérica como esta. Espero que entiendas a dónde voy con esto. No tengo ningún problema en crear algoritmos eficientes, amo las matemáticas, disfruto de materias complejas, no tengo dificultades con la concentración. Creo que tengo un problema con la experiencia y, en consecuencia, con el temor a los errores (intrínsecos o extrínsecos).

Paso casi dos horas al día leyendo sobre nuevos desarrollos, nuevas técnicas, idiomas, plataformas, vulnerabilidades de seguridad, etc. El enigma es que cuanto más conocimiento adquiero, más lento soy al completar proyectos.

¿Cómo lidias con esto?

    
pregunta Zilk 09.10.2013 - 16:03
fuente

21 respuesta

267

No eres más lento en completar proyectos. Anteriormente, pensabas que tus proyectos para principiantes se hacían cuando realmente no lo eran. Deberías vender esta calidad a los clientes.

"Esta compañía podría hacerlo más rápido y más barato, pero ¿está realmente hecho? ¿O va a estar cazando insectos durante años?"

Más allá de eso, necesitas saber y aceptar el viejo idioma: "Perfecto es el enemigo del bien".

    
respondido por el Telastyn 28.03.2014 - 23:16
fuente
177

Parece que es hora de que te unas al lado oscuro: la administración.

No estoy sugiriendo que abandone la programación y se convierta en gerente. Pero parece que toda la experiencia que ha citado hasta ahora ha sido de naturaleza técnica. Con la simple operación de escribir un archivo, puede pensar en 10 aspectos diferentes que un desarrollador menos maduro nunca consideraría. No necesariamente es algo malo, pero ...

El lado oscuro tiene que ver con el valor presente. Se trata de hacer una inversión mínima para obtener el máximo beneficio (análisis de costo-beneficio). En los negocios, todo se reduce a cuánto me costará esto, probabilidad de éxito, probabilidad de fracaso, probabilidad de fracaso espectacular y ganancia potencial. Haz las matematicas; actuar en consecuencia.

Esto funciona igual de bien cuando eres un desarrollador: crea un archivo temporal, ignora los permisos y las colisiones de nombres - 5 min. Ganancia neta, el resto del equipo puede comenzar a trabajar en cualquier código que dependa de la presencia de ese archivo. ¿Es una solución perfecta? Absolutamente no. ¿Le conseguirá el 99%, el 95%, tal vez el 90%? Sí, probablemente lo hará.

Otra pregunta que hacer: ¿Cómo te sientes acerca de la deuda técnica? Algunas personas piensan que hay que eliminarlo. Creo que esas personas están equivocadas. Al igual que en los negocios, la deuda técnica le permite pedir prestado "efectivo" o "tiempo" para entregar algo antes. ¿Qué es mejor: una solución perfecta en 2 años o un hack completo que un cliente puede usar y comprar en 4 meses? Cada situación es diferente, pero en algunas situaciones, si espera 2 años, su cliente ya se registrará con su competencia.

La clave es administrar la deuda técnica de la misma manera que una empresa bien administrada administra la deuda financiera. Si no acepta lo suficiente, no está obteniendo un rendimiento óptimo de la inversión. Si tomas demasiado, el interés te matará.

Por lo tanto, mi consejo: comience a evaluar su trabajo en función de si está maximizando su valor en lugar de maximizar su minuciosidad. Y si practica esto, desarrollará la misma intuición que ya desarrolló en su área técnica.

Como nota al margen, recientemente comencé a hacer la técnica pomodoro y me ha ayudado mucho. En lugar de ir en una tangente de tangente, enfóquese en pequeños intervalos de tiempo y luego asigne pomodoros para trabajos / investigaciones futuras. Es sorprendente cuántas veces hice una nota para investigar un tema, pero una hora después, cuando llegó el momento, pensé: "hay al menos otras 3 cosas que podría hacer con mi tiempo de hoy, que son todas más valiosas". p>     

respondido por el DXM 28.03.2014 - 22:10
fuente
93

Hace muchos años tuve el mismo problema (probablemente), duró algunos años y lo superé. Por lo tanto, tal vez sea de su interés saber cómo lo logré, incluso si no estoy seguro de que mi camino también se aplique a usted.

También deberías echar un vistazo aquí: Las siete etapas de la experiencia en Ingeniería de Software muestra que la productividad es, en gran parte, un efecto secundario del nivel de habilidad. Es posible que todavía estés en algún punto entre la etapa 3 y la etapa 4 sobre la tecnología que estás utilizando actualmente (el dominio de las habilidades depende de la tecnología, puedes dominar algunas tecnologías mientras aprendes otras).

Ahora comienzo con el testimonio biográfico.

Un poco de contexto. Tengo 47 años. Empecé a programar a los 12 en los 80's. Mientras estaba en la escuela secundaria también trabajé como programador de juegos profesional a tiempo parcial. Básicamente no me consiguió tanto dinero, solo lo suficiente para comprar hardware, pero lo disfruté y aprendí mucho. A los 18 años comencé un aprendizaje formal de informática.

Como resultado, cuando cumplí los 20 años, al comenzar cualquier tarea de programación, conocía muchas formas de resolver los problemas dados y era muy consciente de los muchos parámetros y dificultades en las manos, y los inconvenientes y límites de cualquier método.

En algunos puntos (digamos, unos 26 años) me resultó muy difícil escribir un programa. Se abrieron tantas posibilidades que ya no pude elegir entre ellas. Durante algunos años (que sea 6) incluso dejé de programar y me convertí en un redactor técnico de noticias.

Sin embargo, nunca dejé totalmente de intentar programar. Y en algún momento volvió. La clave para mí fue la programación extrema, más específicamente el principio de simplicidad: "Escriba lo más sencillo que podría funcionar".

Básicamente, me obligué a no preocuparme por la eficiencia del código (ese fue mi principal obstáculo, evitar los diseños ineficientes), sino simplemente ir por el camino más fácil. También me obligué a preocuparme menos por los errores, y retrasar el manejo de errores para un momento posterior, después de escribir las pruebas que provocan el error (en realidad es TDD).

Eso es algo que aprendí cuando estaba escribiendo. Cuando no sé qué escribir, o sabía que lo que estaba escribiendo era malo . Sólo sigue En realidad escribe las cosas malas. Eventualmente lo corregiré más tarde. O si realmente es tan malo, bórrelo y vuelva a escribirlo, pero es más rápido escribir cosas dos veces que escribir algo perfecto la primera vez.

Realmente es muy probable que un código que creas que es bueno al principio de la escritura necesite tanta mejora como uno realmente malo.

Si sigues la ruta de la simplicidad, también obtendrás una bonificación adicional. Usted acepta fácilmente eliminar / cambiar el diseño / codificación inicial. Obtienes una mente más flexible.

También me acostumbré a poner un comentario temporal en el código, explicando lo que no estaba haciendo ahora y la intención de hacerlo más adelante cuando el código funcionaría en el caso de uso normal.

También asistí a un Dojo de XP y katas de código practicados con otros programadores para internalizar las prácticas de XP. Eso ayudo. Hizo instintivos los métodos formales anteriores. La programación en pares también ayudó. Trabajar con programadores jóvenes le da algo de impulso, pero con la experiencia también puede ver lo que no hacen. Por ejemplo, en mi caso, a menudo los veo participar en diseños excesivamente complicados y conozco la pesadilla del diseño que puede llevar a. Se fue de esa manera. Hizo que. Tuve problemas.

El punto principal para mí es mantener el flujo. Ser rápido es realmente tener éxito en mantener el flujo.

Ahora he vuelto como programador profesional y creo que soy mejor y más rápido con una comprensión más profunda de lo que estoy haciendo. Si practico TDD, es posible que todavía sea un poco más lento que cuando era un toro joven (y no probé nada), pero tampoco tengo miedo de refactorizar y, ciertamente, dedico mucho menos tiempo a la depuración (casi sin tiempo, haz que sea menos del 10% del tiempo. ).

Resumidamente: superé mi bloque de código usando métodos ágiles (XP), yendo por simplicidad y refactorización, y practicando para hacer eso instintivo. Funciono para mi No estoy seguro de que pueda generalizarse a nadie más.

En cuanto al nivel de adquisición de habilidades, aprendí a aceptar que cada vez que cambio de tecnología (aprender un nuevo idioma, un nuevo marco, etc.) pasaré por una etapa en la que disminuiré la velocidad. Esto es normal y eventualmente lo superará. También puedo compensar eso con una buena metodología y habilidades de programación de propósito general y no será tanto un problema.

    
respondido por el kriss 13.11.2014 - 17:34
fuente
41

Una parte importante de la programación es administrar y controlar la complejidad y, para mí, personalmente, es uno de los principales problemas. Si se ignora, la frecuencia de las deficiencias aumenta o, como en su caso, la ETA del software finalizado aumenta dramáticamente.

Lacomplejidaddelsoftwaresepuedecontrolaryadministrardesdediferentesnivelesyformas,perounabuenareglageneralparaobtenerciertaperspectivaeslasiguiente:"La principal prioridad de cualquier proyecto de software es la satisfacción del cliente, que es una función de sus expectativas".

En otras palabras, la complejidad del software depende en gran medida de su habilidad para controlar las expectativas de su cliente.

Cuando uno adopta esa vista, entonces dos puntos importantes se vuelven obvios:

  1. las expectativas del cliente deben ser explícitas (en cualquier forma);
  2. las expectativas de los clientes siempre pueden modificarse y eso se hace a través del arte de la negociación.

Su ejemplo es muy bueno, "simplemente escríbalo" contra "miles de otras consideraciones". Piénselo: si alguien escribiera requisitos exhaustivos para ambas variantes, ¿puede haber una equivalencia en las características descritas o no?

Construir un F16 es diferente de construir un Cessna aunque ambos pueden volar.

    
respondido por el Saul 08.10.2013 - 14:57
fuente
24

La respuesta simple es: acéptalo.

En todos los sistemas se deben hacer concesiones entre confiabilidad, robustez, seguridad, velocidad, costo de hardware, costo de desarrollo, tiempo de comercialización, lo que sea. No siempre estará de acuerdo con cómo el cliente hace esas concesiones, pero no es usted el que toma esas decisiones. Todo lo que puedes hacer es dar una opinión considerada. El desarrollo de software cubre toda la gama, desde "mi página web personal" hasta "ejecutar el reactor nuclear", y el código debe escribirse en consecuencia. Si un fallo significa "volver a cargar mi página web personal", ¿a quién le importa si eso sucede? Pero si un fallo significa "Chernobyl", entonces su preferencia por el código sólido es, para mi gusto, algo informal.

Hay algunos clientes que aceptan felizmente el código de nivel "Prueba de concepto" y lo ejecutan en sus sistemas en vivo, y con frecuencia tienen administradores de sistemas que están bien acostumbrados a eso. Por lo general, los sistemas IME no están disponibles durante aproximadamente una hora en la mitad de la noche, mientras que ocurren varios reinicios programados. Pero han tomado la decisión empresarial de que así es como quieren rodar. Idealmente porque su campo es tan rápido que el código de alta calidad nunca estaría listo, pero a menudo porque no pueden ver el valor (si un sistema "simplemente funciona" nunca lo notan, por lo tanto, ese sistema no representa valor para dinero). Si te molesta demasiado, intenta evitar a esos clientes.

Mantenerse actualizado es el tiempo que todos tenemos que gastar, o al menos deberíamos gastar. A veces eso te hará trabajar, otras veces solo mantendrá tu mente en buena forma. De cualquier manera, trata de disfrutarlo.

    
respondido por el Móż 08.10.2013 - 03:25
fuente
16

Parece que sus habilidades serían muy útiles para el desarrollo de sistemas de misión crítica de muy alta calidad, como aplicaciones relacionadas con finanzas / comercio, radiodifusión, aeroespacio, defensa ...

Los errores en este tipo de aplicaciones son muy costosos y emplean a personas que piensan como tú, ya que puedes cubrir todos los casos.

    
respondido por el user1037729 12.10.2013 - 20:40
fuente
15

La verdad es que los sistemas modernos son cada vez más complejos. La computadora ahora es similar al juego "Jenga" donde tienes todas estas piezas confiando en muchas de las otras. Saque la pieza equivocada y tiene un error, saque una pieza correcta / necesaria y aún puede producir un error. Cuanto más complejo sea el sistema, más tiempo pasará pensando en maneras de hacer que su código sea más robusto y, con suerte, también más seguro. La velocidad sería buena, pero creo que la velocidad ocupa mucho lugar en estos últimos días cuando escuchas en las noticias que la compañía "XYZ" fue atacada y que se robaron 6 millones de números de tarjetas de crédito de clientes.

Es posible que sus clientes no quieran escuchar que su programa debe ser seguro, robusto, etc. Pero podría decirles que su automóvil no necesita cinturones de seguridad y bolsas de aire, ni su casa necesita cerraduras y puertas ... porque quién quiere escuchar todo eso?

Si estás pensando demasiado, estás haciendo las cosas de la manera correcta, excepto que debes elegir una estrategia que parezca "concreta" y simplemente seguirla.

    
respondido por el David Betournay 08.10.2013 - 03:20
fuente
9

Parece que eres consciente de tu tendencia a pensar en todo lo que puede salir mal.

Los desarrolladores cautelosos con experiencia a menudo aprenden a seguir el mantra YAGNI , no lo vas a necesitar, cuando intenten volver a un flujo de trabajo magro, ágil y productivo después de sentirse demasiado ahogados en las malas hierbas del modo de falla. analisis-ido-enoquecido.

Sin embargo, si está escribiendo algo en un dominio donde el nivel de atención no es inferior al que exige el Profesionalismo, debe darse cuenta de que su "velocidad", su "productividad", en términos netos, se puede medir por cómo mucho bien (o daño) que le está haciendo a su empresa, a sus clientes y al paquete de software, o la familia de productos que está creando o manteniendo.

Recuerde:

  • Incluya el costo total de mantenimiento, el costo total de propiedad y el costo total de implementación y mantenimiento de soluciones cuando considere cambios en su enfoque. Ir más rápido y cometer más errores puede o no mejorar las cosas.

  • Si trabajas en una buena compañía, probablemente puedas discutir esto en tu propio equipo, y con tu propio supervisor, sin que sea un Movimiento de Limitación de Carrera. Si no puede, ahora es un buen momento para averiguarlo y encontrar un nuevo trabajo.

respondido por el Warren P 08.10.2013 - 19:56
fuente
7

Lo único que puedo ver es: "Te estás volviendo más y más valioso".

A medida que obtiene más experiencia, aprende sobre cosas que debe evitar y esto es lo que lo hace mejor que otros.

Una cosa te habrías dado cuenta de que tu código ahora sería más seguro y más fácil de mantener.

  • Lo único que debe hacer es explicar a su cliente por qué tomó tiempo y cómo sería útil para ellos.
  • Necesitas mostrarles la profundidad de tu conocimiento.
  • Debe decirles por qué lo hizo, qué hizo y cómo les importaría a ellos y a su negocio.

Mi sugerencia sería concentrarse en esta parte.

    
respondido por el Falaque 08.10.2013 - 09:49
fuente
7

en caso de duda, omita citar a Knuth ...

"La optimización prematura es la raíz de todo mal".

Esto es lo que sugeriría, ya que parece que tienes un problema que tengo de vez en cuando ...

Lo que realmente funciona para mí ...

  1. Escriba las pruebas unitarias, como si se hubiera hecho todo el código.
  2. documente la interfaz.
  3. implementar la interfaz.

lo que realmente has hecho:

  1. trabajar a través de los requisitos de capas del modelo
  2. realmente configura la división del trabajo, qué objetos son responsables de qué
  3. comience a trabajar en un entorno cuando realmente puede avanzar a través del código de trabajo, lo que hace que las cosas sean mucho más rápidas y más precisas ...

también confíe en las afirmaciones en el desarrollo temprano ... luego descubra qué soluciones deben implementarse y no escribirá un código que no sea accesible o difícil de probar.

    
respondido por el Grady Player 08.10.2013 - 17:36
fuente
6

Creo que deberías cumplir con tus estándares de codificación, pero asegúrate de ser directo con tus clientes. Muchos clientes no saben lo que cuesta / cuesta construir un buen software. Es parte del trabajo del desarrollador profesional educarlos.

Ya sea que sea ágil o en cascada, obtendrá algún tipo de acuerdo del cliente sobre lo que esperan que haga la aplicación. Demasiados desarrolladores (está bien, tal vez más vendedores) son culpables de sandbagging . "No dijeron que querían un sitio web altamente seguro". En la mayoría de los casos, es porque no se les preguntó. "¿Te importa si tu sitio de comercio electrónico es hackeado?" Por supuesto que les importa y ¿por qué lo construirías para permitir que alguien penetre la seguridad? Tienes que educarlos.

Solo asegúrese de que está haciendo solo lo que el cliente le está pagando por hacer. Parte de su servicio es su experiencia. Los clientes esperan que conozca las trampas sin que tengan que preguntar. Depende de ellos incluir el requisito. Es posible que desee transmitir a los clientes que desean algo barato.

    
respondido por el JeffO 08.10.2013 - 16:57
fuente
6

Piense en las consecuencias prácticas de un error en comparación con todos los demás problemas que deben resolverse.

Considere las siguientes consecuencias de crear una pieza de código mal escrita:

  1. Toda la base de datos se vuelca cada dos meses. 48 horas de inactividad mientras se restauran las copias de seguridad.
  2. Los registros de clientes se entrecruzan. Los pedidos de $ 200 se envían a los clientes equivocados por mes.
  3. Una orden se bloquea en un estado incorrecto una vez a la semana. Encargar los buques, pero el almacén debe llamar al servicio de asistencia cada vez que ocurra.
  4. Una vez que hayan transcurrido aproximadamente dos semanas, la aplicación se bloquea y el usuario debe volver a ingresar los datos que valen 2 minutos.
  5. Una vez al mes, la aplicación se bloquea en el inicio. El usuario debe finalizar el proceso y volver a empezar.

El primero es obviamente inaceptable. # 2 - # 5 puede o no ser, dependiendo de la naturaleza del negocio. # 2 - # 5 debe evaluarse en el contexto de otros problemas que enfrenta la empresa.

Idealmente, # 2 - # 5 nunca, nunca sucedería. En la vida real, con prioridades conflictivas, las personas que firman su cheque de pago pueden querer que trabaje en otras cosas en lugar de escribir el código perfecto que nunca, nunca tiene un problema. No quedarán impresionados si # 5 se arregla a costa de no arreglar un error más serio en otro programa.

    
respondido por el poke 08.10.2013 - 20:50
fuente
5

La solución es crear una colección de bibliotecas con funciones de uso común que pueda reutilizar en todos los proyectos. P.ej. Tengo una biblioteca .NET de StringFunctions.dll que hace cosas como codificación, cifrado, descifrado, evaluación de expresiones regulares, etc. De esta manera, no tengo que reescribir continuamente las cosas que no cambian.

Tener un contenedor para las tareas de creación de archivos también tiene mucho sentido. Su biblioteca podría exponer un método llamado GetFile () que realiza todas las comprobaciones por usted y devuelve un valor nulo o un archivo (o lo que considere útil).

    
respondido por el Captain Kenpachi 08.10.2013 - 18:19
fuente
4

Creo que debe aprender a decidir cuánto se debe hacer para cada proyecto. Algunos proyectos pueden ser triviales y realmente no necesitas dedicar todo ese tiempo a perfeccionarlos. No todo va a necesitar un cifrado sólido ni todo será escalado a millones de usuarios.

Escribir un programa que pueda escalar bien para más de un millón de usuarios tomará el tiempo y la experiencia que tiene ahora, pero si sabe que su aplicación no será utilizada por más de 1000 usuarios como máximo, no tiene sentido en pasar todo ese tiempo perfeccionándolo.

Creo que esta es una etapa importante en su carrera de programación y ahora necesita pasar al siguiente nivel, que tiene que ver con la madurez y no con la programación. Debe poder decidir correctamente cuánto tiempo y código debe ser suficiente para cualquier proyecto en particular.

Y como todo lo demás, puedes lograr esto también con la práctica. Así que trate de decidir esto antes de comenzar un proyecto, en algún momento, incluso mientras ya está trabajando en él, con la experiencia también lo superará. Puede haber algunos golpes y fallos al principio, pero con el tiempo lo perfeccionarás (toma de decisiones, no código).

    
respondido por el Sachin Palewar 08.10.2013 - 09:09
fuente
3

@Zilk, no soy un gran programador y he estado programando desde 1998. Incluso ahora me enfrento a este problema. Pero lo que me di cuenta es en última instancia, la calidad importa. Si muero hoy, alguien debería poder recoger lo que estoy haciendo ahora de donde me he ido. Tales deben ser los estándares de programación (Universal).

Ahora me he movido de desarrollador a arquitecto. Mudarse a la administración está cambiando la línea. Si quieres continuar con tu pasión puedes moverte para convertirte en Arquitecto.

Inicialmente como arquitecto técnico - > Solution Architect - > Enterprise Architect - > Chief Architect y así sucesivamente.

Como arquitecto, guiarás a las personas hacia el éxito. Gente como usted que ha programado durante décadas esos años de experiencia que puede utilizar para guiar a otros.

Como un pájaro más alto, vuela más tierra que puede ver, así es tu experiencia.

Permítame decirle que programar la implementación correcta es importante que programar una implementación incorrecta más rápido. Recientemente, uno de mis juniors programó algo mal y le costó mucho dinero a un banco. Por supuesto que habíamos entregado a tiempo antes, ¡pero eso no sirvió! ¿Se me asignó el rol de guía aunque el mismo junior hubiera codificado que el problema no hubiera ocurrido? Estoy dando este ejemplo para subrayar que dar una buena orientación también es importante. Algunos llaman a este trabajo como Consultor.

    
respondido por el Satish 08.10.2013 - 08:49
fuente
3

Otra opción es: deje de escribir código, en lugar de eso, venda su experiencia para detectar los problemas con anticipación.

En otras palabras, conviértete en un Consultor .

Muchas organizaciones se complacen en pagar costosos dólares (si no es el máximo) para que alguien detecte los problemas antes que pasan meses creando el código que genera los problemas. Es bien sabido que corregir un error en el diseño, es órdenes de magnitud más barato / más fácil que corregirlo una vez que se ha codificado, probado y desplegado.

No escribirás tanto código, y es probable que te lo pierdas, pero parece que las líneas de código reales no son tu fortaleza central, pero al saber qué líneas de código debería estar escrito - y cuál no debería.

Enfócate en tus fortalezas.
(bueno, si eso es lo que disfrutas ...)

    
respondido por el AviD 15.10.2013 - 13:17
fuente
2

Mi mejor recomendación para ti es: bloques de construcción.

Cree un bloque de creación de archivos en el que pueda confiar siempre, cree uno para su API, deje de perder el tiempo escribiendo lo mismo una y otra vez. Piense en todos los problemas de una vez y repárelos de una vez por todas.

Nadie se pondrá al día con eso, ciertamente no es el novato que dedica el 80% de su tiempo a depurar el código que falla en casos de esquina que no comprenden.

Más que nada, no solucione problemas que no puedan ocurrir, como permisos incorrectos.

Si los permisos son incorrectos, algo ya está mal y debe corregirlo en lugar de hacer que su programa sea una prueba de balas.

En algún momento debes simplemente no dispararte en el pie en lugar de comprobar siempre si lo hiciste o no.

En lugar de dedicar tiempo a la documentación, dedique tiempo a hacer que su código se autodocumente y lo más corto posible. Reemplace todas esas funciones duplicar-ish. Reduce tu biblioteca, cambia el nombre de las cosas con precisión.

    
respondido por el Morg. 11.10.2013 - 08:54
fuente
1

No seas demasiado duro contigo mismo. Usted está trabajando en una profesión de creciente complejidad, que requiere más inteligencia humana, conocimiento y experiencia que nunca.

La potencia de procesamiento de la computadora se está ralentizando, quizás pronto se está estancando, lo que conlleva la necesidad de introducir chips de múltiples núcleos, numéricos con potencia de gpu, paralelismo, etc. Hay tantos transistores que se pueden colocar en un chip.

Por lo tanto, los grandes avances actuales y futuros provendrán de los programadores: algoritmos avanzados y código más eficiente.

Si observas GTA 4 y GTA 5, las diferencias son asombrosas. Pero ambos se ejecutan en el mismo hardware. Este es el resultado de una práctica de programación muy inteligente y avanzada que simplemente no era necesaria o estaba disponible hace 10 años.

También podría significar que los programadores experimentados pueden llegar a ser más valiosos en el futuro, al igual que otras profesiones como la ingeniería, donde las ganancias máximas suelen ocurrir al final de la carrera.

    
respondido por el AsymLabs 10.10.2013 - 10:09
fuente
1

Al igual que tú, comencé a programar a la edad de 14 años, también cuando obtuve mi primera computadora (aunque había estado estudiando durante algunos meses en ese momento). Sin embargo, estoy "sólo" 33 ahora. :-)

Mi sugerencia es que, cuando desarrolle algo, tome cada una de esas preocupaciones (permisos de archivo, número de archivos en un directorio, etc.) y luego utilice toda su vasta experiencia para responder algunas preguntas al respecto, en este espíritu:

  • ¿Cuánto tiempo tomaría manejar ese problema correctamente en su código?
  • Si no lo manejas correctamente, ¿qué tan probable es que esto te muerda más tarde?
  • Si te muerde, ¿cuáles son las consecuencias?

Armado con esas respuestas, un hombre tan experimentado no tendrá problemas para tomar una decisión sabia. ;-)

Es responsabilidad de los "veteranos" como usted presentar este tipo de requisito, y eso implica identificar qué puede salir mal y decidir a qué problemas potenciales debería prestar atención.

    
respondido por el igorrs 03.04.2014 - 13:50
fuente
0

Saber todos los criterios posibles al desarrollar una aplicación es lo más importante para desarrollar un producto de calidad. Lo estás haciendo bien en esto. Una cosa que puede hacer es, puede clasificar el requisito en nivel de calidad y luego asignar el nivel con el plazo establecido. De este modo, podrá cumplir el plazo del proyecto fácilmente.

    
respondido por el Jagz W 08.10.2013 - 12:37
fuente
0

En palabras de Edsger Dijsktra: "Si la depuración es el proceso de eliminar errores de software, la programación debe ser el proceso de incluirlos". Solo estás haciendo menos de lo último, así que tienes que hacer menos lo primero . Es solo una cuestión de aprender a dedicar tiempo a codificarlo correctamente. Sigo siendo un programador relativamente joven (lea 20 veces) y aspiro a poder codificar algo completamente bien una vez. Una hora de planificación y 10 minutos de codificación es mucho mejor que 10 minutos de planificación, una hora de codificación y tres de depuración.

    
respondido por el ford prefect 09.10.2013 - 14:55
fuente

Lea otras preguntas en las etiquetas