Últimamente he estado trabajando profesionalmente, saliendo con otros programadores y haciendo amigos en la industria. Lo único es que soy 100% autodidacta. Esto causó que mi estilo se desviara extremadamente del estilo de aquellos que están entrenados adecuadamente. Son las técnicas y la organización de mi código lo que es diferente.
Es una mezcla de varias cosas que hago. Tiendo a mezclar varios paradigmas de programación juntos. Como funcional y OO. Me inclino por el lado funcional más que OO, pero veo el uso de OO cuando algo tendría más sentido como entidad abstracta. Como un objeto de juego. A continuación, también voy por la ruta simple cuando hago algo. En contraste, parece que a veces el código que veo de los programadores profesionales es complicado por el simple hecho de hacerlo. Yo uso muchos cierres. Y, por último, no soy el mejor comentarista. Me resulta más fácil simplemente leer mi código que leer el comentario. Y la mayoría de los casos acabo leyendo el código incluso si hay comentarios. Además, me han dicho que, debido a lo simple que escribo mi código, es muy fácil de leer.
Escucho a programadores capacitados profesionalmente seguir y seguir sobre cosas como las pruebas unitarias. Algo que nunca he usado antes, así que ni siquiera tengo la menor idea de qué son o cómo funcionan. Montones y montones de guiones bajos "_", que no son de mi agrado. La mayoría de las técnicas que uso provienen directamente de mí o de algunos libros que he leído. No sé nada sobre MVC, aunque he escuchado mucho sobre cosas como backbone.js. Creo que es una forma de organizar una aplicación. Sin embargo, me confunde porque ahora he creado mis propias estructuras organizativas.
Es un poco doloroso. No puedo usar aplicaciones de plantilla cuando aprendo algo nuevo como Ubuntu's Quickly. Tengo problemas para entender el código que puedo decir es de alguien capacitado. La programación completa de OO realmente deja un mal sabor de boca, sin embargo, eso parece ser lo que TODOS los demás están usando estrictamente.
No me deja tan confiado en el aspecto de mi código, ni me pregunto si causaré chispas al unirme a una empresa o tal vez contribuir a proyectos de código abierto. De hecho, tengo bastante miedo del hecho de que la gente eventualmente revisará mi código. ¿Es esto algo normal por lo que pasa cualquier programador o realmente debería buscar cambiar mis técnicas?
Respuestas:
Bueno. Ser consciente de que la gente va a mirar tu código te hará esforzarte más.
La programación se ha convertido en un campo increíblemente grande. Hay docenas de temas, herramientas, nichos y especializaciones, algunos de los cuales son carreras completas en sí mismos. Hay mucho que aprender y saber, y cuando trabajas con otros programadores, siempre habrá cosas que sabes que no y cosas que sabes que tú no. Ésto es una cosa buena.
Si le preocupa que su experiencia sea incompleta, hay muchos pasos que puede tomar para enmendar eso a través de la educación formal y la colaboración con expertos capacitados. Pero parece que tienes miedo de que haya algún hito cuantificable después del cual la gente diga "Está bien, ahora que lo he dominado, oficialmente soy un programador". No hay tal hito. Definitivamente he tenido momentos en los que pensé "sí, ahora estoy llegando a algún lado" después de aprender algo nuevo, pero no hay una lista mágica de cosas que debes saber y hacer para llamarte programador.
Sé muchas cosas sobre programación, he usado una docena de lenguajes en muchos proyectos y, sin embargo, el subconjunto de conocimientos de programación que puedo llamar mío es muy pequeño. Y me gusta eso.Francamente, un programador no es algo que eres. Un programador es algo que constantemente aprendes a ser.
Haga un inventario honesto de sus habilidades, sus fortalezas y debilidades. Obtenga comentarios de personas con más experiencia que usted. Busque posiciones que se alineen bastante bien con lo que cree que está, pero no tenga miedo de buscar trabajos que estén un poco fuera de su dominio actual. Si solo toma trabajos de los que ya sabe todo, nunca aprenderá en el trabajo.
fuente
Cuando comience a desarrollar aplicaciones en cooperación con otros desarrolladores, algunas de estas debilidades de estilo personal se interpondrán en el camino.
Si comienza a trabajar en una tienda que usa guiones bajos, va a usar guiones bajos. Todos, independientemente de sus antecedentes anteriores, siguen el estándar de la tienda para el estilo de codificación.
A menos que su estilo de codificación sea extremadamente obvio, será mejor que se acostumbre a escribir comentarios claros y concisos que expliquen cómo funciona su código, para que otros desarrolladores puedan seguirlo.
Si no sabe nada sobre las pruebas unitarias, compre un buen libro. Hay muchos buenos libros sobre pruebas de unidades por ahí. Lo mismo con MVC.
Los desarrolladores de software profesionales saben cómo jugar bien con los demás, sin ensuciar la caja de arena. Los mejores saben leer y escribir código independientemente del estilo.
fuente
La programación tiene un componente de arte y un componente de disciplina. El componente de arte es pensar los mejores enfoques e implementarlos; la disciplina consiste en asegurarse de que lo haya hecho correctamente y que otros puedan entender su código y mejorarlo cuando sea necesario.
El componente de arte es divertido: lo haces porque lo disfrutas. Naturalmente, esa es la parte que te enseñas primero.
El componente de disciplina es más una molestia: lo haces por necesidad. Sin embargo, es un componente vital del trabajo en equipo: no se puede evitar hacerlo, al menos hasta cierto punto. Una vez que su código está integrado con el de sus compañeros de equipo, su flexibilidad para "cambiar las cosas a su antojo" se sumerge. Sin embargo, necesita una capacidad para cambiar su código con confianza en respuesta a los requisitos cambiantes, o para solucionar errores. Aquí es donde entran varias pruebas "aburridas": con muchas pruebas en su lugar, es fácil verificar si su último cambio rompe cosas o no.
El estilo de código también adquiere importancia, porque adherirse a un estilo común hace que el código sea más fácil de leer para todos. En las empresas más grandes, encontrará trabajos nocturnos que prueban el cumplimiento de los estándares de codificación automáticamente y le envían por correo electrónico advertencias desagradables cuando se desvía.
Volviendo a su pregunta, concentrarse en el componente de arte es una etapa temprana natural del desarrollo del programador. Pueden pasar varios años de trabajo en la industria antes de comenzar a apreciar el componente de disciplina. Sin embargo, no necesita buscar activamente "cambiar sus técnicas": se transformarán naturalmente en el proceso de trabajar en equipo.
fuente
A su pregunta, sí, siempre debe buscar cambiar su técnica, adoptar el proyecto único y la tecnología emergente.
El punto de @ assfallows de "Francamente, un programador no es algo que eres. Un programador es algo que estás aprendiendo constantemente a ser". es realmente el ser todo y terminar toda la codificación.
Es genial que estés notando áreas donde haces algo diferente de los demás, especialmente cuando ves que es un estándar. Has detectado pruebas unitarias y MVC, y ahora tu próximo paso debe ser aprender sobre ellas. Vea cómo funcionan, qué necesita para implementarlos e intente saber cuándo es un buen diseño implementarlos.
Este es un campo en constante evolución con nuevos lenguajes y patrones que suben y bajan. Si se siente cómodo con el aspecto de la codificación, comience a examinar la parte de diseño. Aprenda qué los hace buenos y cuándo usarlos.
Ciertamente, unirse a un equipo es un gran beneficio: siempre necesita otros ojos para mirar su código para detectar áreas en las que se apresuró o no pensó en todas las implicaciones.
fuente
No necesitas ser un comentarista mayor. Pero debe ser un buen compromiso (sí, comience a usar algún tipo de VCS; recomiendo Git).
El estilo es algo que SIEMPRE evoluciona. No te preocupes por eso. Aprenderá qué es un código reutilizable y qué no. Pero tienes que practicar y obtener ayuda para ello.
Intenta ayudar en algún proyecto de código abierto en Github. Algunas personas son realmente agradables allí e intentarán ayudarte. Este es el mejor consejo que puedo darte.
fuente
¿Cómo sabría qué cambiar sin comentarios de programadores más experimentados?
Hacer que otras personas revisen su trabajo puede ser desalentador, especialmente las primeras veces, pero es la mejor manera de obtener la crítica constructiva que necesita para mejorar sus habilidades. Hay un sitio SE para revisiones de código que puede ser útil. Pedirle a amigos inteligentes que miren su código es otra buena manera de obtener algunos comentarios.
fuente
Lo más importante es desarrollar flexibilidad. Cuanto más familiarizado esté con los conceptos fundamentales, más receptivo podrá ser en cualquier lenguaje, enfoque de programación, estilo o entorno.
El dominio se trata menos de aprender todo / algo / hay que aprender, y más acerca de aprender / cómo / hacer para resolver un problema, en una variedad de situaciones.
Y la mejor receta para eso es la práctica. Siempre debes tener un proyecto; Si estás entre conciertos pagados, toma un juguete personal. Tiempo libre un fin de semana? Trabaje a través del 'mundo hola' para un lenguaje o plataforma que nunca haya usado antes. Busque maneras de aprender mucho a la vez. Por ejemplo, cree algo en Google App Engine y aprenderá de una vez sobre Python, BigTable y las bases de datos orientadas a columnas. También obtendrá una buena dosis de estilo "profesional" de Google.
Un buen general sabe cómo aplicar sus tácticas aprendidas y su experiencia acumulada en una variedad de terrenos. Parece que tienes algunas tácticas y experiencia, pero necesitas encontrar un terreno desconocido. Esa es probablemente la mejor manera de determinar lo que sabe y lo que debe aprender a continuación.
Y si lo que buscas es un estilo "profesional", toma algunos proyectos "profesionales". Encuentre un proyecto de código abierto que le guste, asígnele un cambio y configúrelo. Esté preparado para los revisores imbéciles, pero recuerde que la mayoría de las personas en este campo no llegaron a donde están para tener habilidades sociales fluidas. El punto es exponerse a la mayor cantidad posible de lo que quiere ser. Y tienes que desarrollarte lo suficientemente bien como para hacerlo tú mismo. Ninguna clase realmente puede enseñarte. De hecho, hoy se está aprendiendo demasiado, y no hay suficientes competencias sólidas en el mundo real.
fuente
En mi opinión, no hay necesidad de preocuparse por lo que otros piensan de su código si se enfoca en medidas objetivas de la calidad del mismo. Lo es
Como primer principio, siempre debe ser su objetivo centrarse en las cualidades objetivas, en lugar de las opiniones de los demás. Centrarse en las opiniones de los demás es el camino hacia la mediocridad y, como está experimentando, la ansiedad.
La única razón para preocuparse por las opiniones de los demás es poder integrarse bien socialmente (o en un ambiente de trabajo) con ellos. Si tiene en mente el objetivo de mejorar las cualidades objetivas de su trabajo, entonces no hay necesidad de sentirse asustado por las reacciones de los demás: son solo oportunidades para aprender o, en el peor de los casos, detalles prácticos para tratar .
¡¡Sé sincero contigo mismo!! Continúa aprendiendo y disfrutando lo que haces.
fuente
Me recuerdas a mí mismo después de ir a la universidad para ser ingeniero de software. Si quieres ser programador, diría que toma una posición. Deberá comentar su código, escribir pruebas unitarias, comprender, completamente, el código orientado a objetos. Pero en este momento no tienes una razón real para hacerlo. Siempre y cuando solo estés trabajando en pequeños proyectos personales. Donde no tienes que responder a nadie más que a ti mismo. No crecerá más como desarrollador.
Al asumir grandes proyectos en los que muchas personas están trabajando y tener que responder a preguntas de administración como "¿Esta versión no tiene errores? Porque la vamos a lanzar al cliente". Crecerás como programador / ingeniero. Obtendrás algunos golpes duros. Puede encontrar las cosas que mencionó más valiosas y puede encontrar cosas nuevas que nadie ha pensado antes. Crecerás
Incluso mi universidad no me enseñó estas cosas a pesar de que lo intentaron.
Para Pruebas unitarias, busque Desarrollo guiado por pruebas.
Para comentar piense en el código que ha escrito después de su partida. Y el tiempo que otras personas gastarán en ingeniería inversa.
Para lenguajes orientados a objetos. Entiéndelo al menos. Es una herramienta que puede usar para resolver problemas de una manera más legible.
Buena suerte: D
fuente
En resumen, la mejor manera de aprender es por lo general para pasar el rato con alguien que puede aprender de . Si sientes que tus habilidades no están a la altura, salir con personas que son mejores que tú es lo mejor que puedes hacer. Ciertamente, mucho mejor que retirarse y aislarse aún más.
Sin embargo, creo que estás pintando una imagen muy simplificada y engañosa. Lejos de todos los programadores "profesionalmente enseñados" son realmente buenos. El hecho de que hagan algo no significa necesariamente que sea lo correcto.
Y mucho (pero no todos) de lo que está diciendo realmente suena como que eres el que podría enseñar a un truco o dos.
Eso suena genial para mi. Los mejores codificadores son los que usan la herramienta adecuada para el trabajo. Siempre elegiría a alguien que conozca ambos paradigmas y use cada uno de ellos donde tenga sentido sobre alguien que religiosamente use solo un paradigma.
Nuevamente, la simplicidad es buena . No haga su código complejo hasta que necesite ser complejo. Algunas personas no tienden a hacer cosas complejas de una idea equivocada de la elegancia, o porque "vamos a necesitar esta funcionalidad adicional más adelante". En general, es mejor hacer lo más simple que resuelva su problema.
Lo que debe comentarse y cómo es altamente subjetivo. No hay un verdadero "correcto" o "incorrecto" allí, pero cuando se trabaja en un equipo, es importante escribir un código que todo el equipo, y no solo el autor del código, pueda entender. Y a veces, se deben hacer compromisos para cumplir con el estilo de codificación del equipo. Eso no significa necesariamente que deba escribir más comentarios, simplemente significa que es algo en lo que usted y su equipo tendrán que estar de acuerdo.
Bueno, pregúntales. :) Probar su código es esencial, y las pruebas unitarias son una herramienta popular y útil para esto.
Al igual que con los comentarios, eso es subjetivo y depende del idioma. En C y C ++,
lowercase_with_underscoreses una convención de nomenclatura bastante común. En muchos otros idiomas, prácticamente nunca verías un guión bajo. Pero al final del día, realmente no es importante. Si una función se llamawrite_to_logoWriteToLogno realmente va a hacer la diferencia. Alguien tendrá que asimilarlo y cumplir con lo que el equipo haya acordado allí.Al igual que con las pruebas unitarias, nunca dejes de aprender. Trabaja junto con personas que saben cosas que usted no sabe y que provienen de un entorno diferente al suyo. Aprender de los demás. Claramente hay cosas que puedes enseñarles, pero también hay cosas que no sabes, o de las que nunca has oído hablar, que pueden enseñarte. Eso no significa que usted (o ellos) sean malos programadores. Significa que un buen programador es aquel que se esfuerza por mejorar y aprender de los demás.
Lo mismo aquí, y soy lo que llamarías "profesionalmente entrenado" (un título de CS). Las personas a las que se les ha enseñado programación difieren tanto como las personas que son autodidactas. Parece que estás trabajando con algunos que realmente necesitan aprender algunos trucos nuevos.
Ambos. Por supuesto, da miedo que otros vean (y juzguen) lo que has hecho. Pero también es muy educativo. Pueden decirle lo que habrían hecho de otra manera, o por qué lo habrían hecho de otra manera. Pueden ayudarlo a mejorar y también pueden aprender algo ellos mismos. Muéstreles un código que resuelva un problema mejor de lo que lo hubiera hecho su solución "preferida", y esperemos que digan "oh, eso está bien. ¿Cómo supiste hacer eso? ¿Cómo llamas a esto? Debería usar esta técnica yo mismo "
fuente
Esta no es una respuesta completa, ya tienes varias buenas. Sin embargo, hay un par de puntos que para mí parecen un poco confusos y no se han abordado.
Para mí parece que eres confuso declarativo vs imperativa , en lugar de la programación orientada a objetos funcional y funcional. Si quiere decir que se inclina hacia la programación declarativa y lejos del imperativo, eso es algo bueno. Declarative busca eliminar los efectos secundarios, lo que debería hacer que su código sea más fácil de entender.
Los lenguajes de programación modernos a menudo admiten el modelo de programación declarativa. Por ejemplo, en C #, usar Linq da como resultado un estilo declarativo, porque no está diciendo cómo obtener lo que desea; solo dices lo que quieres.
Los lenguajes modernos son a menudo lenguajes de paradigmas múltiples. Es raro que alguien use un lenguaje "puro". Muchos lenguajes funcionales admiten objetos y efectos secundarios. Los lenguajes considerados orientados a objetos a menudo no imponen la restricción de que todo es un objeto.
¿Qué quieres decir con OO completo? Nunca he trabajado en código OO "puro". Quizás pueda darnos algunos detalles más de lo que no le gusta. Una ilustración de un proyecto de código abierto podría ayudar.
Las programaciones OO nos brindan muchas características para admitir cosas como: abstracción de datos, encapsulación, mensajería, modularidad, polimorfismo y herencia. Si mirara una base de código que no aprovechara eso, dejaría un mal sabor de boca.
fuente
Respuesta corta: sí.
Enseñarse es casi todo bueno.
Filtra con buen sentido, buenos consejos.
WRT aprendiendo programación profesional, sí.
¿Qué tienes en mente?
Conferencias, seminarios, certificación, un título?
Cada uno tiene un costo / beneficio.
Cuando el ROI es bueno, si tiene los recursos, hágalo.
Considere los consejos sobre títulos considerando la fuente: las personas con / sin ellos tienen intereses creados.
Habla con media docena de cada uno.
¿Está la academia aislada de la industria? A menudo.
¿Es un título sin valor? En cuanto al dólar, difícil de discutir.
Los graduados casi siempre ganan más dinero, pero ten cuidado con los préstamos universitarios.
¿Sabio en cuanto al conocimiento? Tal vez.
Si odias la escuela, no obtendrás más de lo que pones.
Si crees que un título es un objetivo digno para ti, probablemente lo sea.
Profundice y descubra el programa de estudio, los costos, el medio ambiente. Asegúrese de tener el interés, el compromiso, el tiempo y los recursos. Probablemente fuiste a la escuela durante trece años, entonces, ¿qué son otros cuatro? Serán los más caros, y la persona principal en la que confiarás para que sean más valiosos eres tú.
Los costos pueden ser bastante aterradores, pero solo cuentan una parte de la historia porque hay muchas subvenciones y becas por mérito, necesidad y otras cien razones.
Si vas, elige profesionales y brotes inteligentes.
fuente
Segunda pregunta: ¿Puedo usar mi propio estilo?
Tienes dos preguntas
El primero está en tu título. Por favor vea mi respuesta anterior.
El segundo se detalla en unos cinco párrafos donde caracterizas cómo tu estilo difiere del estilo profesional con los puntos que se enumeran a continuación:
Resumiendo, creo que está preguntando si está bien que utilice el enfoque de Frank Sinatra: "Lo hice a mi manera". Siento ambivalencia cuando llamas al código profesional de otras personas, pero no estás de acuerdo. El estilo es un problema personal difícil y el debate sobre qué es un buen código es interminable y, a menudo, una pérdida de tiempo. Algunos problemas pueden ser más fáciles si su grupo usa una convención de codificación escrita. Por favor consulte:
http://en.wikipedia.org/wiki/Coding_conventions
Hay una etiqueta para matar el código de otra persona, y esa es otra cosa en la que debe trabajar con su equipo. Ponte la piel gruesa y espera que no sean demasiado brutales, pero hagas lo que hagas, no vayas a la guerra.
Comentaste sobre la ansiedad de que otros vean tu código. Prepárese porque no solo lo verán, sino que lo reescribirán y le dirán qué tiene de malo su estilo. Sus compañeros de trabajo pueden ser flexibles o rígidos. De cualquier manera, le recomiendo que no reescriba su código de estilo ni haga que cada punto de estilo sea una negociación.
Las razones para tener un código uniforme (y una capacitación uniforme) son para aumentar la velocidad y la productividad del desarrollo y, de alguna manera, institucionalizar el aprendizaje de las mejores prácticas. Problemas como camelCase o use_underbars pueden parecer triviales y mezquinos, pero la coherencia tiene beneficios.
Esté abierto a pruebas unitarias y desarrollo impulsado por pruebas. Cuando está solo, no forma parte de proyectos de pago, es más como un pasatiempo. Sus cosas no necesitan combinarse con lo que otras personas están haciendo. Si su código falla, no es gran cosa. Pero cuando está involucrado con un equipo, el código que escribe puede afectar a todo el equipo, especialmente si llega a los clientes.
Del mismo modo, si su equipo usa MVC, infórmese sobre ello, con suerte de las mismas fuentes a las que hacen referencia. Los métodos de estructuración de programas pueden hacer una gran diferencia, como lo ha demostrado el experimento. Nuevamente, tome el ejemplo y el liderazgo de su equipo.
Si su equipo usa backbone.js, usted también lo usa. Tu equipo es como patos volando en formación. Alinearse juntos les ayuda a gastar menos energía, los hace más seguros y les ayuda a llegar a su destino de manera más efectiva. La analogía se rompe si se presiona mucho, pero existen grandes ventajas al usar herramientas, técnicas comunes y alinearse con las decisiones de los equipos.
fuente
El consejo dado es bastante útil, pero trato de recordar que mi objetivo principal es crear un "software de trabajo" que sea útil para mis usuarios. Mi audiencia generalmente NO es un grupo de programadores: son personas de negocios que están dispuestas a pagar dinero por una solución automatizada (a los usuarios no les importan las metodologías OO, los marcos, las pruebas unitarias, los comentarios de código, etc. colgó en él.)
He encontrado útiles los ideales del Manifiesto Ágil en mi carrera (www.agilemanifesto.org)
fuente
Me relaciono completamente con esta pregunta. Tengo exactamente los mismos sentimientos y un fondo muy similar (pero no exactamente el mismo). Se supone que debo estar capacitado profesionalmente (o más bien académicamente), por lo que se supone que debo saber acerca de la programación OO, etc. La programación no fue mi tema principal, pero lo he hecho. Aprendí OO en algunos de mis cursos y no entendí la razón de ser en absoluto. De hecho, la única vez que entendí OO fue cuando hice un trabajo comercial y dos grandes mentores me obligaron a hacerlo.
Estoy seguro de que mi profesor fue igualmente brillante, pero usted ve el beneficio real en la práctica en un entorno comercial frente a la programación funcional, pero no tiene la oportunidad de verlo en un curso diseñado para ejecutarse, enseñar y finalizar en unos pocos meses. . No he tenido la oportunidad de trabajar en una estructura basada en MVC, pero estoy seguro de que será la misma, es decir, podría retomar los conceptos de un libro, pero comprenderé su beneficio cuando lo vea en uso en un entorno comercial Y estoy totalmente de acuerdo con usted, ¿por qué usar OO y MVC y cualquier otra estructura compleja si puede resolver un problema de una manera más simple? Mi consejo es que no sea tímido con el trabajo porque lo expondrá a situaciones diferentes y le permitirá comprender las mismas cosas de una manera diferente.
Claro que aprendí sintaxis y conceptos en mi formación académica, pero fue en el mundo comercial donde comencé a aprender a programar.
fuente