Programación completa de la correa de mano
Lea dos artículos:
Pensamientos del programador
Lei Jun
No soy un programador nato, ni nací para que me gusten las computadoras . Cuando estaba en la escuela secundaria, nunca pensé que me convertiría en programador. Entré en contacto con las computadoras por pura casualidad: un buen amigo mío eligió especializarse en informática en la universidad, así que para tener más "* * * lenguaje" con este amigo, elegí el departamento de informática. En la universidad vislumbré el mundo de la informática y me apasioné. Después de graduarme, comencé mi carrera como programador.
Han pasado casi diez años desde que comencé a escribir programas y he escrito muchos programas. Por los altibajos de los últimos años, no puedo evitar sentir algo. Hablando de experiencia, la mayor experiencia es que el camino es demasiado largo.
Primero, estoy dispuesto a hacerte sufrir por el resto de tu vida.
No espero que todo el mundo compare los programas de escritura con la creación literaria, pero el dolor que implica no es algo que un usuario común y corriente pueda entender. Pasamos demasiadas noches sin dormir intentando escribir un buen programa. Un amigo comentó: "Escribir un programa es un suicidio, requiere mucha energía y capacidad mental". Sin embargo, todavía hay muchas personas que no temen las dificultades y avanzan con valentía.
Tan pronto como entré en contacto con las computadoras, descubrí la belleza de las computadoras: las computadoras son mucho menos complicadas que los humanos. Si tus programas están bien escritos, puedes tener una relación muy armoniosa con las computadoras y ordenarles que hagan lo que quieras. En este momento, eres el amo absoluto. Cada vez que me siento frente a la computadora, es como viajar a un reino.
El mundo de la computadora es muy grande y los programadores viven en el reino de su propia imaginación. Puede profundizar en cada byte y bit de su computadora.
Un día así es simplemente el paraíso, y mucha gente se enamora de ese día.
Mucha gente piensa que los programadores pueden dejar de trabajar cuando tienen como máximo 35 años y que su cerebro debería estar casi descansado. También piensan que los programas de escritura son para jóvenes. Después de alcanzar cierta edad, se estima que pocas personas se convertirán en programadores.
Cuando me gradué por primera vez, estaba muy motivado y quería soportar las dificultades primero. Dejar de fumar a los 30 años. Sólo cuando crecí me di cuenta de mi ignorancia. Una persona tiene sólo 21 o 22 años cuando se gradúa de la universidad, y puede tener 25 cuando sus habilidades están maduras. Luego están los billetes de autobús, una esposa, una casa y muchas otras cosas ocupadas. Cuando todo esté dicho y hecho, puede que tenga treinta y cinco años. Si te rindes a los 35 años, no es necesario que elijas el camino del programador.
Las computadoras llevan mucho tiempo en China, pero no fue hasta 1985 cuando se lanzaron las PC en China cuando realmente comenzaron a usarse a gran escala. Por lo tanto, las personas que realmente escriben programas de computadora en China solo llevan más de diez años escribiendo como máximo (no sé si existen esas personas). Dado que las computadoras se han utilizado en China durante un corto período de tiempo, la fuerza principal en el desarrollo de programas nacionales son principalmente los jóvenes menores de 35 años, pero esto no significa que los programadores sean tan propensos a envejecer como la Dama Rosa. Los desarrolladores en Estados Unidos y Taiwán tienen principalmente entre treinta y cuarenta años. Cuando comenzamos a escribir programas, sentimos que no había nada que no pudiéramos hacer (todavía podemos escuchar esa retórica). Más importante aún, parecía que éramos particularmente inteligentes y aptos para desarrollar software, mucho mejor que los extranjeros. Cuando realmente entramos en contacto con esos excelentes desarrolladores extranjeros, descubrimos que son muy poderosos. Todos tienen más de diez años de experiencia en desarrollo y la mayoría de los productos son producidos por estos programadores con una rica experiencia en desarrollo.
Después de graduarme, la programación no es sólo un hobby, sino también un trabajo para toda la vida, y estoy seguro de que lo haré por el resto de mi vida, aunque no tengo intención de hacer solo esto por el resto de mi vida. Programar con ciclos de vida es fácil y difícil. Si eres mediocre, entonces escribe algunos programas para trabajar y deja que las personas que los han escrito durante dos vidas los tengan. Pero si quieres dedicarte a escribir programas, no será fácil escribir durante diez años. Ahora muchos de mis amigos se han lavado las manos. A veces también tengo este pensamiento, pero una vez que me enfrento a la computadora, inmediatamente me doy cuenta de que la computadora sigue siendo lo que mejor hago y lo más conveniente.
En segundo lugar, mi futuro no es un sueño
Algunas personas trabajan duro para aprender tecnología de programación, trabajan duro para mejorar su nivel de programación y consideran a los programadores senior como sus objetivos, incluso sus objetivos. metas de toda la vida.
Más tarde, después de participar en el desarrollo de software comercial real, me sentí muy confundido y perdido.
Cuando estaba en la universidad, convertirme en programador senior también era mi objetivo. En ese momento, aprobé el examen de grado y obtuve el certificado de programador senior, y las palabras "programador senior" estaban impresas en la tarjeta de presentación. Posteriormente mi nivel mejoró y parecía que me reconocían como un excelente programador. En ese momento comencé a sentirme abrumado. Espero que mis habilidades puedan ser reconocidas por otros. ¿Qué puedes hacer si eres reconocido por los demás? Más tarde descubrí que no importa cuán senior sea un programador, es inútil. La clave es si puedes generar ideas y productos, si tu trabajo puede ser reconocido por la sociedad y si puedes crear riqueza para la sociedad.
Mi futuro es claro: desarrollar productos de alta calidad adecuados para la sociedad y crear riqueza para la sociedad.
En tercer lugar, cada programa es una obra de arte.
Algunas personas piensan que los programadores no son nada, solo un trabajo técnico; otros dicen que la programación es una creación artística, y son elogiados hasta el cielo. Estas dos opiniones son muy controvertidas e incluso contradictorias.
Veamos un trabajo diferente. Los masones deben ser técnicamente sólidos y no tener nada que ver con el arte. Pero son estos masones quienes nos han dejado innumerables reliquias culturales, como el Buda Gigante de Leshan, las Grutas de Mogao, etc. Hay que decir que este masón nos dejó una riqueza cultural infinita. Creo que el trabajo de programación es similar al de un albañil, es a la vez una tecnología y un arte.
La industria del software moderna ha alcanzado una escala considerable y la finalización de muchos software requiere operaciones de cuerpo a gran escala. Después de que un programador experto acepta la tarea de escribir un artículo, a menudo se limita a escribir código, dejando poco espacio para el desarrollo. En proyectos grandes, muchos programadores solo pueden conocer detalles muy locales relacionados con sus propios módulos y también están limitados por el entorno de desarrollo. Es realmente difícil darse cuenta de que lo que hacen es una creación "artística". Más a menudo, se siente como si estuvieran realizando un trabajo físico pesado. A veces me preocupa si el proyecto en el que estoy trabajando tiene sentido, si es competitivo entre productos similares y si quedará obsoleto debido al desarrollo de hardware y la actualización de los sistemas operativos...
La programación es una actividad técnica, para que pueda realizarse a gran escala, se tendrá la teoría de la ingeniería de software. Precisamente porque la programación tiene las características de la creación artística, hay tantos buenos productos de software en nuestras vidas. Los programas de escritura requieren esfuerzo físico y mental. Cuando yo-nosotros-un grupo completamos un programa, a nuestros ojos, cada programa es una obra de arte...
Las cualidades que los programadores deben poseer.
Prefacio
El programador es un trabajo técnico y juega un papel muy importante en el desarrollo de TI. Desde el establecimiento del protocolo de comunicación de hardware subyacente hasta el procesamiento de la capa de transmisión de datos, la construcción del sistema operativo, la construcción de la plataforma de base de datos y la construcción de varias plataformas de marketing de datos en la capa de aplicación, los programadores juegan Un papel importante en ello. El desarrollo de las tecnologías de la información ha contribuido enormemente.
Hay muchas personas en China que son buenas codificando, pero hay muchos malentendidos en la industria del software de China, especialmente en el desarrollo de aplicaciones de red. Es difícil formar una fuerza de desarrollo de software y capacidades de productos a gran escala. No solo está muy por detrás de Estados Unidos, sino que también está muy por detrás de India. Estos problemas no residen en el coeficiente intelectual y el arduo trabajo de nuestros programadores, ni en la inversión del país y la gente en el desarrollo, sino en gran medida en algunos malentendidos sobre la tecnología, el desarrollo de programas y el diseño de proyectos, que resultan en la falta de productización. en la industria del software Capacidad, falta de capacidades de I + D para sistemas de reutilización a gran escala. Se puede decir que cambiar los malentendidos es una tarea importante para resolver las limitaciones que plantean el modelo de pequeño taller y el modelo de héroe personal en la industria del software.
Hay muchos niños en China. Tienen 18,9 años o 21,2 años respectivamente. También aprendieron por sí mismos a escribir mucho código. Algunos están bellamente escritos, otros tienen detalles técnicos sobresalientes y son fáciles de aprender. Sin embargo, se ven afectados por algunos malentendidos y opiniones, y carecen de una comprensión general de los sistemas y procedimientos. Esta gente, un amigo en línea, lo expresó muy bien. De hecho, son solo algunos fanáticos de la codificación y no están calificados para ser programadores, pero hasta donde yo sé, muchos CTO de pequeñas empresas de Internet son fanáticos de la codificación. El salario es aterrador, los proyectos son aterradores y el final. del proyecto suele dar miedo.
1. Cualidades básicas de los programadores
Ser un programador verdaderamente calificado, o un programador que realmente pueda completar algún trabajo de código, debe poseer las cualidades.
1: Espíritu de equipo y capacidad de cooperación
Considerar esto como una cualidad básica no deja de ser importante. Al contrario, es la base más básica e importante para que un programador se establezca y se gane la vida. No tiene sentido describir a los programadores senior como solitarios. El poder de cualquier individuo es limitado. Incluso un genio como Linus necesita formar un equipo fuerte para crear milagros. Es impensable para aquellos maestros que escriben núcleos para Linux en todo el mundo sin el espíritu de cooperación. Los Llaneros Solitarios pueden ganar algo de dinero creando algún software pequeño, pero una vez que ingresan al equipo de RD de algunos sistemas grandes y se involucran en las tareas de comercialización y desarrollo de productos, las personas que carecen de esta cualidad quedan completamente descalificadas.
2. Hábitos de grabación
Lo cierto es que los programadores senior nunca escriben documentos. Una buena documentación es una parte muy importante del proceso formal de RD. Como programador de codificación, es normal dedicar el 30% de su tiempo de trabajo a escribir documentación técnica, pero como programador senior y analista de sistemas, esta proporción es mucho mayor.
Sin documentación, un sistema de software carecerá de vitalidad y encontrará grandes problemas en la detección de errores, actualizaciones, reutilización de módulos, etc.
3. Hábitos de escritura de código estandarizados y normalizados
Al igual que las reglas de algunas empresas de software extranjeras conocidas, la denominación de las variables en el código, el formato de los comentarios en el código, e incluso la longitud de las líneas anidadas, el número de líneas en blanco entre funciones se especifica claramente. Los buenos hábitos de escritura no solo ayudan a la portabilidad del código y la corrección de errores, sino que también ayudan a la colaboración entre diferentes personales técnicos.
Algunos entusiastas de la codificación claman que otros nunca entenderán el código escrito por programadores experimentados. Este tipo de clamor sólo demuestra que no merecen llamarse programadores. La buena legibilidad del código es un requisito de calidad básico para los programadores.
Echemos un vistazo a la estructura completa de Linux. Sin estandarización y hábitos de codificación estandarizados, la cooperación global en I+D es absolutamente inimaginable.
4. La capacidad de comprender los requisitos
Los programadores necesitan comprender los requisitos de un módulo. Muchos niños tienden a centrarse únicamente en un requisito funcional cuando escriben programas. Atribuyen todos los indicadores de rendimiento al hardware, el sistema operativo y el entorno de desarrollo, ignorando las consideraciones de rendimiento de su propio código. Alguien dijo una vez que escribir un programa de intercambio de anuncios es fácil. Estas personas nunca saben cómo se consiguen los indicadores de rendimiento con millones o incluso decenas de millones de visitas. Para un programador así, no puede hacer mucho con el sistema que le proporciona. Entre los requisitos de rendimiento, son muy importantes la estabilidad, el soporte de acceso paralelo y la seguridad. Como programador, debe evaluar el entorno en el que se ejecutará el módulo, la presión de carga que soportará y la posibilidad de que se produzcan diversos peligros potenciales y ataques maliciosos. En este momento, un programador maduro necesita al menos de 2 a 3 años de experiencia en desarrollo y seguimiento de proyectos.
5. Reutilizabilidad, capacidad de pensamiento modular
A menudo escuchamos a algunos programadores quejarse de que se han convertido en trabajadores calificados después de escribir programas durante varios años. Reescriben código todos los días que no tiene nada nuevo que ofrecer. En realidad, este es el mayor desperdicio de talentos de software chinos. Algunas tareas repetitivas se han convertido en el trabajo principal de programadores expertos, lo cual es completamente evitable.
El diseño reutilizable y el pensamiento modular requieren que los programadores piensen más al completar cualquier módulo funcional o función. No se limitan a ideas simples para completar la tarea actual, sino que piensan si el módulo puede existir de forma independiente. ¿Se puede hacer referencia directamente a este sistema en otros sistemas y entornos de aplicaciones simplemente modificando los parámetros? Esto puede evitar en gran medida el trabajo de desarrollo repetido. Si una unidad de RD de software y un grupo de trabajo pueden considerar estos problemas en cada proceso de RD, los programadores no perderán demasiado tiempo en trabajos repetitivos y tendrán más tiempo y energía para invertir en la innovación.
Algunos buenos códigos de módulos de programas, incluso escritos en la década de 1970, ahora se pueden usar como módulos funcionales en algunos sistemas, pero lo que veo ahora es que muchas pequeñas empresas a menudo actualizan o mejoran el software simplemente reescribiéndolo todo. el código, la mayor parte del trabajo repetitivo es una pérdida de tiempo y energía.
6. Hábitos de prueba
En cuanto a algunos desarrollos comerciales y estandarizados, los ingenieros de pruebas a tiempo completo son indispensables, pero eso no significa que los programadores con ingenieros de pruebas a tiempo completo no puedan hacerlo. sus propias pruebas; como proyecto, una característica muy importante del software RD es que cuanto antes se descubra el problema, menor será el costo de resolverlo. Al probar cuidadosamente cada fragmento de código y cada submódulo, los programadores pueden descubrir y resolver algunos problemas potenciales lo antes posible, garantizando así la eficiencia y confiabilidad de toda la construcción del sistema.
De hecho, las pruebas deben considerar dos aspectos. Por un lado, está la prueba de llamadas normales, que consiste en ver si el programa puede completar funciones básicas en llamadas normales. Esta es la responsabilidad de prueba más básica. Desafortunadamente, se ha convertido en la única tarea de prueba para muchas empresas, pero está lejos de serlo. El segundo aspecto es la prueba de llamadas anormales, como pruebas de estabilidad bajo carga de alto voltaje, pruebas bajo posible entrada anormal del usuario, pruebas del estado afectado del módulo bajo falla parcial de todo el sistema y pruebas de estabilidad del módulo cuando se bloquean solicitudes anormales frecuentes. recursos, etc. Por supuesto, no es necesario que los programadores realicen pruebas tan completas en cada parte de su código, pero los programadores deben conocer la posición de sus tareas de código en todo el proyecto y los diversos requisitos de rendimiento, llevar a cabo pruebas relevantes de manera específica y descubrirlos lo antes posible y solucionar el problema. Por supuesto, esto requiere la capacidad antes mencionada de comprender las necesidades.
7. La capacidad de aprender y resumir
Los programadores son una profesión donde los talentos se pueden eliminar y dejar atrás fácilmente, porque una tecnología puede estar sólo tres o dos años por delante. Si los programadores quieren ganarse la vida, deben mantenerse al día con las nuevas tecnologías y aprender nuevas habilidades.
Ser bueno aprendiendo es una motivación necesaria para cualquier profesión, y este requisito es aún mayor para los programadores.
Pero aprender también requiere encontrar el objetivo. Algunos jóvenes fanáticos de la codificación también hablaron sobre sus habilidades de aprendizaje. Han estado aprendiendo asp, php, jsp por un tiempo. Usan esto como derecho de fanfarronear para perseguir ciegamente algunas cosas y sustantivos superficiales y superficiales, y realizan programas y aplicaciones de red sin comprender el procesamiento de vectores de interrupción. Estos técnicos, por muchos de los llamados nuevos idiomas que dominen, nunca lo harán.
Ser bueno resumiendo también es reflejo de la capacidad de aprendizaje. Cada vez que completa una tarea de investigación y desarrollo o un fragmento de código, debe realizar un seguimiento intencionado del estado de la aplicación del programa y los comentarios de los usuarios, resumirlos en cualquier momento y descubrir sus propias deficiencias. Un programador sólo puede crecer mejorando gradualmente.
Se recomienda no elegir un programador que no haya crecido, aunque actualmente sea un maestro, porque es hora de que se quede atrás.
Las personas con todas las cualidades anteriores deberían ser programadores cualificados. Tenga en cuenta que las cualidades anteriores no están determinadas por el coeficiente intelectual ni pueden aprenderse en algunos libros de texto universitarios. Todo lo que se necesita es que el programador comprenda su trabajo, lo cual es una cuestión de conciencia.
En segundo lugar, un programador/diseñador de proyectos senior también debe poseer las cualidades.
Entonces, como programador senior, o incluso analista de sistemas, es decir, para el diseñador de un proyecto de programa, además de todas las cualidades anteriores, también debe tener las siguientes cualidades:
En primer lugar, la capacidad de analizar las necesidades.
Para los programadores, comprender los requisitos puede completar el código calificado, pero para las organizaciones y administradores de proyectos de RD, no solo deben comprender las necesidades de los clientes, sino también establecer algunos requisitos ellos mismos. ¿Por qué dices eso?
Por lo general, las tareas de RD pueden ser propuestas por los clientes o por el departamento de marketing. En este momento, para el departamento de RD no ven la demanda completa. En términos generales, los requisitos son solo requisitos funcionales o, más formalmente, pueden obtener una vista completa del usuario.
Pero esto no es suficiente, porque los clientes pueden tener dificultades para presentar requisitos de desempeño completos, claros o profesionales debido a factores más no técnicos, pero los organizadores y planificadores de proyectos deben poder reconocer claramente la existencia de estos requisitos. debe proponerse de manera adecuada al completar el informe de análisis de requisitos y debe reflejarse con toda claridad en la especificación de diseño, para que los programadores no pierdan estas pautas al codificar.
Los programadores deben comprender correctamente el entorno en el que existen las necesidades de los usuarios y realizar análisis de demanda específicos. Por ejemplo, el mismo software puede tener diferentes requisitos de rendimiento cuando se alquila y se lanza a través de ASP. El primero enfatiza un mejor soporte y estabilidad, mientras que el segundo puede enfatizar la versatilidad y simplicidad de instalación y uso bajo varias plataformas.
2. Métodos de diseño de proyectos y capacidades de procesamiento de procesos.
Los programadores deben poder dominar al menos dos o tres métodos de diseño de proyectos (como métodos de diseño de arriba hacia abajo, métodos de creación rápida de prototipos, etc.) y poder elegir el apropiado en función de Las necesidades del proyecto y la asignación de recursos llevan a cabo el diseño general del proyecto.
La selección inadecuada de métodos de diseño retrasará el ciclo de RD, desperdiciará recursos de RD e incluso afectará el efecto de RD.
Un programador también necesita dedicar mucho tiempo al diseño y procesamiento de diagramas de flujo. Necesita hacer diagramas de flujo de datos y establecer diccionarios de datos; necesita procesar diagramas de flujo lógicos para formar todo el sistema; flujo de procesamiento.
Un sistema con problemas de proceso, por muy bonito que sea el código y por exquisito que sea cada módulo, no se convertirá en un buen sistema. Por supuesto, para hacer un buen trabajo de análisis de procesos y elegir un buen método de diseño de proyectos, es necesario tener una comprensión suficiente de sus capacidades de análisis de necesidades.
En tercer lugar, reutilizar el diseño y las capacidades de descomposición de módulos.
Esto parece ser lo mismo de siempre. ¿No ha explicado ya la cualidad básica este problema?
Como programador involucrado en tareas modulares, necesita considerar la reutilización de los módulos funcionales específicos que enfrenta, pero como analista de sistemas, los problemas que enfrenta son mucho más complejos. Necesita descomponer el conjunto. sistema en muchos módulos funcionales reutilizables y funciones basadas en una capacidad de análisis modular, y forman un requisito de diseño independiente para cada módulo. Por ejemplo, la producción de automóviles. Inicialmente, cada vehículo se instaló individualmente y cada componente se fabricó a medida. Pero más tarde fue diferente. Fue producido en masa por máquina. Cierta fábrica de automóviles comenzó a producir automóviles a través de líneas de ensamblaje y las piezas independientes comenzaron a tener cierto grado de reutilización. Más tarde, la estandarización se convirtió en una tendencia importante y las autopartes de diferentes modelos, diferentes marcas e incluso diferentes fabricantes podían reemplazarse y actualizarse fácilmente. En este momento, se maximiza la eficiencia de la producción de vehículos. Lo mismo ocurre con la ingeniería de software. En una industria de software madura, se pueden reemplazar diferentes componentes a voluntad en algunos proyectos y sistemas relacionados. Por ejemplo, muchos de los programas de escritorio de Microsoft reutilizan el mismo conjunto de módulos funcionales en muchos módulos operativos (como abrir y guardar archivos). Estas interfaces se proporcionan a los desarrolladores de aplicaciones de escritorio a través de algunas bibliotecas de clases para facilitar la conexión. Prueba clara de diseño.
Descomponer un sistema de aplicación grande y complejo en algunos módulos relativamente independientes y altamente reutilizables. Estos módulos solo necesitan depender de unos pocos parámetros para completar la conexión de datos. Este es un requisito para los programadores y sistemas avanzados. importante trabajo de un analista. Los métodos apropiados de diseño de proyectos y los diagramas de flujo claros son garantías importantes para lograr este objetivo.
4. Capacidad general de evaluación del proyecto
Como diseñador de sistemas, debe poder partir de la situación general y tener una comprensión clara del proyecto general, por ejemplo, si la empresa La asignación de recursos es razonable y está en su lugar, como si el progreso del proyecto puede maximizar la eficiencia y no se puede completar a tiempo. Evaluar la carga de trabajo de todo el proyecto y cada módulo, evaluar los recursos requeridos por el proyecto y evaluar las dificultades que puede encontrar el proyecto requieren mucha acumulación de experiencia. En otras palabras, este es un estado que requiere resumen y acumulación continuos. para lograr. En Occidente, algunos líderes de diseño de sistemas de software son muy mayores, como 40, 50 años o incluso más. Son mucho menos flexibles que los jóvenes cuando se trata de codificación, pero en términos de evaluación de proyectos, sus décadas de experiencia son el activo más importante y valioso.
China carece de esa generación de programadores, principalmente debido a la falta de programadores de esa época, pero porque todos los programadores de esa época fueron producidos en institutos de investigación, no en desarrollo de software de productos profesionales, ni acumularon ese tipo de experiencia en desarrollo de productos. Esto también es un acto de desesperación.
En quinto lugar, capacidades de organización y gestión de equipos.
Para completar un proyecto, el equipo necesita trabajar en conjunto. Como diseñador de proyecto o director de RD, debería poder aprovechar al máximo la fortaleza general del equipo. Debido a su profesionalismo, la gestión técnica se diferencia de la gestión general de personal porque en ella están diseñados algunos indicadores y factores técnicos.
La primera es la cuantificación del trabajo. Sin cuantificación, es difícil lograr una evaluación de desempeño adecuada, y la cuantificación de programas no consiste simplemente en contar el número de líneas de código. Por lo tanto, los gerentes técnicos deben evaluar verdaderamente la complejidad y la carga de trabajo de un módulo.
En segundo lugar, la adaptación del modelo de cooperación en equipo. En términos generales, la cooperación en el desarrollo de programas suele realizarse en grupo, principalmente a la manera de un programador y de forma democrática. De acuerdo con la brecha entre el nivel de habilidad del programador y las necesidades de investigación y desarrollo del proyecto, seleccione un método de formación de equipo apropiado para integrar estrechamente las responsabilidades y derechos con las tareas laborales de los miembros para maximizar la eficiencia de la formación del equipo.
Una persona con un alto nivel de codificación no es necesariamente un director de I+D de proyectos cualificado y, a menudo, se pasa por alto la falta de capacidad en esta área.
En resumen, se puede observar que las cualidades y habilidades requeridas como responsable de RD y diseñador de proyectos no son la capacidad de escribir código de programa. Por supuesto, en circunstancias normales, cuando un programador alcanza esta calidad a través de resumen y mejora continua, su capacidad de escritura de código es bastante simple, pero preste atención a la relación causal. Un diseñador de proyectos de alto nivel suele ser alguien que es muy bueno codificando. Sin embargo, ningún programador que sea bueno en la generación de código puede ser competente en el diseño de proyectos. Lo que existe aquí no es un problema de coeficiente intelectual y libros de texto, o que un programador no se da cuenta de en qué pensar cuando acumula experiencia y mejora gradualmente, y no comprende conscientemente la organización y el diseño de reutilización del proyecto. Sin documentación regular y hábitos resumidos, todavía nos faltan diseñadores de proyectos calificados.
Además, para evitar que la gente aburrida se lo tome en serio conmigo, me gustaría agregar que el objetivo de este artículo es realizar proyectos y proyectos de software comercial. Los programadores de instituciones de investigación científica, como los expertos en algoritmos y los expertos en procesamiento de imágenes, se dedican a proyectos de investigación en lugar de completar directamente software comercial (por supuesto, eventualmente se convertirán indirectamente en productos comerciales, como los proyectos de investigación que realiza Microsoft Research). ), por lo que la cualidad que destacan puede ser otra cosa. No se puede decir que estas personas (expertos) sean programadores.
3. Proceso de diseño para el desarrollo de proyectos de software
Finalmente, ¿cuál es el proceso de diseño para el desarrollo de proyectos de software? Tomemos, por ejemplo, los métodos de diseño estándar habituales (pero a mí me gusta la creación rápida de prototipos).
El primer paso es la investigación de mercado.
La tecnología y el mercado deben combinarse para obtener el mayor valor.
El segundo paso es el análisis de necesidades.
En esta etapa es necesario generar tres cosas: vista de usuario, diccionario de datos y manual de operación del usuario.
La vista de usuario es el estilo de página que los usuarios (incluidos los usuarios finales y los usuarios administrativos) pueden ver y contiene muchos procesos y condiciones operativos.
Un diccionario de datos es algo que señala las relaciones lógicas de los datos y las ordena. Cuando se completa el diccionario de datos, el diseño de la base de datos está completado en más de la mitad.
El manual de operación del usuario es un manual de instrucciones que instruye los procedimientos de operación.
Tenga en cuenta que el proceso de operación del usuario y la vista del usuario están determinados por los requisitos, por lo que deben completarse antes del diseño del software para proporcionar restricciones y pautas para el desarrollo del programa. Desafortunadamente, muchas empresas no hacen esto. La causa y el efecto se invierten, el orden no se distingue y el trabajo de desarrollo y las necesidades reales a menudo se separan.
Análisis de requisitos, además del trabajo anterior, creo que como diseñador de proyectos, es necesario hacer una declaración completa de requisitos de desempeño para el proyecto, porque a menudo los requisitos de desempeño solo pueden ser entendidos por personas que Entender la tecnología, que requiere expertos técnicos y requisitos. Comunicación y entendimiento real entre las partes (clientes o departamento de marketing de la empresa).
El tercer paso es el diseño del esquema.
Los módulos funcionales del sistema se dividen inicialmente y se proporcionan procesos de RD y requisitos de recursos razonables. Como método rápido de creación de prototipos, puede ingresar a la etapa de codificación después de completar el diseño del esquema. Este método generalmente se adopta porque las tareas de RD involucradas pertenecen a un campo nuevo y el director técnico no puede dar una especificación de diseño detallada clara al principio, pero esto no significa que la especificación de diseño detallada no sea importante. De hecho, una vez que el método de creación rápida de prototipos completa el código del prototipo, es necesario volver a realizar pasos de diseño detallados en función de los resultados de la evaluación y las lecciones aprendidas.
El cuarto paso es el diseño detallado.
Este es un nivel importante que pone a prueba el pensamiento de diseño de los expertos técnicos. Las especificaciones de diseño detalladas deben proporcionar a los codificadores módulos específicos de la manera más limpia (estructura de caja negra), maximizando así la modularidad general del sistema. Una buena especificación de diseño detallada puede minimizar la complejidad de la codificación. De hecho, estrictamente hablando, una especificación de diseño detallada debe proporcionar la definición detallada de cada parámetro de cada función. Desde el análisis de requisitos hasta el diseño del esquema y la finalización de las especificaciones de diseño detalladas, un proyecto de software debe estar a medio completar. En otras palabras, un gran sistema de software está a medio terminar antes de que se haya empezado a trabajar en una sola línea de código.
Aquellos programadores que simplemente entienden hacer software como escribir código han cometido errores desde la raíz.
El quinto paso es la codificación.
En un proceso de RD estandarizado, el trabajo de codificación durante todo el proyecto no excederá la 1/2 como máximo, normalmente 1/3. Como dice el refrán, si el proceso de diseño se completa bien, la eficiencia de la codificación mejorará enormemente. La coordinación del progreso y la cooperación entre diferentes módulos son las más cuidadosas al codificar. Tal vez un pequeño problema en el módulo pueda afectar el progreso general, por lo que muchos programadores se ven obligados a dejar de trabajar y esperar. Los planes de comunicación y de contingencia son muy importantes a la hora de codificar. Para los programadores, los errores siempre existirán y deben enfrentar este problema todo el tiempo. ¿La famosa Microsoft lleva tres meses consecutivos sin poder publicar parches? ¡de ninguna manera!
El sexto paso es la prueba.
Existen muchos tipos de pruebas:
Según los diferentes ejecutores de pruebas, se pueden dividir en pruebas internas y pruebas externas.
Según el alcance de la prueba, se puede dividir en prueba de módulo y depuración general.
Según las condiciones de la prueba, se puede dividir en prueba de funcionamiento normal y prueba de situación anormal.
Según el rango de entrada de la prueba, se puede dividir en pruebas de cobertura total y pruebas de muestreo.
Lo anterior es fácil de entender, así que no lo explicaré.
En definitiva, las pruebas también son un paso muy importante en el desarrollo de un proyecto. Para un software de gran tamaño, es normal realizar entre 3 meses y 1 año de pruebas externas, porque siempre habrá problemas impredecibles.
Después de completar las pruebas, la aceptación y la documentación de ayuda final, todo el proyecto llegará a su fin. Por supuesto, habrá actualizaciones, reparaciones, etc. en el futuro. Siempre que no desee engañar al dinero comprando y vendiendo, debe continuar rastreando el estado de ejecución del software y continuar reparándolo y actualizándolo hasta que el software se elimine por completo.
Escribir estos pasos no es nada para presumir, porque para ser honesto, tengo ingeniería de software a mano, que es un curso obligatorio para los estudiantes de informática en la universidad, pero sé que muchos programadores parecen haber estado interesados. en "VC Mastery en 30 días" Algo así. Algunos de ellos son guerrilleros como yo y nunca han estudiado formalmente esta especialidad. Algunos de ellos han obtenido suficientes puntos para devolver estas cosas verdaderamente útiles a sus profesores.
La Internet actual también es muy impetuosa. Algunos fanáticos de la codificación están armando un escándalo y confundiendo las cosas. De hecho, los verdaderos expertos en tecnología rara vez publican en línea. Con tan pocos autores, en realidad no es un maestro. Simplemente no le gusta este tipo de malentendidos y tonterías sobre la tecnología y los programadores, por lo que quiere ponerse de pie y hacer las cosas. También espero que aquellos entusiastas de la codificación que todavía son adictos a algunos errores puedan pensarlo seriamente y seguir el camino correcto.