¿Cuáles son los mejores consejos y trucos de programación que has aprendido por tu cuenta por años de codificación?

Answer 1

Realmente no puedo decir que aprendí las siguientes lecciones por mi cuenta. Como dice la famosa cita de Newton “de pie sobre los hombros de gigantes”.

Aprendí estas lecciones trabajando duro, y leyendo todo lo que pude obtener durante los últimos 19 años, 5 años de universidad, 14 años de programación.

Estas lecciones me han servido bien. Ojalá te sean útiles como a mí.

---

Consigue tu mente correcta Obtener buenos conocimientos de programación requiere práctica y estudio, durante muchos años. Lea la publicación de Peter Norvig. Enseñe a usted mismo a programar en diez años.

Iterar El refinamiento sucesivo es cómo conseguimos un gran código y excelentes productos. Al iterar rápidamente, nuestro objetivo es eliminar lo que funciona y lo que no funciona de la manera más rápida y económica posible. Esta es la idea central detrás de The Lean Startup.

Más simple es generalmente mejor . Vea la charla de Rich Hickey Simple Made Easy y lea las Reglas de simplicidad de Kent Beck . Cuando comencé la programación, pensé que mi código era demasiado simple. Como resultado, la simplicidad es una buena calidad de código! Cuando trabajas en grandes bases de código, la simplicidad puede perderse.

Los códigos están escritos principalmente para compañeros de trabajo, no compiladores . La prueba final es que su código es lo suficientemente simple: ¿pueden sus compañeros programadores con antecedentes similares entender su código? Si sus compañeros de trabajo tienen dificultades para entender su código, investigue por qué. Tal vez sea su código que es demasiado complejo. Tal vez no hubo suficientes pruebas. Tal vez usaste un algoritmo poco común. La conversación sobre el código es clave.

Un problema que percibes es un problema que tienes . No estoy seguro de dónde escuché esto, pero se me ha pegado a lo largo de mi carrera. Si ve una ineficiencia, un error, cualquier tipo de problema, es necesario que actúe para rectificarlo. Tal vez agregarlo a una base de datos de errores es suficiente. Tal vez plantear el problema si los compañeros desarrolladores. O tal vez hacer la reparación a ti mismo. Esto se relaciona muy bien con No vivir con ventanas rotas de The Pragmatic Programmer.

No seas listo No intentes escribir código complicado a propósito para mostrar lo inteligente que eres. Escribir código simple, claro, reutilizable. Piensa Simplicidad, Claridad, Generalidad. Lea “La práctica de la programación” por Brian Kernighan y Rob Pike. Hablando de Brian Kernighan, también leyó El lenguaje de programación C de Brian Kernighan y Dennis Ritchie.

Los principios de SRP (principio de responsabilidad única) y DRY (no se repita) avanzan mucho hacia el código limpio. Lea “Código limpio” por el tío Bob Martin (Robert C. Martin)

No lo vas a necesitar ( YAGNI ) se aplica la mayor parte del tiempo. En general, solo se diseña para los requisitos de hoy, para prevenir sobre ingeniería. Dicho esto, a veces es necesario diseñar para el crecimiento futuro. Hay un equilibrio, depende de ti encontrarlo.

El código con obviamente ningún error es inmensamente mejor que el código sin errores obvios.

Ser capaz de razonar acerca de su código es de suma importancia para la alta calidad.

Los requisitos rara vez se convierten en piedra. Como ingeniero / programador, usted tiene la responsabilidad de cuestionar cosas que parecen poco claras, dudosas y cuestionables. A veces, cuando a la gente no le gustan las preguntas, realmente necesita hacer preguntas con mayor atención, aunque posiblemente con una discreción cuidadosa. (Cortesía de Bryan Kelly)

Comience con por qué . Vea la charla de Simon Sinek Cómo los grandes líderes inspiran la acción. ¡Esta es mi charla favorita de todos los tiempos! El mensaje de Simon “la gente no compra lo que haces, compra por qué lo haces ” resuena conmigo. Así que cualquier proyecto en el que trabaje, quiero saber el panorama general. Quiero saber el “por qué”.

Cuando profundizo en un proyecto, puedo perder el enfoque; en esos momentos quiero reflexionar sobre el “por qué” estoy trabajando en este proyecto, por qué este proyecto es importante para el mundo. Eso me da claridad y puedo concentrarme en las tareas que me ayudan a orientarme en la dirección correcta. Sin saber “por qué”, solo estoy volando a ciegas, sin propósito, lo cual es un desperdicio. Saber “por qué” me ayuda a priorizar y me da energía.

Relacionado con el concepto de por qué, muchas veces trabajas para otra persona y es su “por qué” lo que te impulsa. Quizás esté trabajando para un CEO que tenga una visión de cómo el mundo puede ser un lugar mejor. No importa dónde se encuentre en la “cadena de mando”, usted es un líder. Se requiere liderazgo en todos los niveles para que una empresa tenga éxito, incluso para aquellos que no son líderes designados. Recomiendo encarecidamente leer “Extreme Ownership: How US Navy SEALs Lead and Win”. Esto se relaciona con “Comience con por qué” porque si no entiende “Por qué” o no está de acuerdo con los líderes que están por encima de usted, es su responsabilidad averiguar los líderes “Por qué” . ¿Cómo puedes guiar a otros si no entiendes por qué?

Mi segunda charla favorita de todos los tiempos es Inventing on Principle de Bret Victor. Esta charla se enlaza con “Comenzar con por qué” en mi mente. Bret habla sobre su principio rector “Los creadores necesitan una conexión inmediata con lo que crean”. Este principio sirve como una guía para todo lo que Bret hace. Esta es una charla de 3 partes, y la parte 3 es quizás la más importante. Es una sola pregunta ” ¿Cuál es su principio guía? “Para mí, esto está relacionado con la charla de Simon Sinek” Empieza con por qué “, ya que” Por qué “de Simon es muy similar al” Principio de guía “de Bret.

Creo que una de las razones por las que estamos aquí en esta tierra es para descubrir nuestro por qué. Y para hacer eso, creo que necesitamos conocernos a nosotros mismos. Conocer nuestro principio rector. Es algo muy profundo.

Los clientes realmente no saben lo que quieren , y eso incluye a su gerente. Es su trabajo para obtener sus verdaderas necesidades.

A pesar del proceso que siga, se requiere cierta cantidad de diseño inicial : cuánto debe ser proporcional a la complejidad. Lea “Diseño impulsado por dominio” por Eric Evans .

Los patrones de diseño no se utilizan tanto como se podría pensar. Reconocer patrones comunes es importante. No trate los patrones como un martillo buscando un clavo. Lea “Refactoring to Patterns” por Joshua Kerievsky . Lea la respuesta de Steven Grimm a ¿Cuáles son los patrones de diseño más importantes que los ingenieros de software deben saber para trabajar en Google, Amazon y Facebook?

Los principios SÓLIDOS (Principio de Responsabilidad Única, Principio Abierto / Cerrado, Principio de Sustitución de Liskov, Principio de Segregación de Interfaz, Principio de Inversión de Dependencia) son mucho más importantes que los patrones de diseño. Lea el artículo de tío Bob Principios de OOD

Cuidado con el dogma . Generalmente hay más de una forma de hacer las cosas. El término “mejor práctica” está sobreutilizado. Existen algunas buenas prácticas en el desarrollo de software, pero tenga cuidado de que alguien le diga que algo es la “mejor” forma de hacer algo.

Nadie lo tiene todo resuelto . Algunos saben más que otros. Siempre trata de ser el peor miembro de la banda. Lea “El programador apasionado” por Chad Fowler .

Vea la charla de Barbara Liskov “El poder de la abstracción” http://www.infoq.com/presentatio…. Muchas veces he visto a los desarrolladores crear abstracciones sin sentido.

La peor abstracción que he visto es una clase de Java llamada BeanFacade. Este nombre de clase se derivó al juntar el concepto de un Java Bean con el patrón de Fachada. En Java, esto es algo común: concatenar nombres para formar nombres nuevos. Pero la abstracción resultante no tiene sentido. Bien podría haber sido nombrado X, o FooBar. Ten cuidado con las abstracciones que dejas en tus bases de código. Si estás luchando para nombrar cosas, quizás no tienes la abstracción correcta.

En mi opinión, el libro Dominio del diseño de Eric Evan trata sobre la elección de las abstracciones apropiadas y la evolución adecuada a lo largo del tiempo.

No hay tal cosa como perfecto . Siempre puedes ser mejor. “Lo perfecto es el enemigo de lo bueno” – Voltaire.

Si no diseñas para escalabilidad, tu código no se escalará. Si no diseñas por seguridad, tu código no será seguro. Lo mismo se aplica para todos los servicios.

Tú no eres tu código . La crítica de tu código no es una crítica de ti.

Recuerda, es un deporte de equipo. Los grandes productos son construidos por equipos. Lea el libro “5 disfunciones de un equipo” de Patrick Lencioni, o vea su charla sobre el libro. Es un gran libro sobre cómo funcionan los grandes equipos.

No te quedes a oscuras . Comparte tu trabajo sin terminar con otros de buena gana. Lea “Dinámicas de desarrollo de software” por Jim McCarthy

Pon a prueba tu trabajo . Intenta escribir pruebas antes de codificar. Pruebe TDD. Prueba la BDD. Lea “Trabajando efectivamente con el código legado” por Michael Feathers .

Aprende múltiples paradigmas. OOP , Funcional , etc. Su código OO mejorará después de estudiar lenguajes funcionales como Haskell y Lisp .

Vea la nota de apertura de OOPSLA 97 por Alan Kay , “La revolución de la computadora todavía no ha sucedido”.

Nunca dejes de aprender . Lee tantos libros como puedas, pero no solo libros técnicos. Lea “Zen y el arte del mantenimiento de la motocicleta” por Robert M. Pirsig .

Lea “El programador pragmático” por Andy Hunt y Dave Thomas .

Lea “Code Complete 2” por Steve McConnell

Leer SICP (Estructura e Interpretación de Programas de Computación) por Harold Abelson, Gerald Jay Sussman y Julie Sussman. No se limite a leerlo de principio a fin. Siga junto con un entorno Scheme (p. Ej., Racket) y escriba un código.

No pida permiso para refactorizar, probar, documentar, etc. Es todo parte de la “programación”. No pidas permiso para hacer tu trabajo.

Cuida tu trabajo. Cuida a tus clientes. El código que escribimos permite a los usuarios de nuestro código hacer su trabajo, sin que nuestro software se interponga en su camino.

Siempre pregunte “¿Qué problema estoy tratando de resolver”? Esta es una gran pregunta para hacer para aclarar qué es exactamente lo que está haciendo. Te ayuda a enfocarte. Esto se relaciona muy bien con ” Start With Why ” de Simon Sinke.

En general, apéguese a resolver un problema a la vez . Cuando detecte otros problemas, anótelos y vuelva a ellos más tarde.

Estar donde estas Esta es una lección de vida que se aplica al desarrollo de software. Cuando te comprometes a hacer algo, enfócate en hacerlo. Cuando lave los platos, concéntrese en lavarlos; olvídese de todas las cosas que lo estresaron ese día. Si está pasando tiempo con su familia, permanezca allí, apague su teléfono, olvide ese problema difícil con el que ha estado luchando. Cuando estés en una reunión, participa: concéntrate en la conversación y olvídate del trabajo que se está acumulando. Lee “Zen Mind, Beginner’s Mind” por Shunryu Suzuki

SRP tiene aplicaciones más amplias que solo para codificar.

“La optimización prematura es la raíz de todo mal” – Donald Knuth . Comience con un algoritmo de fuerza bruta hasta que encuentre una razón para cambiar.

Pregunte “¿qué es lo más simple que puede funcionar?” Lea “Explicación de la programación eXtreme” por Kent Beck . La primera versión es supuestamente más extrema que la segunda.

Estar bien contigo Nunca lo sabrás todo, eso es imposible. Sigue aprendiendo, pero no te metas en lo que no sabes. Mira la charla de Kent Beck Facilidad en el trabajo.

Para mí, la charla de Kent fue un soplo de aire fresco. He sido desarrollador durante más de una década y media, y en ocasiones me atasca la idea de que la gente más joven ya sabe las cosas que sé y más, y soy un desarrollador viejo y bien pagado. Este no es el caso (espero), pero este pensamiento me impulsa a aprender continuamente para no quedarme atrás. La charla de Kent es genial porque te ayuda a recordar que está bien donde estás. Incluso si hay un prodigio adolescente que puede codificar círculos a tu alrededor, en general eso es atípico. Nunca soy complaciente, pero ¿qué tan fuerte debo empujar para mantenerme al día?

Se humilde Todos están en diferentes puntos de aprendizaje en su carrera. Ayuda a otros en su camino. Pide ayuda cuando la necesites. Devolver a la comunidad. Vea la charla de Leon Gersing “Verdad, mito y realidad en el desarrollo de software”

Realmente disfruté la charla de Leon. Escribe “Hello World” en un nuevo idioma, luego bórralo. La comparación con otros desarrolladores ayuda a comprender de dónde vienen y te ayuda a que te comprendas a ti mismo.

También me gusta la charla de Leon porque une la programación con el Zen, ambos temas me parecen intrigantes. Comprender exactamente qué es el “Zen” es una curva mental, que termina en un lugar donde el Zen es todo y el Zen no es nada. Y un viejo maestro zen golpea a un estudiante, y el estudiante finalmente “entiendes” … o no.

Para mí, estoy aquí para averiguar por qué estoy aquí. Me gusta “codificar”. ¿Cómo ayuda eso a que el mundo sea un lugar mejor? ¿Quién soy yo, de verdad? ¿Puedo encontrar un significado estudiando zen? ¿Taoísmo? No sé si alguna vez sabré el significado de la vida, pero nunca dejaré de buscar.

Está bien ser normal – Lea el artículo Elogiando al desarrollador promedio – Por qué el mito del programador “10x” es tan destructivo por Matt Asay. Matt Asay hace referencia al discurso de Jacob Kaplan-Moss en PyCon 2015.

La multitarea es una ilusión. Las computadoras se salen con la suya porque pueden cambiar de contexto muy rápido (la mayoría de las veces). El cambio de contexto para nosotros, simples mortales, tiene un alto costo. Haz una cosa a la vez, y hazlo bien.

9 mujeres no pueden tener un bebé en un mes. Lee “El mes del hombre mítico” por Fred Brooks .

No hay cuchara. Sólo un recordatorio para aligerar un poco. Que te diviertas.

Answer 2

Comencé a programar, hace solo unos meses … Esto es lo que encontré que me ayudó a aprenderlo más rápido, no me malinterprete, no soy un profesional ni nada, pero estoy mejorando en eso. Aquí hay algunos consejos. para aquellos que recién comenzaron a codificar … o aprender a codificar

• No entenderás mucho al principio, dale algo de tiempo. Tomará tiempo entender todo lo que está mirando / leyendo, así que no se dé por vencido.
• Aprende bien lo básico. Concéntrese tanto como pueda en los principios básicos, las definiciones, el uso de los signos de puntuación, etc.
• Asegúrese de que esté aprendiendo sobre codificación / programación en general ANTES de elegir un idioma. Sepa para qué se usa la codificación, cómo funciona, cómo la traduce la computadora, etc.
• Si conoce a alguien que sabe cómo codificar, pregúntele si estaba bien para resolver un problema que se encuentra frente a usted. Solo para que puedas tener una idea más general de cómo funciona todo.
• ¡Práctica práctica práctica! Practica tanto como puedas, codifica y lee el código de otras personas, mira videos de personas codificando. Aprenderás más de lo que crees que lo harás.
• Asegúrese de que todo lo que esté haciendo se base en su nivel de conocimiento. No leas algo que no entiendes, si es demasiado difícil entonces ve a lo más básico, está bien … Dale un tiempo y los entenderás a los dos lo suficientemente pronto.
• Una cosa que me ayuda mucho es la codificación divertida . Solo codificando cosas tontas (imagen de google, ahora obtuve la fuente. ¿Cuál es el mejor comentario en el código fuente que haya encontrado?) Cualquier cosa como la imagen a continuación lo ayudará en general.

• Aprende de los cursos que están hechos para niños. ¡Mucho más fácil y mucho más divertido! ¡Créeme!

Aquí hay algunos consejos en general …

• Hazlo tan fácil y tan comprensible como sea posible. Presumir aquí no funcionará, confía en mí. Incluso si eres un profesional, no importa. No presumir En su lugar, agregue más comentarios, haga que sea fácil de leer y entender. Haz que sea lo suficientemente comprensible que incluso un principiante pueda saber lo que estás haciendo.
• Asegúrate de que tus fundamentos estén todos establecidos. En otras palabras, pruebe sus conceptos antes de comenzar cualquier otra cosa .
• Elija el idioma usted mismo, no permita que nadie lo elija por usted. Si no tiene idea de cuál debe elegir, solo pregunte y vea los diferentes tipos y luego investigue y vea si le resulta atractivo o no.
• Aprende la diferencia entre los programas. Solo los más populares, solo asegúrese de que cuando vea un código sepa a qué lenguaje de programación pertenece.
• Escriba lo que desea y haga un plan antes de hacerlo, tenga una lista de verificación . Ayuda más de lo que crees cuando estás empezando.
• Hazlo poco a poco. Recuerde probarlo cada tanto, es mucho mejor y más fácil (tal vez un poco más lento) que no hacerlo hasta el final.
• Entiende el problema y luego empieza a resolverlo. Dedica la mayor parte de tu tiempo a comprender el problema antes de hacer cualquier otra cosa. Una vez que entiendas que el resto será fácil, así que no te apresures, no es una competencia.
• No asumas que eres mejor que nadie solo porque sabes cómo codificar. Muchos se pierden este punto, piensan que de repente son genios solo por saberlo, no importa si son buenos o malos. Pero ellos simplemente ‘saben’ …

Espero que esto haya ayudado

Answer 3

Desde lo alto de mi cabeza (después de 37 años de programación), siete ideas que son más filosofía que “trucos”:

1. Comprender el contexto del código requerido. Las tácticas son fáciles, la estrategia es difícil, pero toda la codificación no trivial eventualmente se reduce a una buena estrategia. La mayoría de los proyectos importantes dependen de obtener aproximadamente diez elecciones iniciales correctas y fracasan porque al menos una de estas se pasó por alto.
2. ” Prueba un poco, codifica un poco “. Inicialmente, este enfoque es completamente contraintuitivo, pero si puede juntar el tiempo para probar, fallar, escribir el diagnóstico, tener éxito y repetir, está en una buena situación ya que no solo ha aceptado los errores (en lugar de ignorarlos). ellos) pero tienen un conjunto de prueba para las modificaciones posteriores.
3. Mantenlo tan simple como puedas . Luego aprende a simplificar aún más. No hay un proyecto de un millón de líneas que no se pueda escribir más claramente en menos del 10% del código. Ninguna. (Los programadores J lo entenderán a medias).
4. Entender la máquina . Si su “Hola mundo” ocupa 20k, intente escribirlo en 20 bytes, solo por diversión. Las capas de abstracción son excelentes en el 95% de los casos y lo paralizan el resto del tiempo. Los ingenieros saben esto, los graduados de CS en su mayoría no lo hacen. (He visto 300Meg de código donde 100k haría).
5. Documento obsesivamente bien. Esto generalmente no implica documentación muy larga. Encuentra nuevas formas de documentar mejor. En última instancia, la mayoría del software está paralizado por su documentación incoherente.
6. Aprender varios idiomas. Luego harás preguntas inteligentes como “¿Cómo se debe hacer?” y no “¿Cómo se puede hacer en el lenguaje OO que conozco?” También aprendes a detectar BS.
7. La programadora más afortunada en el mundo es ella que pierde todo su código justo cuando termina el programa. !

Ah, y evitar “cortar y pegar”. Siempre te arrepentirás.

Jo (experto en nada).

Answer 4

Cuida tu artesanía
¿Por qué gastar tu vida desarrollando software a menos que te importe hacerlo bien?

Proporcionar opciones, no hacer excusas cojo
En lugar de excusas, proporcionar opciones. No digas que no se puede hacer; explicar que se puede hacer

Ser un catalizador para el cambio
No se puede forzar el cambio en las personas. En su lugar, muéstrales cómo podría ser el futuro y ayúdalos a participar en su creación.

Hacer que la calidad sea un problema
Involucre a sus usuarios en la determinación de los requisitos de calidad reales del proyecto.

Analiza críticamente lo que lees y escuchas
No te dejes llevar por los vendedores, las exageraciones de los medios o el dogma. Analizar la información en términos de usted y su proyecto.

SECO: no se repita
Cada conocimiento debe tener una representación única, inequívoca y autorizada dentro de un sistema.

Eliminar efectos entre cosas no relacionadas
Diseñe componentes que sean autónomos, independientes y tengan un propósito único y bien definido.

Usa las balas Tracer para encontrar el objetivo
Las balas trazadoras le permiten concentrarse en su objetivo probando cosas y viendo qué tan cerca aterrizan.

Programa cercano al dominio del problema
Diseñe y codifique en el idioma de su usuario.

Iterar el horario con el código
Use la experiencia que obtiene a medida que la implementa para refinar las escalas de tiempo del proyecto.

Usa el Poder de las Cáscaras de Mando
Utilice el shell cuando las interfaces gráficas de usuario no lo corte.

Utilice siempre el control de código fuente
El control de código fuente es una máquina del tiempo para su trabajo, puede regresar.

No se asuste al depurar
¡Respira hondo y PIENSA! sobre lo que podría estar causando el error.

No lo asumas, pruébalo
Demuestre sus suposiciones en el entorno real, con datos reales y condiciones de contorno.

Escribir código que escribe código
Los generadores de código aumentan su productividad y ayudan a evitar la duplicación.

Diseño con Contratos.
Utilice los contratos para documentar y verificar que el código no hace ni más ni menos de lo que dice hacer.

Use aserciones para prevenir lo imposible
Las aserciones validan tus suposiciones. Úsalos para proteger tu código de un mundo incierto.

Termina lo que empiezas
Cuando sea posible, la rutina u objeto que asigna un recurso debe ser responsable de desasignarlo.

Configurar, No Integrar
Implemente opciones de tecnología para una aplicación como opciones de configuración, no a través de integración o ingeniería.

Analizar el flujo de trabajo para mejorar la concurrencia
Aproveche la concurrencia en el flujo de trabajo de su usuario.

Siempre diseño para concurrencia
Permita la concurrencia, y diseñará interfaces más limpias con menos suposiciones.

Usa pizarras para coordinar el flujo de trabajo
Use pizarras para coordinar hechos y agentes dispares, mientras mantiene la independencia y el aislamiento entre los participantes.

Calcula el orden de tus algoritmos
Obtener una idea de cuánto tiempo es probable que las cosas tomen antes de escribir el código.

Refactor temprano, refactor a menudo
Del mismo modo que puede eliminar y reorganizar un jardín, reescribir, volver a trabajar y volver a diseñar el código cuando lo necesite. Arregla la raíz del problema.

Pruebe su software, o sus usuarios lo harán
Prueba despiadadamente. No hagas que tus usuarios encuentren errores para ti.

No reúna los requisitos, excave por ellos
Los requisitos rara vez se encuentran en la superficie. Están enterrados profundamente bajo capas de suposiciones, conceptos erróneos y política.

Las abstracciones viven más que los detalles
Invertir en la abstracción, no en la implementación. Las abstracciones pueden sobrevivir a la avalancha de cambios de diferentes implementaciones y nuevas tecnologías.

No pienses fuera de la caja: encuentra la caja
Cuando se enfrente a un problema imposible, identifique las restricciones reales. Pregúntate a ti mismo: “¿Hay que hacerlo de esta manera? ¿Tiene que hacerse?

Algunas cosas se hacen mejor de lo que se describe
No caigas en la espiral de especificaciones: en algún momento necesitas comenzar a codificar.

Las herramientas costosas no producen mejores diseños
Tenga cuidado con las exageraciones del vendedor, el dogma de la industria y el aura de la etiqueta de precio. Juzgar herramientas sobre sus méritos.

No utilice procedimientos manuales
Un script de shell o un archivo por lotes ejecutará las mismas instrucciones, en el mismo orden, una y otra vez.

La codificación no se realiza hasta que se ejecutan todas las pruebas
‘Nuff dijo.

Prueba de cobertura estatal, no cobertura de código
Identificar y probar estados significativos del programa. Solo probar líneas de código no es suficiente.

El inglés es solo un lenguaje de programación
Escriba los documentos como lo haría con el código: respete el principio DRY, use metadatos, MVC, generación automática, etc.

Superar suavemente las expectativas de sus usuarios
Llegue a comprender las expectativas de sus usuarios y luego ofrezca un poquito más.

¡Pensar! Sobre tu trabajo
Apaga el piloto automático y toma el control. Constantemente critique y valore su trabajo.

No vivas con ventanas rotas
Repare los malos diseños, las decisiones erróneas y el código incorrecto cuando los vea.

Recuerda el panorama general
No se absorba tanto en los detalles que se olvida de revisar lo que sucede a su alrededor.

Invierta regularmente en su cartera de conocimientos
Hacer del aprendizaje un hábito.

Es tanto lo que dices como la forma en que lo dices.
No tiene sentido tener grandes ideas si no las comunica de manera efectiva.

Hazlo fácil de reutilizar
Si es fácil de reutilizar, la gente lo hará. Crea un entorno que soporte la reutilización.

No hay decisiones finales
Ninguna decisión es lanzada en piedra. En su lugar, considera que cada uno está escrito en la arena de la playa y planifica el cambio.

Prototipo para aprender
La creación de prototipos es una experiencia de aprendizaje. Su valor no radica en el código que produce, sino en las lecciones que aprende.

Estimar para evitar sorpresas
Estimar antes de empezar. Vas a detectar posibles problemas en la delantera.

Mantener el conocimiento en texto sin formato
El texto plano no se volverá obsoleto. Ayuda a aprovechar su trabajo y simplifica la depuración y la prueba.

Use un solo editor bien
El editor debe ser una extensión de tu mano; asegúrese de que su editor sea configurable, extensible y programable.

Arregla el problema, no la culpa
Realmente no importa si el error es culpa suya o de otra persona, sigue siendo su problema y aún debe solucionarse.

“Seleccionar” no está roto
Es raro encontrar un error en el sistema operativo o el compilador, o incluso en un producto o biblioteca de terceros. El error es más probable en la aplicación.

Aprender un lenguaje de manipulación de texto
Pasas una gran parte de cada día trabajando con texto. ¿Por qué no hacer que la computadora haga algo por ti?

No puedes escribir software perfecto
El software no puede ser perfecto. Protege tu código y usuarios de los inevitables errores.

Crash Early
Un programa muerto normalmente hace mucho menos daño que uno lisiado.

Utilice excepciones para problemas excepcionales
Las excepciones pueden sufrir todos los problemas de legibilidad y mantenimiento del código de espagueti clásico. Reservar excepciones para cosas excepcionales.

Minimizar el acoplamiento entre módulos
Evite el acoplamiento escribiendo el código “tímido” y aplicando la Ley de Demeter.

Poner abstracciones en código, detalles en metadatos
Programa para el caso general, y coloque los detalles fuera de la base de código compilado.

Diseño usando servicios
Diseñe en términos de servicios: objetos independientes y concurrentes detrás de interfaces bien definidas y consistentes.

Vistas separadas de los modelos
Gane flexibilidad a bajo costo diseñando su aplicación en términos de modelos y vistas.

No programa por coincidencia
Confíe solo en cosas confiables. Tenga cuidado con la complejidad accidental y no confunda una feliz coincidencia con un plan determinado.

Pon a prueba tus estimaciones
El análisis matemático de los algoritmos no te dice todo. Intente cronometrar su código en su entorno objetivo.

Diseño a prueba
Comience a pensar en las pruebas antes de escribir una línea de código.

No uses el código de asistente que no entiendes
Los asistentes pueden generar resmas de código. Asegúrese de entenderlo todo antes de incorporarlo a su proyecto.

Trabaja con un usuario para pensar como un usuario
Es la mejor manera de comprender cómo se utilizará realmente el sistema.

Usa un glosario de proyectos
Cree y mantenga una fuente única de todos los términos y vocabulario específicos para un proyecto.

Comience cuando esté listo
Has estado construyendo experiencia toda tu vida. No ignores las pequeñas dudas.

No seas esclavo de los métodos formales
No adopte ciegamente ninguna técnica sin ponerla en el contexto de sus prácticas y capacidades de desarrollo.

Organizar equipos en torno a la funcionalidad
No separe a los diseñadores de los programadores, a los probadores de los modeladores de datos. Construye equipos de la forma en que construyes el código.

Prueba temprana. Prueba a menudo. Prueba Automáticamente.
Las pruebas que se ejecutan con cada compilación son mucho más efectivas que los planes de prueba que se encuentran en un estante.

Usa saboteadores para probar tus pruebas
Introduzca errores a propósito en una copia separada de la fuente para verificar que las pruebas los detecten.

Encuentra errores una vez
Una vez que un probador humano encuentra un error, debe ser la última vez que un probador humano encuentra ese error. Las pruebas automáticas deben comprobarlo a partir de entonces.

Construir documentación en, no atornillarlo
Es menos probable que la documentación creada por separado del código sea correcta y esté actualizada.

Firma tu trabajo
Los artesanos de una edad temprana estaban orgullosos de firmar su trabajo. Usted debe ser, también.

Fuente: El estante pragmático | Lista de consejos

Answer 5

Tiendo a enmarcar la lógica primero y luego completar el código más tarde, te ayuda a evitar que olvides las cosas. Me gusta

if (openFile () == false) {
zzzzz; // manejar el error de abrir archivo
} else {
zzzzz; // procesar el archivo
}

Este es un caso simple pero ilustra lo que quiero decir. Probablemente estoy pensando en qué hacer con el archivo abierto, así que en lugar de cambiar de marcha mentalmente, coloco un marcador de posición para el manejo de errores y me aseguro de volver a él más tarde.

Tenga en cuenta que “zzzzz;” es literal No se compilará, y en muchos IDE aparece como una marca roja en el margen. Eso es a propósito, para asegurarme de que no intente probar el código que está incompleto. Pongo el punto y coma en el final porque eso ayuda al IDE a analizar el código, de modo que el código después de él tenga el resaltado de sintaxis correcto y señales sensibles al contexto.

No verifique el código de esta manera. Romper la construcción es malo. Si tiene que registrarse, generalmente cambio el código como:
// TODO zzzzz maneja el error de abrir archivo

El “zzzzz” es mi signo universal de volver a algo ahora, pero la TODO es reconocida por todos los desarrolladores (y la mayoría de los IDE) como un trabajo pendiente para terminar. También tenga en cuenta que uso zzzzz porque no es probable que se identifique de forma real, esté representado en texto significativo y sea fácil de escribir (esquina inferior izquierda del teclado).

Answer 6

Comencé a codificar hace aproximadamente 2 años, comencé con el lenguaje C y ahora practiqué java (creé varios proyectos). Aquí me mostré la codificación y lo que aprendí de mis años:

La codificación es arte:

Me encanta tocar la guitarra mientras estaba aprendiendo a tocarla, recordar acordes y mover los dedos de los trastes fue bastante difícil para mí. Un día, mientras intentaba mover mis dedos de los trastes, algo me golpeó. La codificación es similar a tocar la guitarra, ¿recuerdas? la sintaxis, las palabras clave, las reglas y el desarrollo de algo según su lógica y su tormenta de ideas, también recuerda los acordes, comprende la melodía y crea algo por su cuenta.

La codificación tiene que ver con la creatividad:

Cuando practicas código, frustrado debido a errores, pasa horas y horas intentando resolverlos, pero luego te das cuenta de que simplemente te perdiste un punto y coma, tu programa se ejecuta, la sonrisa en tu cara, la maldita voz. de tu garganta dice ” si” lo hiciste!

Si eres creativo, pasas tiempo jugando con tu código, ¡entonces el éxito es tuyo!

Tienes herramientas, úsalas sabiamente:

Cuando comienza a aprender el código, comienza con lo básico, el conjunto de reglas, la sintaxis, las palabras clave en ese idioma en particular, las técnicas, etc. Todas estas cosas son herramientas que le proporcionamos ahora y depende de usted usarlas con sensatez.

Práctica:

Comencé a codificar con C, luego continué con C ++ y ahora java, todo desde ellos, java ha sido el más difícil porque comencé a codificar en el bloc de notas, una pantalla en blanco y lo compilé usando cmd al pasar comandos y eso fue complejo y tomó mucho tiempo. escriba código y vuelva a cmd, presione los comandos y vea la lista inesperada de errores, pero la práctica me salvó.

Mantente en el flujo:

Si la codificación depende de su estado de ánimo, entonces no va a funcionar porque necesita estar en el flujo para poder aprovecharla al máximo. Practique todos los días, aprenda a usar una nueva herramienta cada día y luego cree algo nuevo, algo diferente.

¡Espero eso ayude!

Answer 7

Algunos consejos de diseño que realmente han valido la pena para mí:

• La prueba más simple es mejor que ninguna prueba en absoluto. Algo tan simple como afirmar que su función no se puede lanzar aún puede atrapar toneladas de errores durante el desarrollo. No debe usar esto como una excusa para no escribir buenas pruebas, pero si ya ha pasado la fecha límite y necesita reducir los recortes, debe considerar dedicar unos minutos para al menos escribir algunas pruebas.
• Utilice el sistema de tipos para hacer que los errores sean imposibles o improbables. Los tipos de cosas pueden hacer por ti:

• Mantenga un registro de la entrada validada frente a la no validada, creando un tipo separado para la entrada validada. El tipo validado es devuelto por una función que realiza la validación. Las funciones que esperan una entrada validada deben requerir ese tipo para sus argumentos.
• Unidades (días, pulgadas, metros, etc) de valores numéricos. Vea, por ejemplo, cómo Scott Meyers usa tipos en el constructor de fecha para cometer errores: ¿la guía de diseño más importante?
• Administre correctamente la vida útil de los objetos (por ejemplo, punteros inteligentes en C ++, RAII)
• Exigir el manejo de errores (por ejemplo, boost :: opcional y construcciones similares en muchos idiomas)

• Prefiere la composición en lugar de la herencia. Se han escrito muchos artículos sobre esta guía, no necesito dar un resumen. Sin embargo, mucho código en la naturaleza todavía se basa en la herencia cuando podría estar utilizando la composición. Mi experiencia ha sido que las arquitecturas basadas en composición son, literalmente, más productivas que las arquitecturas basadas en herencia.

Un par de trucos que encontré sorprendentes que pueden dar enormes ganancias de rendimiento:

• El diseño de la memoria es muy importante. Por ejemplo, si está multiplicando dos matrices juntas, su algoritmo será mucho más rápido si transpone la segunda matriz antes de continuar. Esto se debe a que hará que se pueda acceder a la segunda matriz en orden secuencial en lugar de a modo de paso (las lecturas de la memoria pueden ser mucho más rápidas para el acceso secuencial), y facilita el uso de las instrucciones vectoriales de CPU.
• La división puede ser 20 veces más lenta que la multiplicación (según la cantidad de multiplicaciones). Si necesitas el recíproco de 4 números, estarás mejor con

  temp = 1 / (x1 * x2 * x3 * x4);
  y1 = temp * x2 * x3 * x4;
  y2 = temp * x1 * x3 * x4;
  etc

  que hacer cuatro divisiones (pero ten cuidado con las NAN, las INF o los ceros).

Answer 8

Aquí está mi lista de los 10 mejores:

1. Su código debe ser legible. Si tiene que confiar en la documentación para explicar su código fuente, podría haberlo hecho demasiado complejo. Si su compañero no puede entender su código simplemente leyéndolo, es probable que deba volver a factorizarlo o reescribirlo.

2. Nadie amará tu código, por muy hermoso que sea. Además, odiarás el código de todos los demás. De hecho, es probable que odie su propio código si tiene que volver a trabajar en él.

3. No seas demasiado paranoico con los estándares de codificación o una forma particular de escribir código. Diferentes personas provienen de diferentes culturas, hablan diferentes idiomas e interactúan de manera diferente, de igual manera tienen diferentes estilos de escritura de código, lo respetan

4. Comprenda qué es la “complejidad ciclomática”, le ayudará a escribir código menos complejo

5. Escriba el código en unidades más pequeñas y pruebe cada unidad individual

6. Tenga un diseño / diseño / plan / algoritmo listo antes de escribir el código

7. Comprenda los detalles de implementación subyacentes y el funcionamiento de su lenguaje de programación. Esto lo ayudará a evitar costosos errores de programación y evitará que dedique tiempo a optimizaciones injustificadas

8. Conozca su entorno de ejecución y asegúrese de probar su código en un entorno representativo; especialmente cuando se trata de concurrencia

9. Haga una prueba rápida de concepto antes de escribir código complejo

10. Asegúrese de que está escribiendo su código contra los requisitos de sw válidos y claramente explicados. Los requisitos pueden venir en forma de: diagramas arquitectónicos, explicación algorítmica, maqueta de la pantalla, optimización del rendimiento, defecto en el código SW, prototipo de trabajo, etc. Sea cual sea la forma en que haya llegado el requisito, asegúrese de que el alcance sea bien comprendido, claramente definido y acordado por tu y el cliente

Answer 9

Dado que la mayor parte de mi viaje de programación profesional ha sido freelance, mi respuesta se aplicará principalmente a los freelancers.

1) Mantenlo simple
Pase una hora planeando con anticipación para ahorrar innumerables horas de frustración, dolores de cabeza y fracaso.

2) PRUEBA!
Siempre prueba tu código. Si no tienes pruebas, tu código está roto, casi siempre hay algo que no estás notando que está roto.

2) Los clientes no saben lo que quieren.
Como profesional independiente, tengo una cláusula en mi contrato de que soy un contratista independiente y escucharé a mis clientes, pero luego decidiré cuál es la mejor ruta de acción.

3) Nunca confíes en la gente
Tener un contrato si es freelance.

4) Nunca trabaje gratis, y siempre nombre su precio
Los clientes para los que trabaja sin pago son realmente los clientes más necesitados que esperan el mundo de usted, y por qué no lo hacen, usted está trabajando para ellos de forma gratuita, por lo que desean mantenerlo atado el mayor tiempo posible. También nombre su precio, para evitar decepciones, nunca deje que el cliente “decida cuánto vale”. Ya sabes cuánto vales, cárgalos en consecuencia.

5) red
Ir a conferencias, y reuniones. Conoce a otros desarrolladores con intereses similares. Algunas veces solo haces nuevos amigos y otras veces conoces a personas extremadamente valiosas que pueden saber más que tú y están dispuestas a guiarte, o pueden ayudarte a conseguir el trabajo dulce que siempre quisiste, o si trabajas por cuenta propia, pueden tener un montón de desbordamiento de clientes para referirse a usted. En la mayoría de los casos, la creación de redes es una gran victoria para un desarrollador profesional.

6) Comparte tu conocimiento
Tener un blog, enseñar, compartir fragmentos o ejemplos de código. Discuta un pedazo de código con otros. Al compartir, muchas veces aprendes un montón de cosas interesantes por tu cuenta, puedes hacer una investigación más profunda antes de escribir una entrada de blog, por lo que siempre aprenderás algo nuevo. Escribe publicaciones de blog de invitados, etc.

7) Continuar aprendiendo
He visto a varios desarrolladores desarrolladores perder sus trabajos y no pudieron encontrar otro trabajo durante meses porque se enfocaron demasiado en un lenguaje agonizante y no sabían nada más. Siempre agregue algo nuevo a su cinturón de herramientas, no intente dominar todo, pero al menos lea sobre nuevos lenguajes y marcos, y sepa cómo funcionan, qué problemas resuelven, etc.

Answer 10

Oh mucho !!

• La legibilidad es el camino hacia proyectos más interesantes dentro de una carrera.
• La legibilidad es el camino para saber lo que escribió hace 5 años y hace que la reutilización del código sea realmente viable.
• La legibilidad es el camino hacia la adquisición de protegidos que pueden aprender de su estilo.
• La legibilidad que es comprensible para otros permite que las personas aprecien su código en un nivel de arquitectura, no solo funcional.
• La legibilidad es el camino de la resistencia al arrendamiento cuando tiene un error en su código.
• La legibilidad es la forma en que se ponen las ideas en un texto y una sintaxis comprensibles, de manera muy similar a escribir un párrafo en lenguaje natural.
• La capacidad de lectura no es de ninguna manera una prioridad para la mayoría de los otros desarrolladores, sin embargo, es probable que sea bastante importante para su director de desarrollo, si trabaja para uno.
• La legibilidad es más importante de lo que la mayoría cree. Con la ley de Moore, es aún más importante centrarse en la legibilidad que en la optimización prematura.

Aquí hay más:

• La mayoría de las escuelas y colegios enseñan ciencias de la computación como las habilidades de la escuela de comercio. Cómo arreglar un coche. Cómo ser un asistente dental. Cómo ser un administrador.
• La mayoría de las escuelas y universidades no se dan cuenta de que hay una diferencia entre Informática y Programación. Estos son diferentes
• La mayoría de las personas que solicitan trabajo en California son programadores, cuando el trabajo realmente requiere un científico informático.
• La mayoría de las personas solo conocen uno o tres lenguajes de programación. Personalmente, creo que necesitas saber entre 7 y 8 de ellos para dominar realmente la idea de la programación.

¿Psicología sabia?

• La mayoría de los programadores son muy inseguros con respecto a sus habilidades de programación y terminan en debates sobre qué lenguaje de programación es mejor.
• Después de eso, la mayoría no se da cuenta de que cada lenguaje de programación es solo una herramienta que es mejor en algo, mientras que otro es mejor en otra cosa … Como hablar español mientras está en España, o saber chino en el centro de China. Herramientas adecuadas para el trabajo.
• La mayoría de los programadores están acostumbrados a simplemente buscar en Google, así es como se les enseñó.
• La mayoría de los programadores inseguros deliran acerca de cuán “compacto” es su código. Que sirve muy poco propósito en lenguajes compilados.
• La mayoría de los programadores inseguros se enfocan en el hipertintonizar algunas líneas de código. Los buenos programadores se centran en entregar software funcional y utilizable.

Hábitos….

• La mayoría de los programadores siguen la sintaxis y la estructura del estilo que se les enseñó. Muy pocos cuestionan el estilo que les enseñaron. Los ejemplos son {‘s en la línea if-statement, o en la siguiente línea alineada verticalmente con la}.
• La mayoría de los programadores no hacen diagramas antes de comenzar a experimentar. Muchos simplemente copian algún ejemplo existente y comienzan sus modificaciones desde allí (lo que corre el riesgo de adoptar errores de los ejemplos existentes).
• La mayoría de los programadores no hacen una prueba de unidad. Ellos creen que son mejores que eso, o son perezosos.
• La mayoría de los programadores leen xkcd.
• Los programadores que son informáticos son mejores en problemas computacionales.

Lo que la mayoría no se da cuenta de la informática (a diferencia de la programación).

• Usted puede combinar ordenar sus calcetines.
• Puede aplicar métodos de escalabilidad de algoritmos a los procesos de nivel de trabajo laboral para mejorar la eficiencia del negocio.
• Puedes aprender otros campos e industrias porque CS es un catalizador para industrias como la física, la química, el renderizado, etc.
• Puede aplicar métodos CS a contabilidad, administración, logística, tendencias de mercado, administración de recursos humanos, ingeniería de procesamiento de flujo de trabajo, etc.
• La informática tiene filosofías que pueden cambiar su modo de pensar.

Muchos y muchos. Es sorprendente lo que puede hacer si presta atención a la broca de la informática, en lugar de solo cómo programar el software.

La informática incluye:

• Hardware
• Software
• Programación
• Algoritmos
• Resolución de problemas
• Métodos de medición de eficiencia.
• Métodos de estabilidad
• Conceptos de integración
• Arquitectura de Computadores

Y más importante….

• Historia de la informática

Aprendes a apreciar estas cosas cuando entiendes CS y escuchas más allá de la habilidad de intercambio de programación.

O eres un empleado viable … O eres uno increíble que podría ocupar un puesto de liderazgo técnico. Luego, a medida que aprendas más sobre negocios y administración, puedes tomar eso y seguir a los otros fundadores técnicos de nuestra burbuja de Silicon Valley.

Answer 11

Escribí mi primer programa hace casi 50 años (y todavía estoy en eso). Estas son algunas de las lecciones más valiosas que he aprendido en el camino (varias de ellas aprendieron de manera dolorosa).

1. Prefiero optimizar el código depurado que el código optimizado de depuración. Versión larga: no optimice nada hasta que sepa (razonablemente bien) que funciona correctamente en todos los aspectos, excepto en el rendimiento. Mejor aún, no optimice nada a menos que sepa que necesita hacerlo (y tiene todo lo demás correcto). Solo optimice donde haga una diferencia. (¿A quién le va a importar si su cuadro de diálogo aparece cinco milisegundos más tarde de lo que podría tener?) Más generalmente, …
2. “ Lo perfecto es enemigo de lo bueno. ”- Voltaire. No seas un perfeccionista a menos que el trabajo exija la perfección. Si tienes que sacar algo por la puerta, lo suficientemente bueno es lo suficientemente bueno. Por otro lado, la basura es también el enemigo de lo bueno, así que no te excedas con esto.
3. El Número Mágico Siete, Más o Menos Dos puede ser un mito, pero realmente solo puedes tener tantas cosas en tu cabeza al mismo tiempo (incluso si no es exactamente 7 ± 2). Mantente enfocado Si necesita prestar atención a demasiadas cosas a la vez, tome notas, haga una clasificación, escoja algo en lo que concentrarse y ponga todo lo demás fuera de su mente mientras tanto. (Es posible que tenga que hacer un llamamiento respetuoso de su caso a su jefe de vez en cuando.) En el mismo sentido, …
4. “El programador competente es plenamente consciente del tamaño estrictamente limitado de su propio cráneo; por lo tanto, se acerca a la tarea de programación con total humildad y, entre otras cosas, evita trucos inteligentes como la plaga “. – Edsger W. Dijkstra. Sí. Parece que cada vez que he codificado algo que pensé que era particularmente inteligente, tuve que regresar seis meses después para mantener el código y no tenía idea de qué demonios estaba mirando. Si te sientes obligado a ser inteligente, al menos documenta todo lo suficientemente claro como para que un nincompoop total (o incluso seis meses después) tenga una idea cuando llegue el momento.
5. “El joven conoce las reglas, pero el anciano conoce las excepciones”. – Oliver Wendell Holmes, Sr. Todas las reglas tienen excepciones (incluidos todos estos consejos), pero se disciplinan a sí mismos para no hacer recortes hasta que tenga la experiencia para saberlo. Qué puede salir mal y cómo evitarlo. Si no ve el valor de una guía, tal vez sea porque todavía tiene que aprender de qué se trata para protegerse. (Por supuesto, como dice el dicho, la experiencia es lo que obtienes cuando no obtuviste lo que querías. Quizás la única manera de saber realmente que puedes meterte en problemas es meterte en problemas).
6. Si nota que algo está mal en el trabajo, tiene la responsabilidad profesional de alertar a las personas apropiadas. Trabajé con personas que dijeron que, después de que un problema se convirtió en conocimiento común, sabían todo sobre el tema pero no dijeron nada por temor a ser etiquetados como alborotadores. Si bien la preocupación es legítima, guardar silencio es la respuesta incorrecta. Hay una manera de evitar la etiqueta “alborotadora”. Si hay un problema (desde especificaciones poco claras hasta fechas límite poco realistas, entornos de desarrollo de mala calidad o un comportamiento inadecuado de un colega), no se lo guarde. No te quejes con familiares y amigos. No chismes al respecto con el chico en el siguiente cubículo. En su lugar, organice sus pensamientos e informe sus observaciones de manera objetiva y desapasionada a su jefe, gerente de proyecto, representante de recursos humanos, o al trabajo de quien sea, es preocuparse por tales cosas. Preferiblemente, hacerlo en privado y en persona. Se adhieren a los hechos. (Pero es correcto informar cualquier reacción emocional que pueda tener ante un problema si afecta su capacidad para hacer su trabajo). No salte las líneas de autoridad (por ejemplo, informe al jefe de su jefe) a menos que tenga una buena razón y primero notificar a las personas que se saltan. Una vez que haya alertado a las personas correctas, y sepa que se entendió, retroceda, ya sea que las cosas parezcan o no solucionadas. (Está bien indicar, una vez, si desea involucrarse en abordar el problema, pero acepte un “no” si eso es lo que obtiene). Por cierto, esto incluye problemas con su propia capacidad para hacer su trabajo. Por más difícil que sea, tan pronto como se sienta en problemas con una tarea, avise a su gerente. Más que nada, más que incompetencia, los gerentes (y compañeros de equipo) odian las sorpresas desagradables. Todo lo demás, pueden hacer algo para ayudar si se les da la oportunidad.

Answer 12

Tengo 6 años de experiencia en programación.

Estos son los hechos que he aprendido:

1) Nadie vendrá a tu rescate!

Su nave está a punto de hundirse, hoy es la fecha límite, ha ayudado al Sr. Y muchas veces antes, el Sr. Y ha mencionado anteriormente que ya había hecho esto antes. Ve y pide ayuda al Sr. Y. Créeme, hay un 45% de posibilidades de que el Sr. Y ayude y las cosas funcionen. El 55% es probable que el Sr. Y no ayude, o que las cosas no funcionen.
Entonces, ¡aprendí la lección, prepárate y lo suficientemente profesional para resolver las cosas por ti mismo!

2) ¡No estás haciendo nada nuevo!

Si lo has oído bien, no estás inventando o recreando la rueda. El problema al que te enfrentas, lo que estás tratando de hacer, alguien, en algún lugar, ya lo ha hecho. Del 95% de los problemas que enfrenté, había soluciones disponibles en Internet. Pero en lugar de buscar referencias o soluciones, una vez hubo un momento en el que preferí elegir mis instintos o soluciones viscerales. Me costó tiempo. En sitios como Desbordamiento de pila, existe una alta probabilidad de que el problema al que se enfrenta ya se mencione allí con múltiples soluciones. Incluso una simple búsqueda en Google puede obtener tantos resultados en este “error” que mi IDE está informando ahora.

3) ¡KISS es realmente efectivo!

Kiss simplemente significa aquí, mantenlo simple y estúpido concepto. Puedes buscarlo en Google aquí: Déjame buscarlo en Google. El punto es, dependiendo de su memoria, habrá un rango. Para algunos sus días, para algunos sus meses, para algunos es un año o un par de años. Pero nadie puede recordar para siempre todo lo relacionado con la programación.
Puedes pensar que las cosas raras y complicadas que estás escribiendo aquí te convertirán en un héroe y el proyecto dependerá realmente de ti para hacer las cosas. Está usted equivocado. Esto solo se recuperará después de la hora en que olvidará estos trucos tuyos y con la fecha límite en la cabeza, no podrá resolverlos.
¿Por qué ir por tales dificultades? Cuanto más simple sea el código, más efectivo será a largo plazo.

4) ¡Hay alguien más inteligente de lo que crees que eres!

Sí, la hay. Nuevamente, en el punto 3, puede pensar que escribirá un código tan complicado que la gente no entenderá fácilmente. La gente no podrá hacer cambios en esta parte del proyecto sin ti. Bueno, estás equivocado, algún día vendrá una persona inteligente, en un paquete más alto que el tuyo, ¡te pondrá celoso primero y luego romperá tu ego haciendo cambios en tu ‘proyecto abovedado’ como un pedazo de pastel! ¡Hay personas que han inventado algoritmos, sistemas operativos y Dios sabe en qué locuras no puedes pensar! No importa lo que hagas, nunca puedes ser el programador más inteligente que lo sabe todo. ¡Siempre habrá alguien más inteligente que tú!

5) ¡Aunque se ve bien, puede que no lo sea!

Tienes que ejecutarlo en seco, tienes que ejecutarlo.
Tienes que ejecutarlo con todas las entradas posibles.
Puede asumir que el código funcionará de esta manera, pero en realidad, ese fragmento de código se ejecuta en una máquina.
No hay nadie que entienda tus sentimientos allí, ¡hay una lógica simple!
Y no importa lo que pienses, esa máquina va a hacer, lo que va a hacer.
¡Así que mejor entiendes lo que va a hacer la máquina en lugar de asumir cosas!

Answer 13

Sobre el tema de la aceleración del software.

– mi primer gran aha fue cuando un desarrollador senior me mostró (entonces un programador junior) la clave de interrupción en el depurador. Dijo que si mi trabajo era acelerar un programa, primero tenía que entender dónde estaba lento. Dijo que ejecutar el programa y seguir pulsando la tecla de interrupción. Mire la pila, pero vea en qué módulo está actualmente. Después de 10 de estos, debería poder saber dónde se gastó la mayor parte del tiempo, y ese es el código para acelerar.

He tomado muy en serio este primer consejo y repito ese axioma a menudo. Con demasiada frecuencia, los programadores deciden acelerar el software mediante la reflexión y luego la escritura, sin probar primero lo que en realidad era la parte lenta. Perdió tiempo y esfuerzo.

Hay trucos relacionados. Mantener a los constructores fuera de los bucles. Las principales desaceleraciones son el acceso al disco, el acceso a la red, las llamadas al servidor y el acceso a Internet. No se preocupe por acelerar un circuito cerrado tanto como para reducir las llamadas al servidor, etc.

– Puedes codificar bien en cualquier idioma. He escrito un asombroso código de ensamblaje, y sí, incluso un código de máquina. He escrito en Forth, Basic, Fortran, Cobol, Pascal y otros idiomas que ya no están de moda. C # y Swift son agradables, pero la calidad del código que se escribe no depende del idioma.

Answer 14

Incluso si no eres programador de Python, haz lo siguiente

1. Instale python, si su sistema no viene con una versión predeterminada de python.
2. Ejecutar python.
3. Escriba “importar esto”
4. Obtendrá la siguiente salida.

Entiende cada línea. haz esto todos los días hasta que estas reglas se conviertan en parte de tu memoria y hábito de trabajo.

————————–
>>> Lo importo
El zen de Python, por Tim Peters

Lo bello es mejor que lo feo.
Explícito es mejor que implícito.
Lo simple es mejor que lo complejo.
Complejo es mejor que complicado.
Plano es mejor que anidado.
Lo escaso es mejor que lo denso.
La legibilidad cuenta.
Los casos especiales no son lo suficientemente especiales para romper las reglas.
Aunque la practicidad supera a la pureza.
Los errores nunca deben pasar en silencio.
A menos que sea explícitamente silenciado.
Ante la ambigüedad, rechace la tentación de adivinar.
Debe haber una, y preferiblemente solo una, obvia forma de hacerlo.
Aunque esa forma puede no ser obvia al principio a menos que seas holandés.
Ahora es mejor que nunca.
Aunque nunca es a menudo mejor que * correcto * ahora.
Si la implementación es difícil de explicar, es una mala idea.
Si la implementación es fácil de explicar, puede ser una buena idea.
Los espacios de nombres son una gran idea, ¡hagamos más de ellos!
>>>

Edición: aprender un tipo diferente de lenguaje de programación puede mejorar su comprensión y eficiencia en su lenguaje de programación principal. Java es un buen lenguaje para programadores de Javascript y Python.!. Y Python puede ser un buen lenguaje para c #, Java, c ++ programadores.

Answer 15

Una técnica simple que reduce la cantidad de copypasting que hago, y por lo tanto produce menos errores de tipo “tontos”.

A veces solo tienes que duplicar algunas piezas de código. Es inevitable. Este ejemplo no es exactamente el tipo con el que te encontrarías en el mundo real con demasiada frecuencia, pero es algo que hice recientemente y sirve para mostrar la técnica bastante bien:

C # tiene métodos incorporados para analizar números de cadenas. Cada tipo numérico tiene un [type].Parse(string) y [type].TryParse(string, out [type]) . El primero lanza una excepción en un análisis fallido , el último es extremadamente difícil de manejar (aunque gracias a las nuevas características en C # 7 es un poco más agradable).

C # también tiene tipos anulables, por lo que quería tener un método de análisis fácil de usar que solo devuelva el número en caso de éxito o nulo en un análisis fallido. Y porque, por qué no, hagámoslo como una función de extensión en cadenas:

int estática pública? AsInt (esta cadena @ esta)
{
resultado int
if (int.TryParse (@this, out result))
resultado de retorno
retorno nulo
}

Suficientemente simple. Ahora repítelo para todos los otros 10 tipos numéricos. Hay al menos tres lugares que debes cambiar para cada uno de ellos. Termíname ahora …

Ahora, he aprendido que los Regexes codificados son una pesadilla hace mucho tiempo; de hecho, si realmente usas los expresiones regulares para analizar en producción, espero que haya un lugar especial en el infierno para ti.

¡Sin embargo!

Son realmente útiles para tareas comunes de sustitución de texto. Iría tan lejos como para decir que una función de búsqueda y reemplazo sin el soporte de expresiones regulares está rota.

Así que aquí está el truco:

Primero, preparo mis datos en bruto y una implementación de muestra. La implementación de ejemplo está arriba. Los “datos en bruto” se ve así:

Comentó para que el IDE no intente ser útil con el formato.

Es solo una lista de (tipo, nombre) pares, para lo que quiero terminar. Dependiendo de lo que está intentando hacer exactamente, los datos en bruto pueden ser diferentes, por supuesto. Como regla general, necesita una información por cosa que sea diferente en el resultado final.

Luego, prepara la implementación de muestra para que se utilice con su sustituto. En particular, reemplaza los detalles específicos con los marcadores de posición de grupo de expresiones regulares y los aplasta en una línea (al menos en el caso del sustituto de VS – sí, los reemplazos de multilínea harían esto mucho más cómodo).

Y ahora, el último paso importante: realizar el reemplazo.

Seleccione el área que desea reemplazar (sus datos en bruto), establezca el alcance en “Selección” para que no reemplace accidentalmente otras cosas, luego presione el botón mágico “Reemplazar todo”.

Descomentar, limpiar después de ti mismo …

Auge. Siéntase libre de tener el IDE en formato automático para usted, para hacerlo más legible.

Ahora, recapitulación rápida:

1. Prepare el resultado final de la muestra;
2. Preparar piezas de datos únicas para cada caso;
3. Ajuste el resultado final de la muestra para que se ajuste a su mecanismo de reemplazo;
4. Reemplazar.

Si eso parece más esfuerzo que simplemente copiar y pegar y cambiar los detalles a mano … probablemente sea porque lo es.

Pero aquí está lo importante: te das menos oportunidades de joder. Eso es infinitamente más importante que los dos segundos extra que gasta en hacer esto. Solo necesita verificar que el resultado final de la muestra sea lo que desea, y que sus datos se ajusten, en lugar de esperar que su concentración se mantenga durante todo el tiempo que hace los reemplazos a mano.

Durante las sesiones de copypaste más grandes, tiendes a olvidarte de cambiar una cosa aquí, una cosa allí … y se ahoga en el mar de ruidos circundantes, solo para morderte hasta el culo más tarde, cuando hace mucho que lo has olvidado.

E incluso si este método en particular no es de su agrado – la lección subyacente aquí es, haga uso de su IDE. No es solo un editor de texto con resaltado de sintaxis y un botón “Ejecutar”.

Es tan. Mucho. Más.

Answer 16

Las mejores maneras de comenzar a aprender un idioma:

Espero que el siguiente contenido lo ayude a iniciar su operador en el lenguaje de programación …

TODO LO MEJOR !!

Parte 1

Elegir un idioma

1. Elige un lenguaje de programación. La programación de la computadora se realiza esencialmente como un conjunto de instrucciones escritas que la computadora sigue (también conocida como codificación binaria). Estas instrucciones se pueden escribir en varios “idiomas” diferentes, o simplemente son formas diferentes de organizar las instrucciones y el texto. Sin embargo, se suelen utilizar diferentes idiomas para crear diferentes tipos de programas, así que elija un idioma que considere relevante para lo que quiere hacer. Si decide que un idioma no se adapta a sus necesidades, siempre puede pasar a un nuevo idioma.
2. Considere C, C ++, C # y lenguajes relacionados . Estos lenguajes se utilizan principalmente para crear aplicaciones informáticas independientes, como los juegos. C y C ++ son lenguajes difíciles de aprender para un principiante, pero no imposibles. Aprenderlos le dará una comprensión profunda no solo de la programación (la mayoría de los lenguajes de programación heredan algún concepto u otro de C y C ++), sino también de cómo funciona una computadora. Son populares y ampliamente utilizados, aunque C #, un lenguaje muy similar a Java, está empezando a ser mucho más común.
3. Considere Java o JavaScript . Estos son buenos idiomas para aprender si desea trabajar en la creación de complementos web (JavaScript) o aplicaciones móviles (Java). Estos idiomas tienen una gran demanda en este momento, por lo que son útiles para saberlo. Tenga en cuenta que Java y JavaScript son lenguajes completamente diferentes, a pesar de la similitud en los nombres.
4. Prueba Python . Python es un lenguaje muy versátil que se usa ampliamente en varias plataformas. A pesar de ser extremadamente poderoso, es un lenguaje fácil de aprender para un principiante, ¡así que pruébalo!
5. Considere PHP . PHP significa PHP: Procesador de hipertexto. Es un lenguaje de programación web y es relativamente fácil de aprender debido a su débil escritura y popularidad (popularidad significa que habrá varios tutoriales útiles sobre el idioma). Es un gran lenguaje para la programación del lado del servidor.
6. ¡No te limites a estos idiomas! Hay toneladas de lenguajes de programación, todos con diferentes usos. Si quieres trabajar como programador, definitivamente necesitarás saber más de uno, así que aprende lo más que puedas. Lo mejor será mirar los anuncios para el tipo de trabajos que desea obtener y buscar los idiomas comunes que solicitan.

Parte 2

Aprendiendo el idioma

1. Piensa en ir a la escuela. Si bien la mayoría de las compañías que contratan a un programador se preocuparán más por sus habilidades que por la universidad a la que asistió o por sus calificaciones, es de gran ayuda tener un título universitario al que señalar. Aprenderá más eficientemente que si se enseña a sí mismo, todo mientras recibe orientación experta de sus maestros (y quizás de sus amigos). A menudo hay becas y becas disponibles para aquellos que realizan estudios en este campo. No se sienta intimidado por la etiqueta de precio de un título: ¡es posible!
2. Aprende de las universidades online. Ya sea que obtenga un título en línea con tarifas y un título real al final o si asiste a un programa gratuito como la maravillosa Coursera de MIT, puede aprender mucho sobre la programación de estos cursos estructurados.
3. Trate de usar herramientas en línea. Utilice servicios gratuitos como el Consorcio Universitario de Google o la Red de Desarrolladores de Mozilla para aprender más sobre la programación. Estas compañías quieren que más desarrolladores ayuden a que sus plataformas prosperen y sus recursos pueden ser algunos de los mejores en la web.
4. Aprende usando tutoriales en línea. Hay un montón de programadores con sitios web donde te enseñarán los conceptos básicos individuales, así como algunos trucos. Busque tutoriales sobre el idioma que desea aprender para encontrarlos. Muchas clases en línea gratuitas están disponibles para aprender la codificación. La Academia Khan enseña codificación de computadoras, con tutoriales y videos sencillos. Code Academy es otro sitio gratuito para aprender, con tutoriales paso a paso.
5. Empieza joven si puedes. Hay varios programas diseñados para enseñar a los niños a programar. Los programas como Scratch del MIT son muy útiles y cuanto más joven seas, más fácil será aprender (como en cualquier idioma). Evita los kits, ya que estos raramente enseñan algo útil.

Parte 3

Enseñandote

1. Comience con un buen libro o tutorial sobre programación. Obtenga un buen libro actualizado sobre el lenguaje de programación que desea aprender. Por lo general, las revisiones en Amazon o sitios similares lo ayudarán a identificar libros útiles de los que no lo son.
2. Consigue un intérprete para ese idioma. Un intérprete es solo otro programa de computadora, pero convertirá las ideas que ha escrito en un lenguaje de programación en “código de máquina” para que pueda ver cómo funcionan las cosas. Hay muchos programas disponibles y deberá elegir uno que sea apropiado para usted.
3. ¡Leer el libro! Tome ejemplos del lenguaje de programación del libro y póngalos en su intérprete. Intenta cambiar los ejemplos y hacer que el programa haga cosas diferentes.
4. Intenta juntar tus propias ideas para formar un programa de trabajo. Comience con cosas simples, como un programa para convertir monedas, y avance hacia cosas más complejas a medida que continúa leyendo y aprendiendo sobre su lenguaje de programación.
5. Aprender otro idioma. Una vez que comience a programar activamente en su primer idioma, es posible que desee aprender un segundo idioma. Aprovechará al máximo el aprendizaje de un segundo lenguaje de programación si elige uno que use un paradigma radicalmente diferente al que comenzó. Por ejemplo, si comenzó en Scheme, podría intentar aprender C o Java a continuación. Si comenzaste en Java, podrías aprender Perl o Python.
6. ¡Continúa programando y probando cosas nuevas! Para ser un buen programador, al menos, tienes que mantenerte al día con la tecnología cambiante. Es un proceso de aprendizaje constante, y siempre debes aprender nuevos idiomas, nuevos paradigmas y, lo que es más importante, ¡programar nuevas cosas!

Para más información; Por favor, siga,

Govarthanan GC

Answer 17

Los mejores trucos que he aprendido están relacionados con la calidad y la depuración eficiente. Aquí hay algunos:

* Afirmar todo. Si un método acepta un parámetro, confirma que existe, no es nulo, está dentro del rango válido y es del tipo correcto. Después de cada operación, afirmar que su resultado es válido y como se espera.

* Cualquier punto de partida es mejor que ninguno. ¿Está algo mal, pero no sabes dónde? Ponga un punto de ruptura en cualquier lugar de la ruta de ejecución que esté garantizado para ejecutarse, y vaya desde allí. Ahora sabe si el error ocurre antes de ese punto o después. Si sigue avanzando, le garantizamos que encontrará exactamente dónde está el problema.

* Realice el trabajo mínimo necesario en cada paso y repítalo. Si le toma cinco o seis pasadas para escribir una función corta, que así sea. De esa manera, es mucho más fácil de depurar.

Answer 18

Una de las lecciones más importantes que aprendí en mi tiempo en el desarrollo profesional es: ESCRIBA SU CÓDIGO PARA LEER.

O usted o alguien más tendrá que volver a él en el futuro y cuanto más legible sea, mejor será su situación. Esto significa:

* Mantén tus cuerpos de método cortos. Divida la funcionalidad en bits pequeños y coherentes.

* Nombra todo de manera coherente y consistente. La diferencia entre “ds” y “dataSet” es grande. La diferencia entre “updateDataSet ()” y “convertAllDataSetItemsToDTOs ()” es menos obvia pero sigue siendo útil. Cuanto más pueda saber de un vistazo lo que está haciendo el código, más dolor le ahorrará a largo plazo.

* No abstraiga a menos que sea legítimamente útil para su base de código. Habrá ocasiones en las que repita la misma lógica cinco o seis veces o más, y realmente es útil extraerla en su propia construcción genérica, pero también puede dispararse en el pie abstrayendo algo que solo usa. dos veces y alejando la lógica de su caso de uso sin ningún beneficio real. (Un jefe mío dijo una vez que nunca debes abstraer algo hasta que lo veas surgir al menos tres veces).

Básicamente, nunca corra bajo el supuesto de que no tendrá que sacar algo y hacer más con él más adelante.

Answer 19

Dudo en afirmar que podría identificar “los mejores” consejos o trucos.

Sin embargo, mencionaré algunos que me parecen útiles.

Personalmente he llegado a la conclusión de que lo más fundamental que hace un programador es nombrar cosas.

Dado un conjunto de requisitos o algún tipo de especificación, creamos una colección de primitivas que logran algún tipo de recopilación (entrada), manipulación (cálculo, cálculo, transformación) y disposición (salida, almacenamiento, etc.) que cumple esos requisitos (o al menos * algunos * de ellos).

Entonces le damos un nombre a eso. Para tareas de programación muy pequeñas, ese nombre es un comando … para tareas más grandes y proyectos de cualquier tamaño, tenemos que dividir el objetivo general en partes más pequeñas. Encontramos un nombre para el proyecto y creamos nombres para los componentes … además de definir algunos tipos de “responsabilidades” y “colaboración” (y protocolos) sobre cómo interactúan esos diversos componentes.

Dentro de cada componente, descubrimos la necesidad de variables, funciones, clases, métodos, atributos, archivos, instancias, etc. Todos estos necesitan nombres y necesitamos administrar todos estos nombres en todo tipo de formas contextuales (ámbitos).

Por lo tanto, los programadores dedican gran parte de su esfuerzo a nombrar y administrar (recordar la semántica de y usar) los nombres proporcionados por el lenguaje, por módulos de terceros y bibliotecas de clases, por colegas en el mismo proyecto e incluso por todos los nombres que eligieron al final. semana, el mes pasado y así sucesivamente.

La mayoría de la gente piensa en la “programación” como el proceso de diseñar esos encantamientos … y eso es parte del trabajo. Saber cómo rellenar varios formularios (algoritmos) con los detalles específicos de una tarea determinada a veces es un desafío (especialmente al principio).

Pero, más tarde, el desafío es hacer un seguimiento de ese léxico … todos esos nombres (y su semántica asociada). Con el tiempo, se vuelve realmente fácil ver qué tipo de transformaciones y recorridos alimentarán sus datos a través de su funcionalidad y volverán en la forma necesaria. Pero tienes que administrar todos esos nombres … y establecer cada vez más capas de nombres. Por ejemplo, en las aplicaciones agrupadas, los “nombres” de los hosts y los puertos son, probablemente, de algún tipo del servicio de administración de la configuración (como Zookeeper) cuyo “nombre” (lista de nombres de host) puede provenir, a su vez, de una configuración que, en a su vez, puede provenir de un valor predeterminado integrado, una opción de línea de comandos o una configuración de entorno … o alguna jerarquía de esos.

Hacer un seguimiento de todo esto requiere esfuerzo y concentración; a menudo es demasiado para mí, por eso no soy principalmente un programador. Me toma mucho tiempo “meterme en la zona” … conseguir que mis neuronas se activen en el contexto correcto para funcionar de manera efectiva en mi propio código … o en el de otra persona. Una vez que lo administre, tendré que ir con él todo el tiempo que pueda sin volcarme en gran parte de ese estado debido a alguna interrupción o distracción.

Ese es realmente el mejor “consejo” que tengo.

Other than that I suggest that people learn to recognize when certain data are, or contain, or beg to be treated as, sets, hash mappings, trees, bitmaps, etc. Most languages today have really good support for these data types and collections. So, when you can see them in your data you have opportunities to use a bunch of support that’s already been written (and *named*) by a whole community.

Answer 20

In my years as developer these are the main lessons I learned:

• Test your code as good as possible. When you need to touch untested code it often ends up in a bug hell.
• Keep things as simple as possible. Short classes and modules covering a single responsibility. Separate concerns in different modules/namespaces
• Create clear interfaces with a clear concern. Don’t create too general interfaces overing any edge case.
• Don’t do overengineering. If you have part that need to be improved, improve it when you need to touch related code ( at least when you want to sell the software). Otherwise have a shipping focus while developing.
• If you need to use third party code, create an own interface. Any use of that third party code should go through your interface. Wrap return values in own structures (Adapters, warppers or whatever).