¿Qué conocimientos necesitan los ingenieros?

Cualidades básicas de los programadores:

Para ser un programador verdaderamente calificado, o un programador que pueda estar verdaderamente calificado para completar algún trabajo de código

debe tener calidad.

1: Espíritu de equipo y capacidad de colaboración

Tomar esto como una cualidad básica no deja de ser importante, al contrario, es lo más básico que deben tener los programadores,

También es la base más importante para establecerse y establecer una vida. Cualquiera que llame solitarios a los programadores de alto nivel es una tontería. El poder de cualquier individuo es limitado. Incluso un genio como Linus necesita formarse a través de

Un equipo fuerte puede crear milagros. colaboración entre expertos que escriben núcleos para Linux en todo el mundo.

El Llanero Solitario puede ganar dinero con un pequeño software y hacer una pequeña fortuna, pero una vez que ingresa al equipo de I + D de algunos sistemas grandes y ingresa a las tareas de comercialización y desarrollo de productos, carece de personas de este calibre. completamente descalificado.

2: Hábitos de documentación

Cualquiera que diga que los programadores de alto nivel nunca escriben documentos es definitivamente un niño ingenuo. Una buena documentación es muy importante en el proceso formal de investigación y desarrollo.

El vínculo importante es que, como programador de códigos, es normal dedicar el 30% del tiempo de trabajo a escribir documentos técnicos. Como programador senior y analista de sistemas, esta proporción es mucho mayor. Sin

documentación, un sistema de software carece de vitalidad y encontrará grandes problemas

en futuras soluciones de problemas, actualizaciones y reutilización de módulos.

3: Estandarización, hábitos estandarizados de escritura de código

Según las reglas de algunas empresas de software extranjeras conocidas, la denominación variable del código, el formato de comentarios dentro del código e incluso anidamiento

La longitud de la sangría de la línea media y el número de líneas en blanco entre funciones están claramente definidos. Los buenos hábitos de escritura no solo ayudarán al trasplante y corrección de errores del código.

>, pero también ayuda a la comunicación entre diferentes personal técnico. Los fanáticos

claman que el código escrito por programadores de alto nivel nunca es entendido por otros. Este clamor solo demuestra que ellos mismos no son dignos de llamarse programadores

. El código tiene buena legibilidad, lo cual es un requisito de calidad básico para los programadores. Si observamos toda la construcción de Linux,

Sin hábitos de codificación estandarizados y estandarizados, la colaboración global en I+D

es absolutamente inimaginable.

4: Capacidad de comprensión de requisitos

Los programadores necesitan comprender los requisitos de un módulo. Muchos niños a menudo solo se centran en un requisito funcional cuando escriben programas. poner rendimiento Todos los indicadores se atribuyen al hardware, el sistema operativo y el entorno de desarrollo, y se ignoran las consideraciones de rendimiento del propio código

Alguien dijo una vez que escribir un programa de intercambio publicitario es fácil, esa gente nunca

No sé cómo lograr indicadores de rendimiento en el caso de millones o incluso decenas de millones de accesos. Para un programador así, incluso si le das el sistema de Deep Blue, no podrá hacerlo. eso. La capacidad de acceder a la cadena de Tai Chi. Entre los indicadores de requisitos de rendimiento, son importantes la estabilidad

, las capacidades de soporte de acceso paralelo y la seguridad. Como programador, usted necesita

evaluar el entorno en el que opera el módulo durante el funcionamiento del sistema. . La presión de carga y la posibilidad de diversos peligros potenciales y ataques maliciosos. En este sentido, un programador maduro necesita al menos 2 o 3 años de experiencia en desarrollo y seguimiento de proyectos para poder adquirir experiencia.

5: Reutilizabilidad, capacidad de pensamiento modular

A menudo se escucha que algunos programadores tienen este tipo de quejas. Después de escribir programas durante varios años, se han convertido en trabajadores calificados y trabajan duro todos los días. Sí

Escribir código repetidamente sin ninguna idea nueva es en realidad el mayor desperdicio de los talentos del software chino. Algunos trabajos repetitivos se han convertido en el trabajo principal de los programadores expertos y, en realidad, estos son completamente evitables.

.

El diseño de reutilización y el pensamiento modular requieren que los programadores piensen más

al completar cualquier módulo funcional o función, y no limitarse a completar la tarea actual. En términos de ideas, piense si. el módulo puede existir fuera de este sistema

y si se puede hacer referencia directamente a él en otros sistemas y entornos de aplicaciones simplemente modificando los parámetros

. Esto puede evitar en gran medida el trabajo de desarrollo repetitivo. Si una unidad de desarrollo de software y un grupo de trabajo pueden considerar estos temas en cada proceso de desarrollo, entonces los programadores no participarán en trabajos de desarrollo repetitivos. Si pierde demasiado tiempo en el trabajo, tendrá más tiempo y energía para dedicar al código innovador. trabajar.

Algunos buenos códigos de módulos de programa, incluso si fueron escritos en la década de 1970, se pueden usar muy bien como módulos funcionales en algunos sistemas.

Pero ahora lo que hemos visto es que. Muchas pequeñas empresas suelen reescribir el código completo tan pronto como se actualiza o mejora su software, y la mayor parte del trabajo repetitivo es una pérdida innecesaria de tiempo y energía.

6: Hábitos de prueba

En cuanto a cierto desarrollo comercial y formal, los ingenieros de pruebas a tiempo completo son indispensables, pero eso no significa que

hay programadores. no necesitan realizar autopruebas si tienen ingenieros de pruebas a tiempo completo como proyecto de desarrollo de software; una característica muy importante 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 una vez completado, se pueden descubrir y resolver algunos problemas potenciales lo antes posible

para mejorar la construcción general del sistema. Se garantiza la eficiencia y la confiabilidad.

El trabajo de prueba en realidad necesita considerar dos aspectos. Por un lado, es la prueba de llamadas normales, es decir, ver si el programa puede

completar funciones básicas en condiciones normales. llamadas. Esta es la tarea de prueba más básica. Desafortunadamente, en muchas empresas, esta se ha convertido en la única tarea de prueba. De hecho, el segundo aspecto está lejos de ser la prueba de llamadas anormales. como estabilidad bajo cargas de alta presión

Pruebas de rendimiento, pruebas en caso de posibles entradas anormales de los usuarios, pruebas del impacto del módulo en caso de falla parcial del sistema general

Estabilidad del módulo cuando solicitudes anormales frecuentes bloquean recursos Pruebas y más. Por supuesto, los programadores no necesitan realizar pruebas tan completas en cada parte de su propio código, pero los programadores deben comprender claramente que sus tareas de código están en el estado general del proyecto y varios requisitos de rendimiento, y realizar pruebas relevantes de manera específica. descubrir y resolver problemas lo antes posible. Por supuesto, esto requiere las capacidades de comprensión de requisitos mencionadas anteriormente.

7: La capacidad de aprender y resumir

Los programadores son una profesión donde los talentos pueden eliminarse y quedarse atrás fácilmente, porque una tecnología puede estar disponible sólo en tres o dos años

Tiene una vanguardia. Si los programadores quieren ganarse la vida, deben realizar un seguimiento constante de las nuevas tecnologías y aprender nuevas habilidades.

Ser bueno aprendiendo es una motivación necesaria para avanzar en cualquier profesión. Para los programadores, este requisito es aún mayor.

Pero también es necesario encontrar el objetivo adecuado para aprender. Algunas codificaciones pequeñas y algunas codificaciones TO son así. Solo algunos fanáticos de la codificación también hablaron sobre su capacidad de aprendizaje en un momento. Después de aprender php

p, aprendieron jsp por un tiempo. Usan esto como una forma de presumir, persiguiendo ciegamente algunas cosas superficiales y superficiales

y sustantivos. No saben cómo hacer programas de red, los protocolos de transmisión de comunicaciones y los programas de aplicación no comprenden el procesamiento de vectores de interrupción. Dicho personal técnico nunca realizará mejoras cualitativas por muchos de los llamados nuevos lenguajes que domine.

Ser bueno resumiendo también es una manifestación 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 solicitud y de los comentarios de los usuarios sobre el programa. En cualquier momento, encuentre sus propias deficiencias y mejore gradualmente. De esta manera, un programador puede crecer.

Aunque un programador que no tiene potencial de crecimiento parezca un maestro a primera vista, se recomienda no elegirlo, porque llegará el momento en que se quedará atrás.

Se debe decir que las personas que tienen todas las cualidades anteriores son programadores calificados. Tenga en cuenta que las cualidades anteriores no están determinadas por el coeficiente intelectual y no se pueden aprender en algunos libros de texto universitarios. Es solo la comprensión del programador sobre su trabajo. , y es una cuestión de conciencia.

Como programador senior, o incluso analista de sistemas, es decir, diseñador de un proyecto de programa

Además de poseer todas las cualidades mencionadas anteriormente, también debes poseer Las siguientes cualidades:

Primero, capacidad de análisis de requisitos

Para los programadores, comprender los requisitos puede completar el código calificado, pero para la organización y gestión de proyectos de I+D

Los gerentes no sólo tienen que comprender las necesidades de los clientes, sino que más a menudo también tienen que formular algunas de sus propias necesidades. ¿Por qué dice eso?

En general, a la hora de realizar tareas de I+D, pueden ser las necesidades planteadas por los clientes, o las necesidades planteadas por los departamentos de marketing y marketing. En este momento, para el departamento de I+D, lo que ven es. no Un requisito completo En términos generales, este requisito es solo algunos requisitos funcionales, o más formalmente, es posible obtener una vista de usuario completa, pero esto no es suficiente, porque

Porque hay más no-. factores técnicos para los clientes, puede resultarles difícil presentar requisitos completos y claros o de desempeño profesional

Pero para los organizadores y planificadores de proyectos, deben poder comprender claramente Ser consciente de la existencia de estos Requisitos y presentarlos adecuadamente al completar el informe de análisis de requisitos. Al mismo tiempo, deben reflejarse completa y claramente en las instrucciones de diseño para facilitar la codificación por parte de los programadores.

Los programadores deben comprender correctamente el entorno en el que se encuentran las necesidades del usuario y realizar un análisis específico de las necesidades. Por ejemplo,

por ejemplo, el mismo software se lanza y pasa a través de ASP. Alquiler Lanzado bajo licencia, los requisitos de rendimiento pueden ser diferentes

El primero enfatiza mejores capacidades de soporte y estabilidad, mientras que el segundo puede enfatizar más en varias plataformas

Universalidad y simplicidad de instalación. y uso.

En segundo lugar, los métodos de diseño de proyectos y las capacidades de procesamiento de procesos

Los programadores deben poder dominar al menos dos o tres métodos de diseño de proyectos (como los métodos de diseño de arriba hacia abajo)

Métodos, como métodos rápidos de creación de prototipos, etc.), y ser capaz de seleccionar métodos de diseño apropiados según las necesidades del proyecto y la asignación de recursos para

el diseño general del proyecto. La selección inadecuada de métodos de diseño retrasará el ciclo de I+D, desperdiciará recursos de I+D e incluso afectará los resultados de I+D.

Un programador también necesita dedicar mucho tiempo al diseño y procesamiento de diagramas de flujo. Necesita hacer diagramas de flujo de datos

para establecer un diccionario de datos que necesita procesar; Diagramas de flujo lógicos para formar un flujo de procesamiento general del sistema. Un sistema con problemas de proceso

por muy bonito que sea el código y lo exquisito que sea cada módulo, no se convertirá en un buen sistema. Por supuesto, hacer un buen trabajo de análisis de procesos y elegir un buen método de diseño de proyectos requiere una comprensión suficiente de las capacidades de análisis de la demanda.

En tercer lugar, el diseño de reutilización y las capacidades de descomposición modular.

Esto parece ser una vieja melodía otra vez, ¿no explicaban las cualidades básicas este problema antes? Como programador involucrado en tareas de módulos, debe considerar la reutilización de los módulos funcionales específicos que enfrenta. Como analista de sistemas, los problemas a enfrentar son mucho más complejos y el sistema general debe descomponerse en muchos funcionales reutilizables. módulos y funciones de acuerdo con una capacidad de análisis modular, y se debe formar un sistema independiente para cada requisito de diseño de módulo.

Por ejemplo, tomemos la producción de automóviles. Al principio, cada automóvil se instalaba de forma independiente y cada componente se hacía a medida.

Pero luego las máquinas cambiaron con la producción en masa. La fábrica comenzó a producir automóviles a través de líneas de montaje, y las piezas independientes

comenzaron a tener cierto grado de reutilización. Posteriormente, la estandarización se convirtió en una tendencia importante, con diferentes modelos, marcas e incluso diferentes fabricantes

Las piezas de automóviles también se pueden reemplazar y actualizar fácilmente. En este momento, se maximiza la eficiencia de la producción de automóviles.

Lo mismo ocurre con la ingeniería de software en una industria de software madura, en algunos proyectos y sistemas relacionados, se pueden reemplazar diferentes

componentes, como muchos software de escritorio de Microsoft. , en muchos módulos de operación (como abrir archivos,

guardar archivos, etc.), se reutiliza el mismo conjunto de módulos funcionales y estas interfaces se proporcionan

a través de alguna clase bibliotecas Facilita la conexión de los desarrolladores de aplicaciones de escritorio, lo cual es una evidencia obvia del diseño del módulo reutilizable

.

Descomponer un sistema de aplicación grande y complejo en una serie de combinaciones de módulos relativamente independientes y altamente reutilizables que puedan completar la conexión de datos basándose solo en unos pocos parámetros es una de las tareas más importantes como programador senior. y analista de sistemas. Los métodos apropiados de diseño de proyectos y los diagramas de flujo claros son garantías importantes para lograr este objetivo.

Cuarto, capacidad de evaluación general del proyecto

Como diseñador de sistemas, debe poder partir de la situación general y tener una comprensión clara del proyecto en su conjunto, como de la empresa

Si la asignación de recursos es razonable y está vigente, por ejemplo, si el cronograma del proyecto puede maximizar la eficiencia sin dejar de completar el proyecto a tiempo

Evaluar la carga de trabajo del proyecto general y de cada módulo, evaluar los recursos necesarios para el proyecto y evaluar las dificultades que puede encontrar el proyecto requieren mucha acumulación de experiencia. En otras palabras, esta es una capacidad acumulativa que se resume constantemente. alcanzó.

Algunos líderes en diseño de sistemas de software en Occidente son muy mayores, como 4, 50 o incluso más. Son muy inferiores a los jóvenes en términos de codificación.

Las personas lo son. Son muy flexibles, pero en lo que respecta a la evaluación de proyectos, sus décadas de experiencia son el activo más importante y valioso. China carece de una generación de programadores de este tipo. La razón principal no es que falten programadores de esa época, sino que los programadores de esa época son básicamente producidos por unidades de investigación y no provienen de la producción de software profesional. p>

pero no han podido acumular experiencia en I+D de productos. No hay nada que puedan hacer al respecto.

En quinto lugar, capacidades de gestión y organización del equipo

Completar un proyecto requiere los esfuerzos concertados del equipo. Como diseñador de proyecto o gerente de I+D, usted debe

Cuándo. Cuando se trata de maximizar la fuerza general del equipo, la gestión técnica, por su carácter profesional, 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 realizar evaluaciones de desempeño adecuadas y la cuantificación del programa no es simple.

Se puede calcular el número de líneas de código. , por lo que se requiere gestión técnica. Las personas deben poder evaluar verdaderamente la complejidad y la carga de trabajo de un módulo

.

El segundo es el ajuste del modelo de colaboración en equipo. En términos generales, la colaboración en el desarrollo del programa generalmente se divide en grupos pequeños con el método del programador principal y el método democrático. entre los programadores y las necesidades de investigación y desarrollo del proyecto, elegir el método de formación de equipos adecuado y poder asignar las responsabilidades y tareas de los miembros. Una estrecha integración puede maximizar la eficiencia del equipo.

Es posible que una persona con altas habilidades de codificación no pueda convertirse en un gerente de I+D de proyectos calificado. La falta de habilidad en esta área a menudo

se ignora fácilmente.

En resumen, se puede ver que, como responsable de I + D y diseñador de proyectos, las cualidades y habilidades requeridas por un diseñador de proyectos no son la capacidad de escribir códigos de programas. En este caso, cuando un programador alcanza esta calidad a través de resumen y mejora continua, su capacidad de escritura de código ya es bastante extraordinaria, pero preste atención a esto

La relación causal interna es que un diseñador de proyectos de alto nivel es Por lo general, ya es un muy buen escritor de códigos, pero eso no significa que un programador con muy buen código pueda ser competente en el trabajo de diseño de proyectos. El problema no es el coeficiente intelectual ni los libros de texto, sino un programador que no se da cuenta de en qué debe pensar cuando escribe. Acumula experiencia y mejora gradualmente. Descubrimos conscientemente la organización y el diseño de reutilización del proyecto, y no tenemos hábitos de documentación regulares y hábitos resumidos, si no los cambiamos, todavía nos falta mucho. 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 hacer proyectos de software comercial

Proyectos e ingeniería. Por ejemplo, los expertos en programación de instituciones de investigación científica, por ejemplo, los expertos en algoritmos, como los expertos en procesamiento de imágenes, su trabajo es investigar temas en lugar de completar directamente software comercial (por supuesto, eventualmente se convertirá en productos comerciales). indirectamente), como Microsoft Research está trabajando en temas de investigación), por lo que la calidad que enfatizan puede ser otra cosa. No se puede decir que estas personas (expertos) sean programadores y no pueden medirse según los estándares de los programadores.

Finalmente, déjame agregar algo. ¿Cuál es el proceso de diseño del desarrollo de un proyecto de software? Tomemos como ejemplo el método de diseño estándar habitual (pero me gusta el método de 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 la demanda. Esta etapa requiere tres cosas, vista del usuario, diccionario de datos y manual de operación del usuario. La vista de usuario es el estilo de página que pueden ver los usuarios del software (incluidos los usuarios finales y los usuarios administrativos), que contiene muchos procesos y condiciones operativos. El diccionario de datos es algo que especifica la relación lógica de los datos y los organiza. Después de completar el diccionario de datos, se completa más de la mitad del diseño de la base de datos. El manual de operación del usuario es un manual de instrucciones que especifica los procedimientos operativos

. 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. Completarlos proporciona restricciones y pautas para el desarrollo del programa. Desafortunadamente, muchas empresas no lo hacen.

La causa y el efecto se invierten y el orden no se distingue. Esto a menudo crea una desconexión entre el trabajo de desarrollo y las necesidades reales.

Análisis de requisitos, además del trabajo anterior, el autor cree que, como diseñador de proyectos, debe completar los requisitos de desempeño del proyecto.

Solicitar especificaciones, porque a menudo los requisitos de desempeño pueden Sólo puede ser entendido por personas que entienden de tecnología, lo que requiere comunicación y comprensión real entre los expertos técnicos y el lado de la demanda (clientes o departamento de marketing de la empresa).

El tercer paso es el diseño del esquema, que inicialmente divide los módulos funcionales del sistema y proporciona procesos de I+D 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 usa porque las tareas de I + D involucradas pertenecen a campos nuevos y el supervisor técnico no puede dar detalles claros al principio. p>no significa que las instrucciones de diseño detalladas no sean importantes. De hecho, una vez que el método de creación rápida de prototipos completa el código del prototipo, se basa en

los resultados de la evaluación y el resumen de la experiencia y las lecciones. También es necesario rehacer los pasos detallados del diseño.

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 instrucciones de diseño detalladas

deben diseñar módulos específicos de la manera más limpia (caja negra). ). Estructura) se proporciona al codificador para maximizar la modularidad general del sistema

; una buena especificación de diseño detallada puede minimizar la complejidad de la codificación. La especificación de diseño debe proporcionar la definición de cada parámetro de cada función en detalle, desde el análisis de requisitos hasta el esquema del diseño y la finalización de la especificación de diseño detallada; un proyecto de software debe decir Medio hecho. En otras palabras, cuando un sistema de software grande está a mitad de camino, aún no se ha iniciado una línea de código. Aquellos que simplemente entienden a los programadores de software como escritores de códigos han cometido un error fundamental.

El quinto paso es la codificación. En un proceso de I+D estandarizado, el trabajo de codificación no ocupará más de

más de la mitad de todo el proceso del proyecto, normalmente 1/3 del total. tiempo, 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 colaboración entre diferentes módulos durante la codificación son quizás los más cuidadosos. Los módulos pequeños pueden afectar el progreso general, lo que obliga a muchos programadores a dejar de trabajar y esperar. Este problema ha ocurrido en muchos procesos de investigación y desarrollo. La comunicación mutua y las soluciones de emergencia al codificar son muy importantes. Para los programadores, siempre habrá errores y siempre debes enfrentar este problema. ¿Alguna vez el famoso Microsoft ha tenido tres errores consecutivos? ¿un parche en un mes?

¡Nunca!

El sexto paso es la prueba.

Hay muchos tipos de pruebas: según el método de ejecución de la prueba, se puede dividir en pruebas internas y pruebas externas, según el alcance de la prueba,

se puede dividir en; la prueba del módulo y la depuración conjunta general; según las condiciones de prueba, se pueden dividir en pruebas en condiciones de funcionamiento normales y pruebas en condiciones anormales según el rango de entrada de la prueba, se pueden dividir en pruebas de cobertura total y pruebas de muestreo; Lo anterior es fácil de entender y no se requieren más explicaciones.

En resumen, las pruebas también son un paso muy importante en el desarrollo de un proyecto. Para un software de gran tamaño, las pruebas externas de 3 meses a 1

año son normales, porque siempre habrá imprevistos. existen problemas.

Después de completar la prueba, completar la aceptación y completar algunos documentos de ayuda finales, el proyecto general llega a su fin. Por supuesto,

serán necesarias actualizaciones, parches, etc. En el futuro, siempre que no quiera pasar un Si desea engañar al dinero operando con Hammer, debe realizar un seguimiento constante del estado operativo del software y continuar reparándolo y actualizándolo hasta que se elimine por completo.

Escribir estos pasos no es un alarde, porque para ser honesto, tengo una copia de "Ingeniería de software" en la mano en la universidad, este es un curso obligatorio para estudiantes de informática, pero sé que muchos. Los programadores parecen haber estado siempre interesados ​​sólo en "30 días para dominar VC" y cosas por el estilo. Algunos de ellos tienen antecedentes guerrilleros como yo y nunca han estudiado formalmente esta especialización, mientras que otros ya lo han hecho. suficientes créditos, le devolví estas cosas realmente útiles al maestro.

Los fanáticos están clamando y confundiendo al público. De hecho, los verdaderos expertos técnicos rara vez publican publicaciones aleatorias en Internet. Personas tan ignorantes como el autor

en realidad no se consideran qué clase de maestro. ¿Es esto? Simplemente no puedo soportar este tipo de malentendidos y tonterías sobre la tecnología y los programadores

, así que tengo que levantarme y corregir el caos. También espero que aquellos que todavía son fanáticos puedan pensar en ello. tómalo en serio y vete.

En el camino correcto, después de todo, esas mentes inteligentes están lejos de ser de su debido valor.

De programador a ingeniero

Actualización de programador a ingeniero La mayoría de las personas como yo, que tienen un gran interés en el software, irán allí sin dudarlo después de graduarse

Entró en el empresa y comenzó su carrera como programador. En ese momento, estábamos obsesionados con libros como "enciclopedias" y "trucos", y solo teníamos códigos en el corazón.

Cuando veo líneas de código aburrido convertidas en un dispositivo que puede hacer llamadas, convertidas en una hermosa mesa en la pantalla, convertidas en hermosa música, surge espontáneamente una sensación de logro. Creo que también soy un excelente programador

. Trabajar duro durante tres días y tres noches en la sala de computadoras del usuario para resolver errores de software se ha convertido en una calificación que se puede presumir. Un día, hace cinco años,

Llegué a Huawei después de entregar una gran cantidad de código y lamentablemente pocos documentos que alguna vez me entusiasmaron y enorgullecieron.

Aquí hay más gente joven. Me siento como pez en el agua y puedo dar rienda suelta a mi imaginación. Sigue siendo código, sigue anotando apresuradamente en papel (lo llamamos documentos) inspiraciones fugaces, sigue luchando sin cesar contra los errores.

Cuando un día un nuevo colega vino a preguntarme cautelosamente, sosteniendo un documento con mi nombre, me encontré con que no parecía reconocerlo. Me sentí un poco frustrado. Cuando volví a mirar el código, descubrí que parte de la inspiración registrada en el documento había cambiado hasta quedar irreconocible. No sabía cómo se sentía el nuevo colega en ese momento, pero a partir de entonces me pareció darme cuenta de algo.

Mirando ahora hacia atrás, muchas cosas en aquel momento eran la mitad del resultado con la mitad del esfuerzo.

También conocí a mi jefe de proyecto, un joven alto y delgado que se dice que acaba de regresar de Estados Unidos y ha estado trabajando allí durante cinco o seis años. Me alegré mucho después de escuchar esto y esta vez quería aprender ambos movimientos uno por uno. El análisis de requisitos duró un mes. El director del proyecto discutió con nosotros (en realidad en nombre del cliente) el contenido de la propuesta y determinó que todos los elementos eran necesarios. Luego dividió aproximadamente los módulos y comenzó a entrar en la etapa de aprendizaje planificado. Durante la etapa de aprendizaje, todos tienen que escribir una película de descripción funcional y explicarla a los demás. Inconscientemente, todos en el equipo del proyecto tienen una comprensión general del proyecto.

También organizó algunas capacitaciones, como el modelo de desarrollo de software de su empresa y la definición de cada rol en el equipo del proyecto. En el futuro,

la capacitación oportuna continuará, siempre y cuando. Hay demanda en el equipo del proyecto. Siempre invita a QA o personas relacionadas y la capacitación es muy profesional.

Después de completar el análisis de requisitos, envié un documento de más de 40 páginas. Cuando vi que las partes que escribí en este documento en inglés estaban claramente enumeradas.

En ese momento, Mis sentimientos eran muy complicados, algo de alegría, pero más de amargura. ¿Por qué nunca antes había hecho ese análisis de necesidades?

Cuando estaba escribiendo el documento, QA nos capacitó en la plantilla de escritura SRS. Más tarde, todavía estaba preocupado y les pregunté.

Un ingeniero experimentado escribió un párrafo y pensamos. vuelve a hablar de ello y escríbelo. Aunque este SRS fue coescrito por varias personas, tiene el mismo estilo y contenido detallado. Lo que es aún más valioso es que el contenido de este análisis de requisitos no se cambió hasta el final, por lo que no tuvimos la oportunidad de pasar por el proceso de cambio de requisitos.

El análisis de requisitos es la primera etapa del proyecto, y el tiempo de desarrollo de la segunda etapa debe determinarse en función de los resultados del análisis de requisitos.

Cuando el director de tecnología de la otra parte (equivalente al líder general del equipo de nuestro departamento comercial) vino a discutir el plan con nosotros, ya habían enumerado

las líneas de código para cada módulo. Número de predicciones y posibles riesgos. Basándose en la productividad de su empresa de 300

trabajos/persona-mes, calculó cuántas semanas tomaría la segunda fase del proyecto.

En ese momento planteamos objeciones: 1) La empresa tiene una necesidad urgente del proyecto; 2) ¿300 líneas por mes son pocas?

¿También tenemos las descargas? consulte el código fuente. Explicó que 300 líneas/persona-mes es el dato empírico que permite al proyecto cumplir con sus estándares de calidad. Considerando la referencia del código fuente, la productividad no puede exceder las 350 líneas/persona-mes como máximo.

Cuando me preguntó sobre la productividad de nuestra empresa, lo pensé tres veces y no me atreví a decir más. Probablemente eran seiscientas o setecientas líneas.

Se quedó en silencio por un momento y luego dijo con firmeza: nuestro plan se basa en garantizar la calidad. Creo que cuando vienes a la India a desarrollar software, lo primero que buscas es nuestra empresa india.

Garantía de calidad. .

Sé que no te faltan desarrolladores de software, ¿por qué no eliges software descargable? Unas pocas palabras

Hablando de mi problema, ¡los hermanos en China todavía están buscando productos trasplantados usando software descargado!

Las actividades de desarrollo posteriores fueron ordenadas y las seguimos honestamente. Plan de pruebas del sistema, casos de uso, diseño general

Plan de pruebas de integración, casos de uso, diseño detallado, plan de pruebas unitarias, casos de uso, codificación, pruebas unitarias, pruebas de integración

pruebas, sistema pruebas. Un proceso completo de desarrollo de modelos en V, con revisiones para cada proceso. Cuando no entendíamos bien algunos métodos de diseño

el director del proyecto nos envió información relevante, no sé qué estaba pensando en ese momento

Algunos análisis básicos y. Los métodos de diseño se mencionaron en libros de ingeniería de software hace diez o incluso veinte años. Estos contenidos son obligatorios para todos los estudiantes de informática en la India. Además de estar familiarizados con los códigos de algunos protocolos específicos, parece que no sabemos nada sobre estos métodos comúnmente utilizados. Me sentí un poco avergonzado, así que fui directamente a la librería de la ciudad y encontré los libros que me había enumerado. Me acosté en la cama por la noche y los estudié detenidamente. Parecía que de repente conocí a una buena persona que podía darme algunos. guía y amigo

. Ahora la India ha creado una fuerte atmósfera de aprendizaje. Después de mi regreso, también promocioné más de 700 libros. Estos libros nos enseñan cómo desarrollar software utilizando métodos de ingeniería. Son materiales de lectura obligada para convertirse en ingeniero de software.

Nuestro gerente de proyectos tiene fuertes capacidades de planificación y control cuando sucede algo que afecta el plan del proyecto, como

dimisión de personal, reubicación del laboratorio o falta de predicción de un determinado. Módulo Preciso (este módulo es lo que predecimos), siempre toma las medidas necesarias para reducir retrasos y ajustar los planes. Al principio teníamos algunas objeciones a que bajaran a tomar café a las 11 a. m. y a las 4 p. m. todos los días.

También empezamos a tomar café más tarde. Resultó que los intercambios con el café fueron muy ricos, desde luego. Desde la gestión de proyectos hasta los métodos de diseño, que abarcan todo, desde el desarrollo técnico hasta las costumbres locales, son muy útiles para nuestra comprensión mutua y la atmósfera del equipo. El control de calidad de nuestro proyecto también apareció frente a nosotros en el momento apropiado, y solo teníamos una comprensión perceptiva de su trabajo.

Cada vez que asiste a una reunión, siempre tiene una lista de verificación en la mano. El director del proyecto prepara la información correspondiente.

Para responder algunas preguntas, marca las casillas o escribe la explicación del director del proyecto. También fue muy paciente al darnos capacitación, lo que demostró muy buen profesionalismo. Aún extraño la ayuda que nos brindó.

Me dedico al desarrollo de software durante nueve años, pero todavía no puedo decir que sea un ingeniero de software calificado

Y mucho menos un gerente calificado. Vi un informe de que una organización autorizada en Lausana, Suiza, movió la competitividad integral de China en ciencia y tecnología del lugar 13 original a más del 20 porque ajustó algunos criterios de evaluación. Uno de ellos es la disponibilidad de ingenieros calificados en China. es muy bajo. Pensando en los ojos rojos de los hermanos y las figuras cansadas que corren en busca de actualizaciones

Tengo un fuerte deseo: ¡actualicemos rápidamente para convertirnos en ingenieros calificados!