¿Cómo han cambiado sus valores de codificación desde que se graduó?

Question

Todos salimos de la escuela con las estrellas en nuestros ojos y poca experiencia en la programación del "mundo real". ¿Cómo han cambiado sus opiniones sobre la programación como oficio desde que adquirieron más experiencia fuera de la academia?

Me he vuelto más y más sobre el diseño a la McConnell: uso amplio de encapsulación, código de calidad que le da cálidos sentimientos borrosos cuando lo lee, mantenibilidad sobre el rendimiento de ejecución, etc ..., mientras que muchos de mis colegas -los trabajadores han seguido un camino diferente de capas de intermediarios que se interponen en el camino, código que es correcto a la vista y más fácil de localizar, incluso si es más difícil de leer, y diseños centrados en el rendimiento.

¿Qué has aprendido sobre el oficio del diseño de software que ha cambiado la forma de abordar la codificación desde que abandonaron el mundo académico?

Answer 1

Antes de la universidad: el truco es ser lo suficientemente inteligente como para saber la manera correcta para crear su programa antes de empezar a programar. Nunca fui lo suficientemente inteligente y me di cuenta de mis errores después de 15 minutos de codificación. :-(

Después de la universidad: la estimación de tiempo para crear software es imposible hacerlo con precisión, por lo que no debería haber horarios

Después de unos años en la industria:. Después de fallar constantemente para conseguir La primera vez, decidí que era imposible. Desde que estaba trabajando en el depurador de Visual C++, decidí que la clave para ser un programador exitoso es ser muy bueno en la depuración. Escribes todo lo que puedes, luego utilizo el depurador para encontrar los problemas, luego resuélvalos.

Afte r otros pocos años: Cambié de Visual C++ Debugger al Editor de Visual C#. Decidí que el depurador no importa, la clave para ser un gran desarrollador es ser excelente en edición. También leo Fowler's Refactoring. En lugar de intentar hacer las cosas bien la primera vez, o equivocarme la primera vez y vivir con eso, decidí hacerlo mal la primera vez, y luego mejorar el diseño con refactorización.

Otros conocimientos: La simplicidad y la claridad del código son fundamentales. Hágalo bien y podrá acceder a cualquier otra cosa que desee (corrección, rendimiento, capacidad de agregar nuevas funciones). Además, cada vez que tenga un error, no solo solucione el error, no solo solucione errores similares en otros lugares, sino cambie la forma en que hace las cosas para garantizar que ese tipo de error nunca vuelva a suceder.

Como directivo, dirigí un equipo de acuerdo con los valores de simplicidad, refactorización, claridad, capacidad de prueba, obtener comentarios rápidamente, esforzarme por un buen diseño, prácticas de codificación que eliminan clases enteras de errores, etc. Tuvimos un éxito fantástico. Como desarrollador individual continué siguiendo lo que había aprendido como gerente, y tuve la mayor productividad de mi carrera (aunque mi antiguo equipo fue mucho mejor en eso que yo). Mi punto es que estos principios han sido probados en el mundo real.

Answer 2

El director DRY (Do not Repeat Yourself) se ha vuelto mucho más importante para mí. Mis criterios para un software exitoso también han cambiado: soy más feliz con el software que otras personas pueden ampliar fácilmente.

Answer 3

Me gradué de ingeniería de software. Aprendí que casi nadie quiere software de ingeniería. Es costoso y lento de desarrollar. Mucha gente quiere todo lo contrario. Algo que se junte tan rápido y descuidado como sea posible, siempre y cuando funcione. A nadie le importa cómo se ve el código debajo, siempre y cuando sea funcional. Personalmente, intento presionar por prácticas de desarrollo de software más profesionales, pero me doy cuenta de que, a veces, lo rápido y lo sucio es mejor.

Answer 4

Cuanto más simple sea el código/concepto, mejor. (No sobrearquitectivo.)

Answer 5

Me gradué hace 10 años así que tal vez el hecho de que intellisense permita más verbosidad y que la delcaritiveness de HTML y XAML transmita la intención del desarrollador ha jugado un papel en esto, pero mi opinión sobre el código en línea comenta cambiado considerablemente Mientras estaban en la escuela, me enseñaron y me convencieron de que casi todas las líneas de código necesitaban un comentario. Mis mentores de la vieja escuela creían lo mismo. Ahora creo que debería esforzarme por hacer un código que exprese claramente mi intención. Solo comento cuando no puedo escribir código que tiene una intención clara.

Answer 6

No aprendí mucho, excepto que no utilice números mágicos:/

Answer 7

He aprendido que la práctica que se shun sobre en mi escuela, también conocido como copiar y pegar código de otras personas es en realidad cómo se hace en el mundo real. Entonces, en lugar de obtener falsas marcas por plagiar el código de otras personas en la escuela, es lo más inteligente en el mundo real, aprovechando el código bien probado de otras personas/usando marcos/apis en lugar de tratar de reinventar la rueda cada vez.

Por supuesto que siempre comprobar la licencia de código antes de que yo las uso en mi aplicación :)

Answer 8

/******************************************************** 
* Star encrusted header's have gone the way of the dodo * 
********************************************************/ 

comentarios se aplican ahora si y sólo si es necesario. El código por lo general es un comentario suficiente.

Answer 9

Tuve mucha suerte de trabajar en una empresa importante mientras estaba en la universidad, por lo que ya asistí a mis cursos de desarrollo avanzado con suficiente desilusión.

Yo diría que la principal diferencia con la escuela es la naturaleza de la colaboración y el trabajo distribuido. En proyectos escolares, todos (si pertenecen a su equipo) tienen el mismo interés en el resultado final. En el mundo real, es posible que no conozca bien a las personas con las que está trabajando, y debido a la política, todos tienen un conjunto diferente de prioridades y resultados del mismo proyecto.Por ejemplo, puede ser políticamente beneficioso obtener muchos resultados inmediatos en partes visibles del proyecto, en lugar de garantizar una infraestructura segura a largo plazo.

Answer 10

Terminé sólidamente en el campamento de McConnell después de deshacerme lentamente de un montón de basura que aprendí en la escuela.

Su libro tiene más en buena ingeniería de software de lo que aprendí en la universidad.

Answer 11

Las cosas que nunca te enseñan en la universidad:

• Horarios importan: que no sólo obtener una fecha límite dictada por el cual usted tiene que hacer el viejo intento de la universidad.
• Cada cambio introduce riesgos: los sistemas grandes generalmente tienen suficientes piezas móviles que no puede comprender de inmediato la magnitud completa de cualquier cambio.
• Todo es relativo: "esto debe hacerse" no tiene sentido. Todo, todo, debe hacerse. Toma un número y ponte en línea.

Answer 12

Desde que dejé la universidad/colegio, me he dado cuenta lentamente de que el uso de la herencia y el diseño orientado a objetos clásico no es la respuesta a todos los problemas de diseño.

Mientras sigo intentando escribir clases poco cohesionadas y altamente cohesivas que tienen responsabilidades claras, me parece que casi nunca necesito jerarquías de herencia profunda y, de hecho, a menudo me las arreglo sin heredarlas.

Además, yo solía pensar código necesario para ser escrita de tal manera que es mejor para el compilador/equipo de entender. Ahora escribo código para que otras personas entiendan. Tal vez esto debería haber sido enseñado en mi grado de Ciencias de la Computación, pero no fue así.

Answer 13

he aprendido un montón de cosas que se mencionan en otra parte de este hilo, pero la cosa no veo mencionado todavía es mantenibilidad. Al escribir el código en la universidad, sabes que nunca volverás a usarlo. Solo necesita hacer el trabajo. Al escribir código en el "mundo real", vivirá para siempre. Las herramientas que escribí cuando llegué a este trabajo hace más de 10 años todavía se están utilizando. Mantener el código simple, directo y bien comentado es muy importante.

Answer 14

La necesidad es relativa. A menudo, lo que los usuarios realmente necesitan son herramientas adecuadas a su nivel de sofisticación. En muchos casos, esto significa un lápiz.

Answer 15

La mentalidad de "vaca sagrada" se ha ido. Ahora cuestiono todo y escucho más mis instintos y mi sentido común en lugar de adoptar ciegamente y seguir lo que hacen los demás.

Answer 16

-Simplicidad y facilidad de lectura por encima de todo, su forma de trabajo a través de allí. Rendimiento vienen después

-No reinventar la rueda, sino tratar de entender que lo más profundamente posible. Esto aplica la mayoría de los frameworks más moden disponibles que hacen mucha magia interna.

-Uso tanto la abstracción como sea necesario y no más. Es fácil ir a la ingeniería al límite por cuestiones de ingeniería (consulte muchos de los frameworks empresariales de Apache para Java como ejemplo), pero hay un punto positivo en el que utiliza solo encapsulación y abstracción para transmitir el mensaje y tener un código suficientemente descriptivo.

-El código es para humanos. Dijkstra dice al respecto es conocimiento profundo.

-Hay una herramienta para nada y ninguna herramienta hace todo. El lenguaje y el fanboyismo del IDE son especialmente negativos. Use lo que necesita para hacer el trabajo.