¿Qué conocimientos necesitan los ingenieros?

Conviértete en un programador verdaderamente calificado o sé capaz de completar algo verdaderamente calificado.

Cualidades que deben poseer los programadores que crean código.

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

No deja de ser una cualidad básica, al contrario, es lo más básico que deben tener los programadores.

También es la base más importante para sentar cabeza y sentar cabeza. Cualquiera que llame solitarios a los programadores de alto nivel está diciendo tonterías sobre cualquier poder personal.

Los números son limitados e incluso un genio como Linus necesita pasar.

Forma un equipo fuerte y crea milagros. Los expertos que escriben núcleos para Linux en todo el mundo no tienen ningún espíritu de cooperación.

Inimaginable. Un llanero solitario puede ganar algo de dinero creando un pequeño software, pero una vez que se dedica a la investigación de algunos sistemas grandes, carece de la capacidad para desarrollar un equipo y emprender tareas de comercialización y productización.

Calidad la gente está completamente descalificada.

2. Hábitos de grabación

Aquellos que dicen que los programadores senior nunca escriben documentos deben ser jóvenes. Una buena documentación es I+D formal.

Una parte muy importante del proceso Como programador de códigos, es normal dedicar el 30% del tiempo de trabajo a escribir documentos técnicos, y

Como programador senior y analista de sistemas. , esta proporción es mucho mayor. Carencia

Sin documentación, un sistema de software carecerá de vitalidad, lo que se encontrará en futuras detección de errores, actualizaciones y reutilización de módulos.

Es muy problemático.

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 anidar.

La longitud de la sangría de línea y el número de líneas en blanco entre funciones están claramente definidos. Los buenos hábitos de escritura ayudan con algo más que código.

La portabilidad y la corrección de errores también facilitan la cooperación entre diferente personal técnico. Los fanáticos claman que el código escrito por programadores experimentados nunca será entendido por otros. Este tipo de clamor sólo demuestra que no son dignos de llamarse a sí mismos.

Programador. La buena legibilidad del código es un requisito de calidad básico para los programadores. Si observamos toda la estructura de Linux,

sin hábitos de codificación estandarizados y normalizados, 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.

Los científicos 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 se jactó una vez de que escribir un programa de intercambio de anuncios es muy sencillo. ¿De dónde viene esa gente?

No sé cómo se logra el índice de rendimiento cuando hay millones o incluso decenas de millones de visitas. Para tal proceso,

secuenciador, si le asigna el sistema Deep Blue, no podrá lograr la capacidad de acceso paralelo de la cadena Taichi. Entre los requisitos de rendimiento, la estabilidad

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

evaluar el entorno operativo, la presión de carga y varios módulos del sistema. sistema potencialmente peligroso y malicioso.

Posibilidad de ataque. En este momento, un programador maduro necesita al menos de 2 a 3 años de experiencia en desarrollo y seguimiento de proyectos.

Es posible aprender algo.

5. Reutilizabilidad, capacidad de pensamiento modular

A menudo se escucha que algunos programadores se quejan de que han escrito programas durante varios años y se convierten en trabajadores calificados, todos los días.

La escritura repetitiva de código sin nuevas ideas es en realidad el mayor desperdicio de talentos de software chinos y tiene un cierto grado de repetición.

El trabajo se ha convertido en el trabajo principal de los programadores cualificados y, de hecho, esto es totalmente posible.

Para evitarlo.

El diseño reutilizable y el pensamiento modular requieren que los programadores completen cualquier módulo o función funcional.

Piensa más, no te limites a la simple idea de completar la tarea actual, piensa si el módulo se puede separar de este departamento.

Si el sistema existe, ¿se puede hacer referencia directa a él en otros sistemas y entornos de aplicaciones simplemente modificando los parámetros?

Si una unidad de desarrollo de software y un grupo de trabajo pueden desarrollarlo cada vez, Entonces se pueden evitar en gran medida los esfuerzos de desarrollo duplicados.

Estas cuestiones se tienen en cuenta durante el proceso, por lo que los programadores no perderán demasiado tiempo en trabajos repetitivos y dedicarán más tiempo y energía.

En trabajo de código innovador.

Algunos buenos códigos de módulos de programas incluso se escribieron en la década de 1970 y ahora se incorporan a algunos sistemas como si funcionaran.

Todos los módulos funcionales encajan bien, pero lo que veo ahora es que muchas pequeñas empresas siempre están actualizando o mejorando su software.

Reescritura de código, la mayor parte del trabajo repetitivo es una pérdida innecesaria de tiempo y energía.

6. Hábitos de prueba

Con el desarrollo de cierta comercialización y estandarización, los ingenieros de pruebas a tiempo completo son indispensables, pero esto no significa que

Con un ingeniero de pruebas a tiempo completo, los programadores pueden dejar de autocomprobar el desarrollo de software como un proyecto. Una característica muy importante es que cuanto antes se descubra el problema, menor será el costo de resolverlo y más programas habrá.

Los miembros han probado cuidadosamente cada fragmento de código y cada submódulo una vez finalizado y pueden intentar evitar posibles problemas lo antes posible.

El descubrimiento y la solución del sistema garantizarán la eficiencia y confiabilidad de toda la construcción del sistema.

De hecho, las pruebas deben considerar dos aspectos. Por un lado, es 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, pero en muchas empresas es la única prueba.

La tarea intentada es en realidad muy diferente; el segundo aspecto es la prueba de llamadas anormales, como la estabilidad bajo carga de alto voltaje.

Pruebas de rendimiento, que prueban el fallo parcial de todo el sistema en el caso de una entrada del usuario potencialmente anormal y del módulo afectado.

Pruebas condicionales, pruebas de estabilidad del módulo cuando solicitudes anormales frecuentes bloquean recursos, etc. Por supuesto, esto no significa que los programadores deban verse a sí mismos correctamente.

Cada fragmento de código debe probarse por completo, pero los programadores deben comprender las tareas de su código.

El estado y los diversos requisitos de rendimiento del proyecto individual, llevar a cabo experimentos relevantes de manera específica y descubrir y resolver problemas lo antes posible.

Sin embargo, esto requiere comprender el requisitos mencionados anteriormente.

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 durar sólo tres o dos años.

Con una posición de liderazgo interna, los programadores deben mantenerse al día con las nuevas tecnologías y aprender nuevas habilidades si quieren ganarse la vida.

Ser bueno aprendiendo es una motivación necesaria para progresar en cualquier profesión. Para los programadores, este requisito es aún mayor. Pero el aprendizaje también requiere encontrar el objetivo correcto, como es el caso de cierta codificación pequeña y algo de codificación TO.

Incluso algunos Cfans también hablaron sobre su capacidad de aprendizaje. Aprendieron asp por un tiempo y ph por un tiempo.

p. Después de un tiempo, después de aprender jsp, lo consideraron como un medio para lucirse y persiguieron ciegamente algunas cosas superficiales y superficiales.

Xihe sustantivo, no conoce el protocolo de transmisión de comunicación como programa de red, ni conoce el procesamiento de vectores de interrupción como programa de aplicación.

No importa cuántos de los llamados nuevos idiomas domine una persona, nunca mejorará cualitativamente.

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, siempre debe realizar un seguimiento intencionado del estado de la aplicación del programa y los comentarios de los usuarios, resumir en cualquier momento, descubrir sus propias deficiencias y hacerlo uno por uno.

Paso a paso, un programador puede crecer.

Se recomienda no elegir un programador que no haya crecido, aunque actualmente sea un maestro, porque se ha quedado atrás.

Ya casi es hora. Una persona con todas las cualidades anteriores debería ser un programador calificado. Tenga en cuenta lo anterior.

Diversas cualidades no están determinadas por el coeficiente intelectual ni pueden aprenderse en algunos libros de texto universitarios. Todo lo que se necesita es el programa.

La comprensión de los empleados sobre su trabajo es una cuestión de conciencia.

Tanto 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 es necesario poseer las siguientes cualidades:

En primer lugar, capacidad de análisis de necesidades.

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 solo deben comprender las necesidades del cliente, sino también preguntar siempre por sus necesidades. ¿Por qué dices eso?

Por lo general, las tareas de I+D pueden ser propuestas por los clientes o por el departamento de marketing.

Pues en este momento, para el departamento de I+D, lo que ven no es una demanda completa. En términos generales, los requisitos son solo

algunos requisitos funcionales, o más formalmente, se puede obtener una vista de usuario completa, pero esto no es suficiente, porque

para los clientes, debido a más; Hay muchos factores no técnicos y puede resultarles difícil presentar requisitos de desempeño completos y claros o profesionales.

Sí, pero para el organizador y planificador del proyecto, debe poder comprender claramente la existencia de estos requisitos y completarlos.

A la hora de buscar informes de análisis, estos deben presentarse de forma adecuada y reflejarse completa y claramente en las especificaciones de diseño para facilitar el proceso.

Estos criterios no se pierden cuando el secuenciador codifica.

Los programadores deben comprender correctamente el entorno en el que se ubican las necesidades de los usuarios y realizar análisis de demanda específicos, como

En otras palabras, el mismo software lanzado a través del alquiler y la licencia de ASP puede satisfacer las necesidades de rendimiento. existir.

La diferencia es que el primero enfatiza mejores capacidades de soporte y estabilidad, mientras que el segundo puede poner más énfasis en varias plataformas.

Versatilidad y sencillez de instalación y uso.

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 el diseño de arriba hacia abajo)

métodos, como la creación rápida de prototipos. ), y ser capaz de seleccionar métodos de diseño apropiados según los requisitos del proyecto y la asignación de recursos.

El diseño general de la línea de pedido. La selección inadecuada de métodos de diseño retrasará el ciclo de I+D, desperdiciará recursos de I+D e incluso afectará la eficiencia de la I+D.

Buenos resultados en 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.

Establezca un diccionario de datos; necesita procesar el diagrama de flujo lógico para formar todo el flujo de procesamiento del sistema. Hay un problema con el proceso

El sistema, por muy bonito que sea el código o por exquisito que sea cada módulo, no se convertirá en un buen sistema. Por supuesto, haz el proceso.

Analizar y seleccionar un buen método de diseño de proyectos requiere una buena comprensión de las capacidades de análisis de requisitos.

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 esclavo

Como programador de tareas de módulos, debe considerar la reutilización de los módulos funcionales específicos que enfrenta, y como

analista de sistemas debe enfrentar el problema correcto Es mucho más complejo y requiere un enfoque modular para analizar todo el sistema.

La fuerza se descompone en muchos módulos y funciones funcionales reutilizables, y cada módulo forma un requisito de diseño independiente. Rise

Por ejemplo, tomemos la producción de automóviles. En los primeros días, cada automóvil se instalaba de forma independiente y cada componente se hacía a medida.

Pero las cosas cambiaron después y la máquina se produjo en masa. Una fábrica de automóviles comienza a producir automóviles a través de líneas de montaje, departamentos separados.

Las piezas empezaron a tener cierto grado de reutilización, y posteriormente la estandarización se convirtió en una gran tendencia, con diferentes modelos, diferentes marcas e incluso diferentes fabricantes.

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

Lo mismo ocurre con la ingeniería de software. Una industria de software madura es diferente en algunos proyectos y sistemas relacionados.

Los componentes se pueden reemplazar a voluntad. Por ejemplo, en muchos software de escritorio de Microsoft, el mismo conjunto de módulos funcionales se reutiliza en muchos módulos de operación (como abrir archivos,

guardar. archivos, etc.). Interfaz

A través de algunas bibliotecas de clases, es conveniente para los desarrolladores de aplicaciones de escritorio conectarse, lo que se refleja claramente en el diseño de módulos reutilizables.

Una evidencia.

Descomponer un sistema de aplicaciones grande y complejo en algunos sistemas de aplicaciones relativamente independientes y altamente reutilizables.

Y solo puede confiar en unos pocos parámetros para completar la combinación del módulo de conexión de datos, que es para programadores senior y analistas de sistemas.

El trabajo más importante, los métodos adecuados de diseño del proyecto 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, como la empresa.

Si la asignación de recursos es razonable y está vigente, por ejemplo, si el progreso del proyecto puede maximizar la eficiencia y no cumple con los requisitos de progreso.

Listo. Evalúe la carga de trabajo de todo el proyecto y cada módulo, evalúe los recursos necesarios para el proyecto y evalúe los problemas que pueda encontrar el proyecto.

Las dificultades requieren mucha acumulación de experiencia. En otras palabras, este es un estado que solo se puede lograr mediante resumen y acumulación continuos. Hay

Algunos líderes de diseño de sistemas de software occidentales que son muy mayores, como 4, 50 o incluso mayores, y están en codificación.

A primera vista, son mucho menos activos que los jóvenes, pero en términos de evaluación de proyectos, sus décadas de experiencia acumulada son el activo más

más importante y valioso. China carece de esa generación de programadores. La razón principal no es la falta de programadores de esa época, sino que los programadores de todas las edades son básicamente investigados y no desarrollados por software de productos profesionales.

Sí, no tienen experiencia en el desarrollo de productos y no pueden hacer nada al respecto.

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 o director de proyectos de I+D, debería

Cuando se tiene la capacidad de maximizar la fuerza general del equipo, la gestión técnica se diferencia de la gente común debido a su naturaleza profesional.

Gestión, porque existen unos indicadores técnicos y un diseño factorial.

La primera es la cuantificación del trabajo. Sin cuantificación, es difícil implementar evaluaciones de desempeño apropiadas y la cuantificación de los procedimientos no es sencilla.

El número de líneas de código se puede contar, por lo que los administradores técnicos deben poder evaluar verdaderamente la complejidad y el trabajo de un módulo.

Medición.

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 dividirse en pequeños grupos.

El grupo tiene un modo de programador principal y un modo democrático, basado en la brecha de nivel de habilidad entre los programadores y en base a elementos.

El objetivo es adaptarse a las necesidades de investigación y desarrollo, elegir un método de formación de equipos adecuado y combinar las responsabilidades y derechos de los miembros.

El trabajo y las tareas están estrechamente integrados para maximizar la eficiencia de la formación de equipos.

Una persona con un alto nivel de codificación puede no ser un director de I+D de proyectos cualificado y su capacidad en esta área es deficiente.

En el pasado era fácil ignorarlo.

En resumen, podemos ver qué cualidades se requieren para ser un líder de I+D y diseñador de proyectos.

Y la habilidad no es la capacidad de escribir código de programa. Por supuesto, en términos generales, un programador mejora a través de un resumen continuo.

Cuando alcanza esta calidad, su capacidad para escribir código ya es bastante simple, pero preste atención a esto.

En la relación causal, un diseñador de proyectos de alto nivel suele ser un muy buen escritor de códigos, pero

ningún programador con un código excelente puede ser competente en el diseño de proyectos, lo hay. no hay sabiduría en ello.

El problema de los materiales empresariales y didácticos es que cuando un programador acumula experiencia y va mejorando poco a poco no se da cuenta de que debe pensar.

En cuanto a qué tipo de cosas probar, no existe un pensamiento consciente sobre la organización y el diseño de reutilización del proyecto, y no existe un documento regular.

Si no cambiamos nuestros hábitos y hábitos resumidos, todavía tendremos escasez de diseñadores de proyectos calificados.

Además, para evitar que gente aburrida se tome las cosas en serio conmigo, me gustaría añadir que este artículo está dirigido a proyectos de software comercial.

Proyectos e ingeniería, programadores en instituciones de investigación científica, como expertos en algoritmos, como expertos en procesamiento de imágenes, su trabajo.

Es un tema de investigación en lugar de completar directamente un software comercial (por supuesto, eventualmente se convertirá indirectamente en un producto comercial,

como el proyecto de investigación realizado por Microsoft Research), por lo que enfatizan que la calidad puede ser otra cosa.

No se puede decir que algunas personas (expertos) sean programadores y no pueden medirse según los estándares de los programadores.

Finalmente, ¿cuál es el proceso de diseño para desarrollar un proyecto de software? En los métodos de diseño estándar habituales, por ejemplo (pero 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 la demanda, que requiere tres cosas: vista del usuario, diccionario de datos y operación del usuario.

Hacer un manual. La vista de usuario es un estilo de página que los usuarios de software (incluidos los usuarios finales y los usuarios administrativos) pueden ver. Contiene muchos procesos y condiciones operativos. El diccionario de datos es una herramienta que señala las relaciones lógicas de los datos y las organiza.

Dong, cuando se completa 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 explica los procedimientos operativos.

Explicación. Tenga en cuenta que el flujo de operaciones del usuario y las vistas de los usuarios están determinados por los requisitos y deben incluirse en el diseño del software.

La realización de estas tareas proporciona limitaciones y estándares para el desarrollo del programa. Desafortunadamente, muchas empresas no lo hacen.

Causa y efecto se invierten y el orden es irrelevante. Por lo tanto, el trabajo de desarrollo y las necesidades reales suelen estar separados.

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

Solicite instrucciones, porque a menudo los requisitos de rendimiento solo los entienden personas que entienden de tecnología, y se necesitan expertos técnicos y exigentes.

(El departamento de marketing del cliente o de la empresa) puede tener comunicación y comprensión reales.

El tercer paso es el diseño del esquema, que inicialmente divide los módulos funcionales del sistema y proporciona procesos y recursos de I+D razonables.

Requisitos. Como método rápido de creación de prototipos, se puede ingresar a la fase de codificación después de completar el diseño general, que generalmente se adopta.

El método se debe a que las tareas de I+D involucradas pertenecen a un campo nuevo y es imposible para el director técnico dar una teoría de diseño clara y detallada de inmediato.

Esto no significa que las especificaciones detalladas de diseño no sean importantes. De hecho, una vez completado el código del prototipo, el método de creación rápida de prototipos echa raíces.

Con base en los resultados de la evaluación y las lecciones aprendidas, se deben realizar nuevamente los pasos de diseño detallados.

El cuarto paso es el diseño detallado, que es un nivel importante que pone a prueba el pensamiento de diseño de los expertos técnicos y proporciona instrucciones de diseño detalladas.

Se deben proporcionar módulos específicos a los codificadores de la manera más limpia (estructura de caja negra) para que todo el sistema pueda modularizarse.

Alcance el valor máximo; una buena especificación de diseño detallada puede minimizar la complejidad de la codificación, que en realidad es estricta.

Las especificaciones de diseño detalladas deben proporcionar la definición de cada parámetro de cada función en detalle de acuerdo con los requisitos.

Desde el análisis hasta el esquema del diseño y la finalización de las especificaciones de diseño detalladas, un proyecto de software debe Estar a medio hacer. En otras palabras:

Cuando un sistema de software grande está a mitad de camino, una línea de código en realidad no ha comenzado a funcionar. Aquellos que lo tratan como un softie

Un programador que simplemente lo entiende como escribir código ha cometido un error desde la raíz.

El quinto paso es la codificación. En un proceso de I+D estandarizado, la codificación no será lo más común durante todo el proyecto.

Si excede la mitad, generalmente 1/3, el llamado afilado no se escapa y la eficiencia de codificación del proceso de diseño también aumentará.

Muy mejorado, la coordinación del progreso y la cooperación entre diferentes módulos son las más cuidadosas al codificar, tal vez un módulo pequeño.

El problema puede afectar el progreso general, por lo que muchos programadores se ven obligados a dejar de trabajar y esperar. Este es un problema en muchos estudios.

Ya aparece en el proceso capilar. La comunicación mutua y los planes de contingencia durante la codificación son muy importantes para los programadores.

En términos generales, los errores siempre existirán y tendrás que enfrentar este problema todo el tiempo. ¿El famoso Microsoft ha estado ausente durante tres meses seguidos?

¿Cuándo se lanzará el parche? ¡de ninguna manera!

El sexto paso es la prueba.

Hay muchos tipos de pruebas: según el ejecutor de la prueba, se puede dividir en pruebas internas y pruebas externas, según el alcance de la prueba,

se puede dividir en módulo; pruebas y depuración general según el documento de prueba, se puede dividir en prueba de funcionamiento normal y prueba de condiciones de trabajo anormales.

Pruebas; 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 y no se repetirá.

Explícalo.

En definitiva, las pruebas también son un paso muy importante en el desarrollo del proyecto. Un software grande tarda 3 meses en construirse.

Las pruebas externas en 2008 son normales, porque siempre habrá problemas impredecibles.

Después de las pruebas, la aceptación y alguna documentación de ayuda final, todo el proyecto, por supuesto, llega a su fin.

Habrá actualizaciones, mantenimiento y otros trabajos en el futuro. Siempre que no quieras hacer trampa con dinero en una sola transacción, debes seguir rastreando el software.

La salud del software y continúa siendo reparado y actualizado hasta que el software esté completamente obsoleto y

se detenga.

Escribir estos pasos no es nada para presumir, porque para ser honesto, tengo un libro "Ingeniería de software" en la mano, que leí en la universidad.

Este es un curso obligatorio para estudiantes de informática, pero sé que muchos programadores siempre parecen estar interesados ​​en la "Esencia de 30 días"

Pase VC y similares, algunos lo son. Al igual que yo, los guerrilleros nunca han estudiado formalmente esta especialidad, y algunos lo han hecho en una etapa temprana.

Después de obtener suficientes créditos, le devolví estas cosas realmente útiles al profesor.

Los fans gritaban y gritaban para confundir al público. De hecho, los verdaderos expertos técnicos rara vez publican en línea, como el autor.

He plantado un poco, pero en realidad no soy un maestro, simplemente no me gusta esta tecnología, para programadores.

Fue un malentendido y una tontería. No tuve más remedio que levantarme y explicar el asunto claramente. Espero que esos fans puedan pensarlo seriamente y marcharse.

Después de todo, en el camino correcto, esas mentes inteligentes están lejos de desempeñar el papel que les corresponde.

De programadores a ingenieros

De programadores a ingenieros, la mayoría de las personas que están tan interesadas en el software como yo no dudan después de graduarse.

Entré a la empresa y comencé mi carrera como programador. En aquella época estábamos obsesionados con las enciclopedias, los manuales secretos y otros libros.

Solo tengo código en mi corazón. Cuando veo líneas de código aburrido convertidas en un dispositivo que puede realizar llamadas, queda flotando en la pantalla.

La mesa luminosa se convirtió en una hermosa música y una sensación de logro surgió espontáneamente. Creo que también soy un buen 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 de jactancia. en algún lugar hace cinco años.

Un día llegué a Huawei después de entregarme un montón de código y varios documentos que alguna vez me emocionaron y enorgullecieron.

Hay muchos jóvenes en esta escuela, así que me siento cómodo y puedo dar rienda suelta a mi imaginación. Todavía código, todavía tengo prisa.

La inspiración fugaz escrita a toda prisa en un papel (lo llamamos documento) sigue luchando sin cesar contra los errores.

Cuando un día, un nuevo colega vino a interrogarme atentamente con un documento con mi nombre, me encontré

No parecía saberlo. Me sentí un poco deprimido y luego miré el código y descubrí que parte de la inspiración registrada en el documento se había vuelto irreconocible. No sé cómo fue ser un nuevo compañero de trabajo, pero parece que me he dado cuenta de algo desde entonces.

Mirando ahora hacia atrás, muchas cosas en aquella época se hacían con la mitad de esfuerzo.

También conocí a mi director de proyecto, un joven alto y delgado que, según se decía, acababa de regresar de Estados Unidos.

Trabajó cinco o seis años. Estoy muy feliz de escuchar esto. Esta vez quiero aprender ambas habilidades una por una. El tiempo requerido para el análisis de necesidades es uno.

El mes pasado, el director del proyecto discutió el contenido de la propuesta con nosotros (en realidad, en nombre del cliente) y se aseguró de que todos los elementos fueran

requeridos. Luego, dividió aproximadamente los elementos. módulos y comencé a ingresar a Planificar la fase de aprendizaje. Todos están en clase de estudio.

Duan quiere escribir un vídeo que describa la función y explicársela a otros. Antes de que te des cuenta, todos los miembros del equipo del proyecto tienen un proyecto completo.

Comprensión del cuerpo.

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. Posteriormente se continuó con la capacitación oportuna.

Siempre que el equipo del proyecto tiene necesidades, siempre invita a QA o personas relacionadas, y la capacitación es muy profesional. Obligatorio

Una vez completado el análisis, envié un documento de más de 40 páginas. Cuando vi el documento en inglés, escribí todas las partes claramente.

Cuando me incluyeron en él, mi estado de ánimo fue mixto, con algo de alegría, pero más de amargura, que nunca antes había sentido.

¿Ha realizado dicho análisis de necesidades?

Durante el proceso de redacción del documento, QA nos capacitó sobre la plantilla de escritura SRS, pero después todavía estaba preocupado.

Un ingeniero experimentado escribió un párrafo, pensemos en ello. Aunque este SRS fue escrito por mucha gente, es muy popular.

Consistente y detallada. Lo que es aún más valioso es que el contenido de este análisis de necesidades no se modificó hasta el final.

En cuanto a nosotros, no tenemos la posibilidad de experimentar el proceso cambiante de sus necesidades.

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, lo enumeraron.

Predecir posibles riesgos en función del número de líneas de código de cada módulo. Basándose en la productividad de su empresa (300 líneas/persona-mes), calculó cuántas semanas duraría la segunda fase del proyecto.

En ese momento planteamos objeciones: 1) La empresa necesitaba urgentemente este proyecto; 2) ¿300 líneas por mes son pocas? 3)

También hemos descargado el código fuente como referencia. . Explicó que 300 líneas de producción/persona-mes permitieron que el proyecto cumpliera con los estándares de calidad.

Datos empíricos, considerando la referencia del código fuente, la productividad no puede superar 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. Quizás seiscientas o setecientas líneas.

. Permaneció en silencio durante un rato y luego dijo con firmeza: "Creo que nuestro plan se basa en garantizar la calidad".

Cuando vienes a la India a desarrollar software, lo primero que tienes que mirar es nuestra empresa india.

Garantía de calidad. Sé que no te faltan desarrolladores de software, así que ¿por qué no eliges software descargable? Unas pocas palabras

Hablando de mis puntos débiles, ¡los hermanos en China todavía se apresuran a descargar productos de trasplante de software!

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

Diseño, 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

Probar , prueba del sistema. Un proceso completo de desarrollo del modelo V con una revisión de cada proceso. Cuando establecimos algunos

Cuando no entendía muy bien los métodos de planificación, el director del proyecto nos envió información relevante y no sabía lo que estaba pensando en ese momento.

Algunos métodos básicos de análisis y diseño se mencionaron en libros de ingeniería de software hace diez o incluso veinte años. Cada vez en la India

Estos son cursos obligatorios para todas las especialidades de Ciencias de la Computación. Además de estar familiarizado con el código de algunos protocolos específicos,

parece no saber nada sobre estos métodos comunes. Sintiéndome un poco avergonzado, fui directamente a la librería de la ciudad y lo enumeré por mí.

Encontré el libro y lo estudié detenidamente mientras estaba acostado en la cama por la noche. Fue como si de repente conociera a un mentor que pudiera darme algunos consejos.

Amigos. Ahora la India ha creado una fuerte atmósfera de aprendizaje. Después de regresar, vendió más de 700 libros y nos enseñó

Cómo utilizar métodos de ingeniería para desarrollar software es una lectura obligada para un ingeniero de software.

Nuestros directores de proyectos tienen sólidas capacidades de control de planificación. Cuando sucede algo que afecta el plan del proyecto, como la renuncia del personal, la reubicación del laboratorio o la predicción de un determinado módulo que no es precisa (este módulo fue predicho por nosotros), siempre toma las medidas necesarias.

Medidas para reducir retrasos y ajustar planes. Al principio les dijimos que bajaran a tomar un café a las 11 a.m. y a las 4 p.m. todos los días.

Todavía tenía algunos comentarios y luego seguí su ejemplo. Resulta que los intercambios durante el café son muy ricos, desde la gestión del proyecto hasta el diseño.

Métodos, que abarcan todo, desde el desarrollo tecnológico hasta las costumbres locales y la comprensión mutua y la atmósfera del equipo.

Ayuda.

El control de calidad de nuestro proyecto también llegó en el momento adecuado y solo teníamos algunas sensaciones sobre su trabajo.

Conócete. Cada vez que hay una reunión, ella suele tener una lista de verificación en la mano y el gerente del proyecto prepara la información correspondiente.

Responde algunas preguntas, marca o escribe la explicación del director del proyecto. También tuvo mucha paciencia a la hora de entrenarnos, lo cual se nota.

Aún extraño la ayuda que nos brindó por su gran profesionalismo.

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, introdujo tecnología china.

La competitividad general se ajustó del decimotercero original a más de veinte porque ajustaron algunos criterios de evaluación, incluido

En primer lugar, el número de ingenieros calificados en China es muy pequeño. Pensar en los hermanos corriendo con los ojos rojos aumentó la fatiga.

Bajo la figura cansada, tengo un fuerte deseo: ¡convertirme en ingeniero calificado lo antes posible!