Cómo codificar más rápido (sin sacrificar la calidad) [cerrado]

144

He sido codificador profesional durante varios años. Los comentarios sobre mi código generalmente han sido los mismos: escribe un gran código, bien probado, pero podría ser más rápido .

Entonces, ¿ cómo me convierto en un codificador más rápido, sin sacrificar la calidad? En aras de esta pregunta, voy a limitar el alcance a C #, ya que eso es principalmente lo que codifico (por diversión), o Java, que es lo suficientemente similar en muchos aspectos.

Cosas que ya estoy haciendo:

  • Escriba la solución mínima que hará el trabajo
  • Escriba una serie de pruebas automatizadas (evita regresiones)
  • Escriba (y use) bibliotecas reutilizables para todo tipo de cosas
  • Utilice tecnologías conocidas donde funcionen bien (por ejemplo, Hibernate)
  • Use patrones de diseño donde encajen en su lugar (por ejemplo, Singleton)

Todos estos son geniales, pero no creo que mi velocidad aumente con el tiempo. Yo hago cuidado, porque si yo puedo hacer algo para aumentar mi productividad (incluso en un 10%), que es 10% más rápido que mis competidores. (No es que tenga ninguno)

Además de eso, mis gerentes me han enviado esta retroalimentación, ya sea desarrollo de Flash a pequeña escala o desarrollo empresarial Java / C ++.

Editar: Parece que hay muchas preguntas sobre lo que quiero decir con rápido y cómo sé que soy lento. Déjame aclarar con algunos detalles más.

Trabajé en equipos pequeños y medianos (5-50 personas) en varias empresas a través de varios proyectos y diversas tecnologías (Flash, ASP.NET, Java, C ++). La observación de mis gerentes (que me dijeron directamente) es que soy "lento".

Parte de esto se debe a que un número significativo de mis compañeros sacrificaron la calidad por la velocidad; escribieron código con errores, difícil de leer, difícil de mantener y difícil de escribir para pruebas automatizadas. Mi código generalmente está bien documentado, es legible y comprobable.

En Oracle, siempre solucionaba errores más lentamente que otros miembros del equipo. Sé esto, porque recibiría comentarios al respecto; Esto significa que otros desarrolladores (sí, más experimentados y con más experiencia) podrían hacer mi trabajo en menos tiempo del que me llevó, con casi la misma calidad (legibilidad, mantenibilidad y capacidad de prueba).

¿Por qué? ¿Qué me estoy perdiendo? ¿Cómo puedo mejorar en esto?

Mi objetivo final es simple: si puedo hacer el producto X en 40 horas hoy, y puedo mejorar de alguna manera para poder crear el mismo producto a las 20, 30 o incluso 38 horas mañana, eso es lo que quiero saber: ¿como llego hasta ahí? ¿Qué proceso puedo usar para mejorar continuamente? Pensé que se trataba de reutilizar código, pero parece que eso no es suficiente.

cenizas999
fuente
44
¿Otros codifican más rápido que usted con la misma calidad? De lo contrario, señale sus registros de mantenimiento e informes de errores para indicar que la velocidad no es un problema.
Michael K
3
Posible duplicado: programmers.stackexchange.com/questions/55692/…
Corbin marzo
1
Para intentar ganar la carrera, algunos elegirán sus caballos más rápidos y los derrotarán para ir más rápido. ¿Alguna pregunta?
Paul
24
No tengo una respuesta para ti, pero tengo algo que puede hacerte sentir mejor. Por lento que sea como programador, por ineficiente que se sienta, su gerente es mucho, mucho peor. ¿Qué tipo de idiota dice: "Hola Bob, eres demasiado lento" sin ayudarte a mejorar? También podría decirte que eres demasiado bajo. Eso no es liderazgo, es solo fastidiar. Supongo que tengo una sugerencia: encontrar un trabajo con un gerente competente, uno que trabaje con usted para superar sus deficiencias.
Malvolio
1
Todas las respuestas me hacen infeliz. Si solo quieres el paso noob-> mediocre, entonces tal vez hacer una cosa está bien. Pero mediocre-> experto siempre requiere aprender todo. Debe aprender su VCS, su editor, su lenguaje de programación y sus marcos en profundidad. Debe repetir pasos difíciles e interesantes que puede hacer sin pensar. Y luego necesita encontrar una manera de aplicar el contexto, como la diferencia entre las necesidades del cliente y las necesidades de su compañero de trabajo, cómo su estado de ánimo diario influye en su capacidad para codificar / diseñar / discutir. Si quieres 1 cosa, haz esto: aprende todo.
erikbwork

Respuestas:

158

Me gusta el enfoque de Jeff Atwood sobre esto que se puede encontrar aquí http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

Básicamente, en el artículo hace referencia a un pasaje del libro Art & Fear de David Bayles y Ted Orland. El pasaje dice:

El maestro de cerámica anunció el día de la inauguración que estaba dividiendo la clase en dos grupos. Dijo que todos los que estaban en el lado izquierdo del estudio serían calificados únicamente por la cantidad de trabajo que producían, todos los que estaban a la derecha únicamente por su calidad. Su procedimiento fue simple: en el último día de clases traería las básculas de baño y sopesaría el trabajo del grupo de "cantidad": cincuenta libras de macetas calificadas con una "A", cuarenta libras con una "B", y así sucesivamente. Sin embargo, aquellos que fueron calificados en "calidad", necesitaban producir una sola maceta, aunque perfecta, para obtener una "A". Bueno, llegó el momento de calificar y surgió un hecho curioso: los trabajos de la más alta calidad fueron producidos por el grupo que se calificaba por cantidad. Parece que mientras la "cantidad"

Esencialmente ensuciarse las manos más rápido y con mayor frecuencia mejora sus habilidades mejor que pasar su tiempo estudiando y teorizando sobre la forma "perfecta" de hacerlo. Mi consejo, sigue practicando, mantente al día con la tecnología y estudia diseño.

chrisw
fuente
12
¿Sin embargo, esta analogía no implica que los alfareros produjeron una pila de botes de basura antes de producir los de calidad? ¿Podrías hacer eso en un entorno profesional, con toda conciencia? ¿Y qué hay de aquellos que estudiaron y teorizaron y luego hicieron el trabajo antes de la fecha límite?
pdr
44
Estoy de acuerdo con 20 botes de basura para la experiencia de programación hobby. Eso también me ayuda con mi experiencia profesional de programación; Además, tengo que empezar en alguna parte.
cenizas999
23
Simplemente elijo mirar esto por valor de superficie, "la práctica hace la perfección". No mires demasiado profundo;)
chrisw
66
No me gusta esta respuesta porque puede tomarse fácilmente de la manera equivocada, al igual que los "prototipos descartables" realmente nunca parecen descartarse.
Rudolf Olah
2
Me resulta extraño que tanta gente tenga un problema con esto. Es una analogía casi perfecta para el proceso de desarrollo iterativo. Construye algo rápido para cumplir con los requisitos, corrige errores y refactoriza hasta que sea correcto y lo suficientemente bueno. Si no está creando software de esta manera, realmente necesita probarlo. La rumia y la mirada en el ombligo son mucho menos efectivas que hacer algo y dejar que la gente lo golpee.
JimmyJames
72

Una posibilidad que nadie más parece haber mencionado es que lo estás haciendo bien y tus gerentes no son muy buenos. ¿Cómo están midiendo la productividad? ¿Pueden darte ejemplos específicos o es solo una percepción general? ¿Han tenido en cuenta la cantidad de tiempo dedicado a arreglar el trabajo de otras personas en comparación con el tuyo?

He visto a muchas personas obtener crédito por hacer cosas, mientras que el resto de su equipo arregla el desastre que han dejado atrás.

pdr
fuente
1
Esta es probablemente una gran parte del problema. Mirándolo en retrospectiva, parece demasiado concluyente que siempre me comparen con las personas que trabajan en mi empresa años más que yo. Hmm ...
cenizas999
Si ese es el caso, mi consejo es hacer las dos primeras preguntas directamente y ver qué respuesta obtienes, tómalo desde allí
pdr
16
cuán cierto es, tan a menudo me he encontrado con gerentes que me dicen que soy incompetente cuando los proyectos que realizo en producción generan sistemáticamente una o dos órdenes de magnitud menos llamadas de soporte que el trabajo equivalente de otros equipos. Muchos simplemente no pueden ver la imagen más grande. La métrica ayuda tanto como es una molestia. Por lo general, dicho administrador intentará jugar con el sistema de tal manera que sus estadísticas se vean bien.
Newtopian
Esto es más un comentario que una respuesta. Personalmente, siempre quiero ser más rápido y más eficiente como programador, independientemente de lo que piensen los demás. Definitivamente hay mucho que discutir sobre el tema.
Andres Canella
@AndresCanella Cada respuesta en esta pregunta es básicamente un comentario largo. Tienes razón, hay mucho que discutir. Este realmente no es un buen formato para el debate (ni pretende serlo). Pero para empezar fue una buena pregunta, por eso está cerrada y marcada como Wiki de la comunidad, por lo que nadie obtiene puntos de reputación, en lugar de eliminarse.
pdr
39

La mayoría de lo que la gente piensa que es importante no es importante. La velocidad de escritura no es importante. Máquinas o herramientas más rápidas no son importantes. No somos mecanógrafos ni operadores de máquinas. Somos pensadores trabajadores. Somos tomadores de decisiones .

Lo que es importante es el uso de información para mejorar continuamente su proceso de toma de decisiones. La única forma de hacerlo, como adquirir cualquier otra habilidad, es a través de la experiencia, la práctica decidida y la retroalimentación continua.

  • Trabajar en proyectos paralelos.
  • Trabajar en proyectos de código abierto.
  • Trabaja con desarrolladores que sean mejores que tú. Programa par!
  • Exponerse a nuevas herramientas y técnicas. Quédate con lo que funciona.
  • Haga ejercicios de programación diseñados para entrenar su aparato de toma de decisiones *.
  • Monitoree su mejora en función de métricas objetivas como velocidad y velocidad de defectos, y métricas subjetivas como calidad y adecuación del código.

Finalmente: recuerde que la velocidad sin calidad es inútil, y viceversa. Para maximizar su utilidad, encuentre un equilibrio entre estas tensiones.

* http://codekata.pragprog.com/

Rein Henrichs
fuente
¿Puedes sugerir otros sitios / términos a google? Creo que abordar un desafío extraño por semana podría hacer que mi cerebro se mueva en diferentes dimensiones.
cenizas999
Un favorito reciente mío es pragprog.com/titles/btlang/seven-languages-in-seven-weeks
Rein Henrichs
1
La parte al principio no tiene sentido. Cualquier cosa que te haga más rápido te hace más rápido. Si pasa al menos parte de su tiempo escribiendo, mejorar su velocidad de escritura lo hará más rápido. Si al menos parte de su tiempo lo pasa esperando a la computadora, entonces una computadora más rápida lo hará más rápido. Cuando estás en la búsqueda de ser lo más rápido posible y mejorar constantemente, nada debe pasarse por alto.
still_dreaming_1
12
Las pequeñas cosas como escribir y la velocidad de la computadora hacen una gran diferencia. Esto se debe a los efectos secundarios inesperados. Cuando tiene que esperar su computadora, la mayoría de las personas se frustran y algunas incluso se distraen. La combinación de frustración y distracción son enormes asesinos de productividad. Algo similar se aplica a escribir. Si es rápido escribiendo, eso probablemente significa que se ha vuelto muy bueno en la escritura táctil, y probablemente no piense demasiado en escribir. Esto libera sus ojos y cerebro para enfocarse en la tarea en cuestión, un gran impulso de productividad.
still_dreaming_1
@INTPnerd Estoy de acuerdo. Si pasas tiempo pensando en cómo aparece la palabra "lanzar" en tu pantalla ("Necesito mover el mouse allí, luego hacer clic, entonces necesito encontrar la 't' en mi teclado") tu cerebro tampoco tiene tiempo para considerar las decisiones reales
erikbwork
25

Es muy posible que, en realidad, se le pida que sacrifique algo de calidad, para una mayor velocidad.

En algunos entornos de desarrollo 1 , simplemente no vale la pena el tiempo extra para producir algo pulido, cuando "lo suficientemente bueno" servirá.


1 - Estoy pensando en el "herrero interno" en particular, pero probablemente hay otros.

Jens Bannmann
fuente
55
Eso es lo que concluí de mis primeros trabajos: otros escribían una calidad significativamente menor, a costa de una gran velocidad. Ese es mi talón de Aquiles; Me resulta muy difícil escribir un código incorrecto que sé que me morderá más tarde.
cenizas999
Ese es un problema fácil de resolver. necesita cambiar su entorno de software. Debe trabajar en un entorno en el que valorarlo sea más valioso que hacerlo rápidamente. Hay trabajos por ahí donde sí importa.
Michael Shaw
Después de haber trabajado en entornos donde ambos son igualmente valorados, entre todos los que lo hacen bien, los que lo hacen más rápido están superando a los que lo hacen más lentamente. Y creo que estoy en el último grupo.
cenizas999
2
bueno, en ese caso, probablemente se deba a las estrategias que usas para escribir, probar y depurar código. pregunte si puede emparejar un programa con un programador "rápido" y ver cómo organizan sus procesos de pensamiento?
Michael Shaw
1
@ ashes999: Con práctica, experiencia y paciencia, pasarás del último grupo al anterior. No hay píldora mágica para tomar que te hará la transición durante la noche.
FrustratedWithFormsDesigner
12

Parece que está haciendo todas las cosas buenas, eso en el mediano plazo lo hará más rápido, por lo que no es obvio si realmente es lento. Solo que realmente lo sabes. (pero es una posibilidad muy real: PeopleWare afirma una diferencia de productividad hasta 10 veces mayor entre los desarrolladores para la misma tarea).

Así que tengo algunas sugerencias para ti:

  1. El tiempo es algo relativo, por lo que quizás el problema no sea su velocidad real sino la percepción del tiempo que está dando. Puede implicar que tomará una semana, pero terminará pasando dos semanas, mientras que otros podrían pasar 3 semanas ... pero solo parece 1 semana lento.

  2. Dado que recibe estos comentarios a menudo, tal vez es hora de hablar con su gerente y sus compañeros para ver lo que dicen: debe haber mucho que aprender de ellos.

  3. Haga un par de programación con un desarrollador de "calidad rápida" para ver si puede detectar la diferencia.

Stephen Bailey
fuente
8

Efectivamente, todo se reduce a la experiencia . Para ser más rápido en lo que haces es como conducir un automóvil, inicialmente tienes miedo ya que otros son conductores rápidos (o ebrios) (o ambos) y quieres llegar a casa de forma segura (en términos de software, quieres asegurarte de que tu código funciona según lo desarrollado y funciona bien).

Con el paso de los años / meses, una vez que se familiariza con la conducción y las autopistas, aprende algunos trucos en el camino que hacen que conducir sea divertido. Eso es lo que llamamos experiencia. Esos "trucos" (que llamo rasgos) es lo que ayuda.

En mi caso, aprendí el uso real de los patrones de diseño mediante la codificación (incluso @ home) y aprendí los usos de algunos. Por lo tanto, cuando encuentro un problema que requiere un patrón de diseño, uso la experiencia pasada para ver cuáles funcionaron y por qué funcionaría / no funcionaría para mi situación.

En resumen:

  • La experiencia crea rasgos que aumentan la confianza y un mejor software.

PD: La experiencia también proviene de aprender de los demás. Por ejemplo, ayuda de SO, programación de pares, revisiones por pares, etc. No puede tener una experiencia si no puede mirar hacia atrás y aprender de los errores (o si alguien nunca desafía su esfuerzo).

Buhake Sindi
fuente
Realmente espero que esta no sea la respuesta correcta; Ya paso gran parte de mi tiempo libre codificando, y espero que me falte algo más que me brinde una ventaja significativa.
cenizas999
@ cenizas999, ok! con codificación de tiempo libre, ¿revisas tu trabajo? Mi punto es que debe haber tiempo para trabajar en la optimización del código y dominarlo. Todos podemos codificar, pero ¿cuántas veces nos damos tiempo para la optimización?
Buhake Sindi
@TEG Lo reviso entre proyectos; p.ej. Si codificara algo de cierta manera en el proyecto n. ° 1, en un proyecto similar n. ° 2, podría reflexionar mucho sobre los defectos de diseño y refactorizarlos.
cenizas999
@ashes: "refactorizar mucho" significa que tiene un tiempo de caída justo allí porque su diseño inicial no era óptimo. Si su jefe no sabe que tiene un problema para explicarle a dónde fueron las horas. Si el jefe lo sabe, tiene un problema para explicar por qué no hizo que un compañero de trabajo experimentado revisara su diseño en primer lugar.
@TRA lo siento, debería haber especificado que en los proyectos de pasatiempo refactorizo ​​mucho. En el trabajo, refactorizo ​​ligeramente o creo tareas visibles para que mi gerente sepa que estoy refactorizando.
cenizas999
8

La pregunta es si usted es menos costoso cuando mira el costo total a largo plazo.

En otras palabras, ¿sus correcciones de errores cuidadosamente elaboradas son de tan alta calidad (incluidos los casos de prueba y la documentación) que superan los costos de tener que mantener las correcciones de errores realizadas por sus compañeros de trabajo más rápidos?

En caso afirmativo, debe informar a sus superiores de este hecho. Puede ser difícil argumentar si no miden y tienen los datos necesarios para confirmar su evaluación.

Si no, entonces debes considerar por qué este es el caso:

  • ¿Eres demasiado inexperto?
  • ¿Pasa mucho tiempo haciendo cosas no solicitadas que cree que deberían estar allí?
  • ¿Le resulta difícil determinar cuándo finaliza la solución?
  • ¿Es su código de menor calidad después de todo lo que cree que es?
  • ¿Debería abordar el desarrollo de código de una manera diferente porque le lleva demasiado tiempo acelerar la forma en que lo hace ahora?
  • ¿Pasaste demasiado tiempo en cosas como este sitio?

Piénselo y edite su pregunta con sus hallazgos.

usuario1249
fuente
8

Todas las preguntas que la gente ha hecho sobre si eres realmente lento o no es una tontería. Convertirse en un programador más rápido sin sacrificar la calidad siempre es un buen objetivo, no importa cuán lento o rápido sea. Este es mi objetivo número 1 como programador y nunca terminaré. Siempre trato de ser más rápido sin sacrificar la calidad, estoy obsesionado con eso. Esto es lo que me ha funcionado hasta ahora en el orden de la ayuda, junto con algunas ideas experimentales al final:

1) Nunca dejes de aprender: aprende todo lo que puedas sobre la programación y el uso de las computadoras en general. Encuentra áreas en las que eres débil y apréndelas. Incluso si parece completamente ajeno a su trabajo y C #, le garantizo que si lo está buscando, a menudo encontrará formas de aplicarlo a lo que hace. El aprendizaje también se trata de la experiencia, así que no solo lea cosas, sino que pruébelas y amplíe sus habilidades. Si está acostumbrado a usar Windows, pruebe Unix o viceversa. Si normalmente desea utilizar las herramientas de línea de comandos y los editores de texto de IDE, o viceversa. Si escuchas de una herramienta o tecnología de la que no has oído hablar antes o no sabes mucho, no cedas ante la tentación de seguir adelante. ¡Búscalo! No tenga miedo de pensar fuera de la caja y aprender nuevas tecnologías experimentales que otros dicen que no son prácticas;

2) Divida los proyectos: intente dividir sus proyectos en mini proyectos. Intente hacer una nueva versión todos los días o una vez cada pocos días como máximo. Pregúntese "¿Cuál es la cantidad mínima de funcionalidad que puedo liberar, y aún así liberar algo que sea útil para el usuario". Esta es una habilidad que aprenderás al hacerlo. Es posible que deba convencer a sus gerentes para que le permitan hacer esto, pero generalmente estarán contentos con los resultados con bastante rapidez. Al hacer esto, comenzará a notar que las cosas que creía que eran esenciales para su función son en realidad funciones adicionales que se pueden desarrollar más adelante. Esto le permite a usted y a sus gerentes priorizar solo las funciones más importantes en lugar de todas las funciones relacionadas con la que está trabajando. Esto le permite pensar más rápido manteniendo su mente clara y enfocada. A su vez, legítimamente programará más rápido. También es probable que sus gerentes, o al menos los gerentes de su gerente, perciban que ahora está programando incluso más rápido de lo que realmente es porque está obteniendo más lanzamientos. Otro gran beneficio de esto es que será mucho mejor para estimar cuánto tardarán en completarse las versiones, y sus gerentes lo amarán por esto. Como ya está haciendo muchas pruebas automatizadas, no debería tener problemas para realizar lanzamientos frecuentes que sean estables. Sin embargo, es posible que necesite reforzar su sistema de construcción automatizado. Recomiendo leer el libro Entrega continua en la serie Martin Fowler. Es una lectura difícil y porque es extremadamente repetitiva, pero sigue siendo muy útil. También es probable que los gerentes perciban que ahora está programando incluso más rápido de lo que realmente es porque está obteniendo más versiones. Otro gran beneficio de esto es que será mucho mejor para estimar cuánto tardarán en completarse las versiones, y sus gerentes lo amarán por esto. Como ya está haciendo muchas pruebas automatizadas, no debería tener problemas para realizar lanzamientos frecuentes que sean estables. Sin embargo, es posible que necesite reforzar su sistema de construcción automatizado. Recomiendo leer el libro Entrega continua en la serie Martin Fowler. Es una lectura difícil y porque es extremadamente repetitiva, pero sigue siendo muy útil. También es probable que los gerentes perciban que ahora está programando incluso más rápido de lo que realmente es porque está obteniendo más versiones. Otro gran beneficio de esto es que será mucho mejor para estimar cuánto tardarán en completarse las versiones, y sus gerentes lo amarán por esto. Como ya está haciendo muchas pruebas automatizadas, no debería tener problemas para realizar lanzamientos frecuentes que sean estables. Sin embargo, es posible que necesite reforzar su sistema de construcción automatizado. Recomiendo leer el libro Entrega continua en la serie Martin Fowler. Es una lectura difícil y porque es extremadamente repetitiva, pero sigue siendo muy útil. y tus gerentes te amarán por esto. Como ya está haciendo muchas pruebas automatizadas, no debería tener problemas para realizar lanzamientos frecuentes que sean estables. Sin embargo, es posible que necesite reforzar su sistema de construcción automatizado. Recomiendo leer el libro Entrega continua en la serie Martin Fowler. Es una lectura difícil y porque es extremadamente repetitiva, pero sigue siendo muy útil. y tus gerentes te amarán por esto. Como ya está haciendo muchas pruebas automatizadas, no debería tener problemas para realizar lanzamientos frecuentes que sean estables. Sin embargo, es posible que necesite reforzar su sistema de construcción automatizado. Recomiendo leer el libro Entrega continua en la serie Martin Fowler. Es una lectura difícil y porque es extremadamente repetitiva, pero sigue siendo muy útil.

3) Usa la técnica de pomodoro y adapta / cambia lo que no funciona para ti. Si combina esto con el número 2 en esta lista, obtendrá un ENORME impulso de productividad.

4) Aprende Vim. Incluso si termina utilizando estos comandos dentro de Visual Studio a través de ViEmu, o desde dentro de Eclipse a través de un complemento, o desde dentro de Emacs, obtendrá productividad. La mejor manera de aprender Vim es comenzar a usarlo y forzarse nunca a hacerlo (deshabilitarlo / volver a sus herramientas anteriores) hasta que lo haya dominado. Al principio es doloroso, pero nunca querrás retroceder, e incluso encogerte cuando tienes que trabajar sin él. Algunos dirían que esto no aumentará su velocidad por mucho. Pero más rápido es más rápido, especialmente cuando leer y modificar código es LO QUE HACEMOS, y ocasionalmente me he ahorrado mucho tiempo con esto.

5) Este último no se recomienda necesariamente ya que no estoy seguro de que sea una buena idea, y en realidad puede disminuir su productividad, pero lo superaré de todos modos. Puede intentar hacer más pruebas de aceptación y menos pruebas unitarias, o tal vez al menos asegurarse de hacer algunas pruebas de aceptación. He tenido éxito con SpecFlow, pero sospecho que hay algo mejor por ahí. Incluso escribir las especificaciones puede ser bastante técnico, por lo que es posible que desee que su gerente / cliente escriba primero una versión preliminar que cambie significativamente, o puede escribir todo usted mismo y hacer que lo lean y lo aprueben. Esto te ayudará con el número 2 de esta lista. Además, las pruebas de aceptación pueden ser más prácticas y requieren menos código que las pruebas unitarias. Esto no quiere decir que los reemplacen, diferentes herramientas para diferentes cosas.

6) Este es aún más experimental y controvertido. En realidad no lo he hecho, así que no puedo recomendarlo exactamente. Aprenda y use el Sistema de Meta Programación de JetBrains. Úselo para crear herramientas que su gerente / cliente usa para crear el software deseado por sí mismo. Incluso podría dejar de hacer pruebas unitarias y de aceptación si puede usar esto para crear herramientas que su gerente / cliente use para especificar el comportamiento de una manera muy directa y no complicada. La idea no es deshacerse del programador. Los programadores aún necesitarían agregar nuevas funciones a estas herramientas utilizadas por el cliente / gerente cada vez que ellos (las personas, no las herramientas) no puedan crear fácilmente alguna funcionalidad deseada. Creo que MPS u otras herramientas similares son el camino del futuro.

revs INTPnerd
fuente
5

Usa más tu cerebro y haz menos pruebas. Para ser sincero, las pruebas tienen su lugar, pero es costoso.

Además, lea The Art of Unix Programming (gratis en línea, el libro vale la pena)

Finalmente, puede que no estés en el lugar correcto. Clavija redonda en trabajo cuadrado, etc.

En última instancia, es como la escuela: "Producir lo que el maestro quiere" se convierte en "generar lo que la gerencia pide y paga".

Christopher Mahan
fuente
3
Las pruebas me hacen más rápido, no más lento. Menos pruebas significan que más regresiones pasan inadvertidas por más tiempo y son más difíciles de arreglar, porque no puedes dar grandes saltos en el código por temor a que "algo se rompa".
cenizas999
Las pruebas automatizadas para mí son código olfativo. Significa que el código no era lo suficientemente simple.
Christopher Mahan
66
Si su código es tan simple que no necesita pruebas, entonces no hace nada interesante.
Rein Henrichs
¿Cómo lo sabes exactamente? Oh, suponiendo de nuevo ... lo referiré a la Regla de Modularidad: escriba partes simples conectadas por interfaces limpias. (de The Art of Unix Programming)
Christopher Mahan
Creo que puedes tener algo, Christopher. Es aquí donde ashes99 pasa mucho tiempo, por ejemplo, "slew". Demasiado de algo es algo malo. En este caso, a menos que esté enderezando el código para los sistemas de control de vuelo, es posible que desee repensar la cantidad de pruebas que realiza. O entrar en ese tipo de campo.
user21007
5

Si toma un proyecto grande y terminado y obtiene el número de líneas "finales" de código por hora hombre, encontrará que los programadores codifican MUCHO más lento de lo que podría haber imaginado.

Estamos hablando de unas pocas líneas de código al día. El resto del tiempo lo pasas depurando, reescribiendo y haciendo cosas generales de programación.

Es posible que haya escuchado el viejo dicho: si detecta un error mientras lo escribe, le ahorrará 10 veces más si lo captó en el momento de la compilación, que es 10 veces mejor que detectarlo durante el control de calidad, que es 10 veces mejor que atraparlo después del lanzamiento ...

Entonces, ¿cómo lo aceleras? No me concentraría en ninguna forma de velocidad de escritura; reducir los errores y mejorar otras "interacciones futuras" con su código debería ser una inversión mucho mejor de su tiempo.

El código legible y claro es crítico. Escribe su código una vez, pero se leerá docenas de veces. Escribir para facilitar la lectura le ahorrará MUCHOS problemas en el futuro (lo que también le ahorrará mucho tiempo). Si alguna vez vuelves y lees tu código y tienes que pensarlo por un segundo, entonces lo estás haciendo mal.

La programación por pares puede reducir el tiempo de control de calidad y, si considera que un programador produce solo unas pocas líneas al día, si dos pueden codificar a la misma velocidad que uno pero con menos errores, entonces está MUY por delante.

La codificación defensiva (por ejemplo, la verificación de parámetros) puede reducir los problemas ... Si tiene un analista / arquitecto realmente bueno en su equipo, puede ahorrar algo de tiempo con un buen diseño inicial.

De lo contrario, sigue mejorando tus habilidades de diseño. A medida que gane experiencia, podrá reconocer patrones que no funcionarán y evitarlos, podrá identificar los sumideros de tiempo antes, etc.

Bill K
fuente
3

¿Has considerado hacer una auditoría detallada de ti mismo mientras trabajas? Puede realizar un seguimiento con lápiz y papel de cómo está gastando su tiempo o usar algo como Rescue Time para rastrearse.

Una vez que esté más consciente de exactamente CÓMO pasa su tiempo, puede tener una mejor idea de lo que necesita mejorar y concentrar sus esfuerzos allí.

Idealmente, puede desafiar a algunos de sus compañeros de trabajo a hacer esto también, comparar sus resultados y obtener ideas entre ellos. Probablemente tengas algunas fortalezas de las que también podrían beneficiarse.

Tal vez descubra que está pasando demasiado tiempo en una parte de su proceso que podría automatizarse o simplemente que tiene muchas distracciones durante una determinada parte del día y otra parte del día es tranquila, luego puede planificar sus tareas en torno a eso, etc.

O tal vez descubras que las pruebas están tomando más tiempo de lo que pensabas y tienes que repensar tu percepción de que te está haciendo más rápido.

Si nada más, te da algunos puntos de referencia con los que puedes trabajar.

DKnight
fuente
3

De tu lista lo estás haciendo bien.

Si sus colegas están haciendo código con un número CRAP más alto, irán más rápido. CRAP es una métrica con un nombre cómico que combina complejidad ciclomática y cobertura de prueba.

No escriba código que sea más basura de lo que debe. ;)

Mi único cambio para sugerirle es que use bibliotecas, no las escriba a menos que:

  1. Su empresa vende bibliotecas.
  2. Has refactorizado el código recurrente en una biblioteca

Estás leyendo y haciendo y eso es genial. Pero podría estar atrapado pensando en el código procuedural u OO. ¿Se ha expuesto a la programación funcional (por ejemplo, Haskell?) Y a Prolog?

Para agudizar tu técnica de programación OO, ¿has jugado con Smalltalk / Squeak?

Y finalmente, la teoría. ¿Tiene al menos una comprensión rudimentaria de la teoría de grafos? (Algunos programas funcionan con árboles, DAG o simplemente gráficos simples en algún momento. Las redes son gráficos)

Tim Williscroft
fuente
Muchos puntos geniales aquí. Necesito bibliotecas porque necesito una función para el juego X (p. Ej., Almacenamiento de Silverlight en varias sesiones de mi juego), y puedo decir que las necesitaremos más tarde, o son solo un código abstracto (como búsqueda de ruta) que No tengo nada que ver específicamente con mi juego. Tengo un fondo de comp-sci, así que hice procedimientos, OO, funcionales y el otro (Prolog). Teoría de grafos, sí; Profundidad de la recursividad del primer gráfico que he usado muy a menudo, por extraño que parezca.
cenizas999
3

Hasta donde yo sé es:

  1. bueno
  2. rápido
  3. barato

Como gerente, puedes elegir 2.

No se preocupe por los comentarios que ha estado recibiendo sobre la velocidad. Como compañero codificador, preferiría mantener un código bien pensado y bien escrito que algo que se uniera.

Nico
fuente
2

Las cosas principales en las que puedo pensar son las siguientes

  • Aumenta tu velocidad de escritura.
  • Use herramientas que brinden ganancias de productividad. Por ejemplo ReSharper.
  • Máquinas o herramientas más rápidas. Como más RAM o una unidad de estado sólido.

Estoy seguro de que hay algunas cosas que puedes hacer en el área de habilidades de codificación también, pero parece que estás en ese tipo de cosas. Las cosas que enumeré arriba son generalmente ignoradas por los desarrolladores.

mpenrow
fuente
Estoy en igualdad de condiciones con mis compañeros de trabajo con respecto a estas cosas (tal vez tengo una ventaja en la velocidad de escritura); son aún más rápidos, de alguna manera. Experiencia, tal vez?
cenizas999
1
Por encima de un mínimo mínimo de "cazar y picotear", la velocidad de escritura no es el factor limitante.
2
Puede estar a la altura de ellos al tener las herramientas (por ejemplo, Resharper), pero ¿sabe cómo usarlas de manera efectiva? He visto a muchas personas instalar Resharper y luego no aprender a usar el 80% de las funciones. Para el caso, asegúrese de comprender todas las funciones de refactorización y acceso directo de Visual Studio. Obtengo una ventaja del 2-3% sobre cualquier otra persona en mi oficina solo por mantener mis manos en el teclado todo el día. Los ratones son lentos :)
EZ Hart
@EZ Hart: Muy buen punto. Algunos IDEs modernos (estoy pensando en Eclipse, fuera de mi alcance) tienen herramientas muy poderosas para refactorizar, buscar referencias de código (como dónde se hace referencia a una clase o método, no simplemente dónde aparece el texto "myMethod" ) Para algunas de estas características "avanzadas", vale la pena dedicar 5 minutos a aprenderlo para poder administrar la base de código de manera mucho más eficiente.
FrustratedWithFormsDesigner
Estamos todos a nivel. Ninguno de nosotros tiene las herramientas :)
ashes999
2

Podrías tomar un curso de mecanografía rápida. No sé si escribir más rápido es un problema, pero "la codificación demasiado lenta" podría deberse simplemente a velocidades de escritura lentas.

¿Qué pasa con los generadores de código? A veces el código se vuelve repetitivo. La refactorización puede eliminar parte de ella, pero incluso entonces puede tener llamadas repetitivas a la misma función refactorizada. Dependiendo de los datos y el código con el que trabaje, los generadores de código (escritos en Excel, Perl, Java, lo que sea ...) pueden ahorrarle mucho tiempo. Y el uso de herramientas de generación de código para el desarrollo de la interfaz de usuario suele ser obvio.

Y finalmente, tal vez las métricas estén equivocadas. ¿Has considerado que estás codificando a la velocidad más rápida posible dado todo lo demás, y que los plazos son demasiado cortos, lo que te hace parecer un codificador lento?


Según las ediciones en su pregunta, parece que podría tomar el camino de algunos de sus compañeros de trabajo y hackear juntos la solución más rápida que funcionará, ¡y la documentación y el control de calidad serán condenados!

O ... obtenga más experiencia y práctica en un área específica para que conozca la base de código y la API tan bien que pueda codificar las soluciones mientras duerme. Esto se puede hacer pero requiere más tiempo. Si los otros desarrolladores que son más rápidos de lo que se sabe son más senior y más experimentados, entonces solo hay una cosa que hacer: ¡ debes ser más senior y experimentado!

FrustratedWithFormsDesigner
fuente
No son líneas de tiempo; otros compañeros de trabajo pueden hacer el mismo trabajo más rápido. Quizás es experiencia. +1 para la velocidad de escritura; Puedo escribir alrededor de 100WPM, así que tampoco es eso.
cenizas999
@ ashes999: y si las personas que pueden hacer el mismo trabajo más rápido tienen más experiencia, entonces probablemente se beneficiaría más de una mayor experiencia con los sistemas en cuestión. La experiencia requiere tiempo ...
FrustratedWithFormsDesigner
Los generadores de código son una bendición mixta. Pueden ahorrarle tiempo, pero si tiene que dedicar demasiado tiempo al código generado, el ahorro puede convertirse en una pérdida inmanejable.
2

Tengo una objeción a la vista de "calidad sacrificada por la velocidad" de OP.

Los programadores profesionales (programadores) deben satisfacer 3 objetos:
1) El código debe ejecutarse según lo previsto
2) La entrega debe realizarse a tiempo
3) Tener buena calidad, documentación, etc.
4) Otros, etc.

Creo que OP fue culpado de lento probablemente porque OP no lo hizo a tiempo.

9dan
fuente
2

Esta es una trampa 22 difícil de sortear. Aunque todavía puede carecer de experiencia y cierta cantidad de conocimiento en muchos aspectos ya es más rápido que la mayoría, el problema es que es más difícil de medir .

Personalmente, lo mejor que puedes hacer en este momento es medirte a ti mismo. Dése su opinión sobre cómo trabaja, quizás cambios simples en sus hábitos de trabajo pueden hacerlo más productivo.

Encontré que los correos estaban consumiendo mucho más de lo que pensaba simplemente debido a la interrupción. Ahora solo respondo correos electrónicos dos veces al día y gané casi 1 hora de productividad algunos días. Pruebe métodos como pomodoro , lo usé como un medio de medida. A intervalos regulares (15 minutos), anotaría lo que estaba haciendo en ese momento. Esto me permitió ver cómo estaban estructurados mis días y qué podía hacer para maximizar la eficiencia.

Newtopian
fuente
Entonces, ¿estás diciendo que tienes un perfil de muestra tú mismo? Interesante. :)
sum1stolemyname
en realidad fue un efecto secundario de un método de seguimiento de tiempo que probé durante un tiempo ( davidseah.com/tools/ett/alpha ). Resulté algunas tendencias de datos interesantes e inesperadas cuando comencé a mirar más allá de la parte del rastreador de tiempo. Es después de que aprendí sobre pomodoro, GTD y tal.
Newtopian
0

La ventaja de Squeak para la codificación rápida va mucho más allá de simplemente "perfeccionar las habilidades de OOP". Hay una razón por la cual las GUI modernas, así como las IDE, se inventaron en Smalltalk, sin mencionar que JUNIT era un puerto de SUNIT para Java, el término "OOP" se inventó para describir Smalltalk, etc., etc.

Siempre se debe usar el lenguaje y el entorno más adecuados para lo que se espera lograr, pero para la creación de prototipos en general, al menos, compararía el chirrido con cualquier cosa, con la posible excepción de HyperCard, e incluso eso requeriría una evaluación comparativa para ver cuál era en realidad más rápido dado que hay instalaciones similares a las hipercartas integradas en Squeak

usuario22340
fuente