¿Cómo se entiende el "código comercial"? ¿Por qué algunas personas piensan que escribir código comercial es bajo?

En mi opinión, los programadores a menudo se dividen en dos categorías: una son los programadores como yo que escriben código comercial y la otra son los "programadores que estudian algoritmos avanzados y construyen "ruedas". Científicos"...

Es un poco exagerado llamarlos científicos. La primera vez que se me ocurrió esta idea fue cuando asistí a una conferencia de tecnología, cuando otros invitados compartían sobre desarrollo, diseño, arquitectura y gestión. En términos de experiencia, un ingeniero de algoritmos que trabaja en Tencent (debería haber sido un pequeño líder) subió al escenario para compartir información como: modelo autorregresivo de promedio móvil, programación de expresión genética de redes neuronales, aprendizaje integrado de máquina de regresión SVM... Sentado en Ante el público, por primera vez pensé: "Esto es algo que los científicos estudian".

Por supuesto, no se puede decir que escribir. El código comercial es muy bajo y escribir código comercial no es tan simple como se imagina.

Para escribir código relacionado con el negocio, debe comprender el proceso comercial y también debe comprender lo que piensa el personal comercial, es decir, cuál es el punto de partida del negocio.

Por ejemplo, recientemente encontré una demanda. El proceso probablemente sea el siguiente: el vendedor está vendiendo un producto que es muy popular. Algunos vendedores excelentes pueden vender cientos o incluso miles de productos. Como resultado, recibimos una demanda para limitar la cantidad de ventas de cada agente. Por ejemplo, cada persona solo puede vender 10 unidades (las que se han vendido antes no se cuentan). , las ventas fueron buenas. ¿Por qué tenemos que imponer esta restricción? Esta exigencia parece muy irrazonable.

Más tarde, el personal de ventas nos explicó el motivo: debido a que la empresa no gana dinero con este producto, el personal de ventas dedica menos tiempo a otros productos para promocionar este producto, por lo que se introduce esta función. Es dejar que el personal de ventas "se retracte" y se centre en otros productos.

Con esta explicación, lo entendimos de inmediato; por lo que si no entiendes el negocio, es muy fácil cometer errores al escribir código según los requisitos.

Algunas personas piensan que la lógica empresarial es solo un montón de if-else, pero creo que en el trabajo real, estos if-else también son muy Difícil de hacer.

La lógica empresarial está diseñada por personas. ¿Es difícil la lógica empresarial? Lo terrible es que no es rigurosa y cambia rápidamente. La lógica empresarial es diferente de esas cosas deterministas, como el código if-else que escribimos. Si hay dos ramas, nunca saldremos de este ámbito. La lógica empresarial es diferente. Las oportunidades comerciales desaparecen tan rápido como aparecen. Un sistema completo y flexible para hacer frente a las necesidades que puedan surgir en el futuro.

Por lo tanto, durante el proceso de desarrollo, si el proceso de negocio se puede dividir en múltiples modelos de componentes, los componentes y los componentes cooperan para completar un proceso de negocio completo solo cuando el negocio cambia o hay un nuevo negocio; Reorganizar estos componentes o realizar pequeños cambios en un determinado componente puede hacer frente a los cambios comerciales, pero no es fácil alcanzar este nivel.

En este proceso, es necesario lograr una alta cohesión y un bajo acoplamiento, evitar una abstracción excesiva, partir de los procesos y motivaciones comerciales y centrarse en satisfacer las necesidades comerciales, ya que no podemos ser "científicos", trabajaremos; difícil Escriba bien el código comercial.

Continuaré compartiendo mis conocimientos sobre el desarrollo de Java, el diseño de arquitectura, el desarrollo profesional de programadores, etc., y espero llamar su atención.

En primer lugar, creo que escribir código comercial no es "bajo", pero la mayor parte del código comercial que se copia y pega sin pensar es relativamente "bajo". En otras palabras, son los llamados cinco años de experiencia laboral. Simplemente repita el trabajo del primer año cinco veces.

Generalmente existen dos líneas para el crecimiento del personal técnico, una es convertirse en experto técnico y la otra es convertirse en experto de campo. Entiendo que la llamada transferencia a la administración se refiere a expertos en el dominio. Después de todo, no se puede administrar bien sin comprender el conocimiento del dominio. Por ejemplo, si es el líder de un determinado departamento comercial de finanzas de Internet, entonces debe comprender las finanzas. El conocimiento del dominio se acumula mediante la escritura continua de código y pensamiento comercial.

Otro problema es cómo definir el negocio. Por ejemplo, "implementar una función para modificar pedidos". Este es un requisito comercial y parece muy bajo, sin embargo, si el requisito comercial se cambia a "implementar un". función para modificar órdenes, "Se requiere ejecutar 10k aplicaciones simultáneas con recursos limitados y el tiempo de respuesta no supera los 10 ms". Quiero dejar una cosa clara al hablar de este tema. Si está haciendo negocios, no se quede en la superficie del negocio y se contente con realizar funciones. Debe pensar de manera proactiva.

En conclusión, no existe la mejor tecnología, solo la que es más adecuada para el negocio. La tecnología es fuerza interna y los negocios son movimientos. Si la fuerza interna es insuficiente, el crecimiento posterior será débil. Sin movimientos, la fuerza interna no puede ejercer su poder. Esta es también la razón por la que muchas nuevas empresas de Internet necesitan transformar su tecnología después de hacerse grandes.

Como programador, también escribo código. No creo que escribir código comercial sea bajo.

1. En primer lugar, lo que todos piensan sobre el código comercial son algunas adiciones, eliminaciones, modificaciones y verificaciones relacionadas con el negocio. Los puntos técnicos involucrados son relativamente fijos. Una vez que esté familiarizado con él, podrá hacerlo. Simplemente cópielo y péguelo, lo cual no existe. Mucha gente piensa que los obstáculos técnicos son muy simples y no tienen contenido técnico, y las personas que realizan estas tareas también parecen ser de muy bajo nivel. Si lo crees así, entonces lo eres. Está mal, porque la mayoría de las personas que escriben código comercial son programadores junior con experiencia laboral limitada y no tienen la capacidad de escribir algunos métodos e interfaces públicos. Sin embargo, esto no significa que sus habilidades no mejorarán en el futuro. Si continúan trabajando duro, se convertirán en programadores o arquitectos senior. ¿Quién puede nacer para ser programador senior? ¿No lo acumula poco a poco? E incluso si escribe código comercial, no puede ser bajo. Algunos escenarios comerciales son muy complejos y la lógica debe ser muy rigurosa. Si hay un pequeño error, pueden aparecer errores que causen grandes pérdidas a la empresa. para escribir código comercial.

2. Además del código comercial, existe código no comercial, como desarrollar bases de datos, desarrollar marcos o escribir algunos métodos públicos o interfaces para llamadas de desarrolladores junior. Las personas que escriben código no comercial no necesariamente son muy hábiles, porque incluso proyectos como marcos de desarrollo o bases de datos no son necesariamente desarrolladores de alto nivel. También habrá algunos desarrolladores de nivel inferior porque escriben código no comercial. También está relacionado con el proyecto. Si su equipo desarrolla proyectos como marcos de desarrollo o bases de datos, entonces nadie en su equipo escribe código comercial, lo que no significa que todos en su equipo sean muy capacitados, pero la naturaleza del proyecto es diferente. Es lo mismo.

3. Depende de su comprensión de la palabra código comercial. Creo que, de hecho, todos los códigos pueden convertirse en códigos comerciales, no importa qué producto se desarrolle, existen. necesidades, solo con la demanda puede haber motivación para el desarrollo. Para el desarrollo de bases de datos, la demanda de la base de datos es el negocio. Para el marco de desarrollo, la función del marco es el negocio, por lo que creo que en un sentido amplio es el negocio. código, y no existe el código no comercial. En primer lugar, depende de cuál crea que es la definición de negocio. Pero pase lo que pase, no debes reírte ni menospreciar a los demás, y mucho menos a los demás.

El desarrollo de programas empresariales es diferente del desarrollo de programas en la capa de infraestructura subyacente:

El tiempo de desarrollo empresarial es escaso y cambia rápidamente.

Esta característica hace que los programadores no tengan tiempo para refactorizar el código o no estén dispuestos a refactorizarlo. En cambio, utilizan la forma más simple y sencilla de copiar y pegar para implementar rápidamente la lógica empresarial. De hecho, todo copiar y pegar significa que se requiere refactorización.

Para el desarrollo de sistemas subyacentes, los arquitectos y programadores senior generalmente diseñan y controlan el tiempo del proyecto. En términos relativos, el ciclo de desarrollo es largo y los cambios lentos. Prestará más atención a la racionalidad y estabilidad de la arquitectura y continuará reconstruyéndola y mejorándola.

Una vez completado el desarrollo del negocio, siempre que funcione sin problemas, nadie volverá a compensar la deuda técnica ni a redactarla mejor. A menos que el negocio estalle, la arquitectura debe reestructurarse para soportar una mayor concurrencia. Si funciona mal después de conectarse, es probable que se desconecte y ya no se le dé mantenimiento. Por tanto, las empresas se muestran reacias a gastar demasiada energía en un proyecto de producto que aún no ha sido reconocido por el mercado.

Los proyectos del marco de arquitectura subyacente se utilizarán continuamente en diferentes proyectos de productos. En constante evolución. Al igual que los marcos de código abierto como Spring, se actualizan y mejoran constantemente.

En términos relativos, los programadores de desarrollo empresarial dedican mucho tiempo a aprender y comprender el conocimiento empresarial, mientras que los programadores del marco subyacente dedican más tiempo a aprender arquitectura técnica. Si el conocimiento empresarial es común dentro de la industria, como las finanzas, el conocimiento de la industria financiera. Entonces la acumulación a largo plazo también es muy útil para el desarrollo empresarial. Si el negocio es muy específico, o incluso si haces este negocio en los últimos meses y luego haces otro negocio en la segunda mitad del año, solo sabes un poco al hacerlo, al igual que gran parte de la subcontratación. entonces no habrá acumulación de negocios.

Solo escribo código comercial, pero creo que esto es normal. No sé por qué crees que es bajo.

Por lo tanto, como empresa, su negocio debe respaldar su desarrollo, independientemente de los servicios que venda, debe ganar dinero a través del negocio. Puede haber algunas mejoras dentro de la empresa para el negocio. Por ejemplo, algunas personas harán parte del front-end y otras harán el back-end, así como la operación y el mantenimiento, las operaciones y la coordinación del producto. Cuando la interfaz se refine aún más, algunas personas mostrarán y presentarán algunas páginas, y otras crearán algunas herramientas adecuadas para que las empresas mejoren la eficiencia del desarrollo.

Si tu puesto es solo escribir páginas, solo se puede decir que tus requisitos para ti son un poco bajos y no has considerado cómo hacer algo para mejorar el trabajo. la eficiencia. Por ejemplo, tomemos los sistemas de administración de backend comunes, porque sus funciones son muy similares. ¿Ha considerado cómo crear una plantilla común o simplemente la seguirá repitiendo?

El resultado de esta otra persona ha creado una plantilla para el sistema de gestión de backend de Vue. La estrella actual de GitHub es más de 60.000 A través de este proyecto, puede. obtener el reconocimiento de más personas y obtener más buenas oportunidades laborales.

Por lo tanto, no crea que el código comercial es bajo. Sea bueno resumiéndolo y luego comparta su experiencia. Tal vez pueda convertirse en un líder en un campo.

No te preocupes demasiado por el llamado bajo o no. Lo que debes preocuparte es si has mejorado tus habilidades después de realizar este proyecto o negocio. Si es así, significa que no. bajo. Si no, significa que sólo estás haciendo un trabajo mecánico.

Todo gran jefe parte del código empresarial. En lo que se centran es en si pueden crecer, las oportunidades de aprendizaje y práctica y si el tamaño y el futuro de la plataforma coinciden con sus propios objetivos.

En resumen, cualquier trabajo que pueda mejorar tus capacidades merece la pena.

Creo que, en primer lugar, todo el mundo debe comprender qué es el "código empresarial" y es un concepto relativo.

1. Para una empresa de aplicaciones de IoT en general, el código comercial es la implementación de una lógica de control de aplicaciones basada en una MCU o MPU según las necesidades del cliente.

2. Para una empresa que fabrica aplicaciones puramente de capa superior, el código comercial es personalizar la aplicación correspondiente para los clientes en función de un sistema operativo e implementar la lógica de aplicación correspondiente.

3. Para un fabricante de diseño de microcontroladores, el código comercial es la implementación específica de la arquitectura subyacente básica y el diseño del marco de cada controlador periférico.

4. Para un desarrollador que diseña un sistema operativo, el código comercial significa diseño de arquitectura, administración de memoria, optimización del mecanismo de programación, administración de prioridades, optimización del mecanismo de comunicación entre procesos y administración de subprocesos. y mejoras del kernel, etc.

El llamado "código comercial" es todo relativo, ¿cómo podemos hablar sin un sistema de referencia? Al igual que un sistema operativo, desde la perspectiva del proveedor del núcleo del sistema operativo, todos los marcos de aplicaciones de capa superior y servicios de procesos son códigos comerciales y yo los sirvo. La tecnología es sólo una herramienta y la implementación empresarial es el propósito. Desde la perspectiva de diferentes proveedores, cualquier cosa que implique código puede denominarse código empresarial. Entonces, desde esta perspectiva, si queremos decir que el código comercial es "BAJO", entonces no hay código que no sea "BAJO".

Sin embargo, en realidad hay muy pocos ingenieros que realmente estén en contacto con el marco empresarial subyacente o implementen el marco empresarial subyacente de RTOS. La mayoría de los ingenieros básicamente realizan algún desarrollo orientado a aplicaciones que no impulsa el marco subyacente del sistema no operativo en respuesta a las necesidades del cliente, por lo que la mayoría de las veces el "código comercial" está dirigido únicamente a aquellos que solo desarrollan las necesidades de las aplicaciones de la capa superior. de los clientes. Ajustar o iterar el código.

En cuanto a si esta parte del código es "BAJA" o no, mi respuesta es: no "BAJA". Pero la realidad es muy "BAJA". La razón por la que se considera BAJA es porque:

1. Juzgar la excelencia de un programador ya no se basa solo en lo que hace. Usted escribe cuántos códigos orientados a aplicaciones y cuántos marcos de aplicaciones se han diseñado, pero ¿comprende la lógica del controlador subyacente, el núcleo del sistema operativo, la reducción del núcleo, etc.? Por lo tanto, esta situación ocurre a menudo durante el proceso de entrevista. El entrevistador le dará un salario más bajo porque no comprende el controlador y el núcleo subyacentes.

2. Las personas que saben cómo escribir código comercial no necesariamente tienen una base sólida de programador. Porque la aplicación de la capa superior puede estar más centrada en los negocios, pero no es tan rigurosa en la programación en algunos lenguajes específicos. Siempre que pueda usarse, naturalmente se considerará "BAJO" para dichos programadores. En cuanto a una persona que puede escribir controladores de bajo nivel, considera más la seguridad, el rigor y la capacidad del código básico, etc. Su base lingüística es relativamente mucho más sólida.

3. Los líderes técnicos generalmente son todoterreno. Las personas que pueden escribir controladores de bajo nivel o comprender mejor el núcleo del sistema operativo tienen más probabilidades de convertirse en líderes tecnológicos. Y aquellos que sólo conocen el "código comercial" generalmente no tienen mucho margen de mejora en la mayoría de las empresas.

Según el análisis anterior, los programadores que hacen "código comercial" se consideran básicamente "BAJOS", pero según mi experiencia personal, diferentes personas tendrán diferentes puntos de vista sobre este asunto.

Por ejemplo, para los líderes, es diferente. Repitió y mejoró los requisitos del "código comercial", completó las tareas antes de lo previsto y el cliente quedó muy satisfecho. Entonces el jefe no pensará que eres un programador muy "BAJO". Eres muy superior, el líder te aprecia y las "consecuencias" son muy cómodas. Pero para un entrevistador, usted se centrará en la convocatoria y el diseño de aplicaciones de capa superior. ¿Por qué debería pagarte tanto? Aunque pueda considerarse “BAJO”, también es una realidad.

El código comercial no es necesariamente un código bajo que pueda satisfacer las necesidades del usuario.

Además, para aquellos de nosotros que nos dedicamos al software integrado y al software de herramientas EDA, el software empresarial es un código con más contenido técnico y significado científico, y el software puede ser solo un soporte. Al comprender los conceptos físicos y las fórmulas matemáticas detrás de ellos a través de códigos, superará al programador y dará un paso más para convertirse en científico.

El software de Internet es en realidad el mismo. Lo que el software realiza es la automatización de un proceso comercial. Puede restaurar completamente el proceso comercial de los usuarios de la Parte A a través del programa que usted escribe, y este proceso lo formula el jefe. Comprenda que si llega a un nivel superior, podrá avanzar para convertirse en un jefe en el futuro.

Descubrí que muchos programadores se "burlan" al lidiar con la lógica empresarial. ¿Sientes que escribes código de lógica empresarial y corriges errores todos los días sin tener tiempo para estudiar o lograr crecimiento personal?

Sin embargo, como programador, si no estás investigando y desarrollando tecnologías básicas subyacentes, ¿no es la mayor parte de tu trabajo simplemente apretar tornillos? ¿Es realmente tan fácil apretar un tornillo? Puede que sea fácil apretar los tornillos, pero no lo es tanto apretarlos correctamente.

No subestime el código de lógica empresarial si realmente está bien escrito, en realidad es bastante difícil hacer que la lógica sea clara, simple y fácil de usar, robusta y estable. funciones y cumplir con los requisitos de rendimiento al mismo tiempo.

De hecho, muchos programadores como él tienen dificultades con la programación, por un lado, tienen requisitos más altos para sí mismos y, por otro lado, no les gusta el código que escriben ahora. No tiene contenido técnico. Tengo mayores ambiciones y esperanzas, pero tampoco me gusta mi trabajo actual. Simplemente no pienso en las razones por las que sucedió y no tomo medidas. Sigo quejándome: ¿Sientes que escribes código de lógica empresarial y corriges errores todos los días sin tener tiempo para estudiar o lograr crecimiento personal?

Llegados a este punto, no podemos evitar preguntarnos: ¿Cómo podemos salir de esta situación? De hecho, es muy simple. Debemos corregir nuestras actitudes y opiniones y tratar correctamente el código de escritura de lógica empresarial.

Escriba constantemente un buen código de lógica empresarial

Como dije anteriormente: no subestime el código de lógica empresarial si realmente está bien escrito, la lógica debe escribirse de forma clara, simple y sencilla. de usar, la función es robusta y estable, y el rendimiento cumple con los requisitos, en realidad es bastante difícil.

Por lo tanto, debemos ver correctamente el código para escribir la lógica empresarial, corregir nuestra mentalidad y escribir de forma persistente. Los llamados cambios cuantitativos conducen a. cambios cualitativos, ese es este principio. Escriba código comercial, acumule la cantidad de código y hágalo diez veces a la vez. Después de acumular una gran cantidad de código, casi cualquier cosa con el llamado contenido técnico no será un desafío. Por supuesto, si realmente desea escribir código comercial usted mismo, también debe pensar en lo siguiente al escribir bien el código comercial.

El código de lógica empresarial también puede jugar muchos trucos

De hecho, el código de lógica empresarial también puede jugar muchos trucos, y esta es la esencia que puede mejorar sus capacidades. Por ejemplo: usted escribió una lógica de negocios para manejar una sola tarea, aunque satisface las necesidades de los usuarios, ¿puede tener requisitos más altos para usted en este momento? Aunque se implementa la función de tarea única, la eficiencia puede no ser alta y el procesamiento puede ser lento. ¿Qué tal crear una lógica de tareas múltiples? Los puntos técnicos como grupo de tareas, grupo de subprocesos, grupo de memoria, concurrencia, sincronización, etc. están todos aquí. Si usted tiene tales requisitos y tiene objetivos, pensará más en cómo lograrlos. Si lo hace, sus habilidades mejorarán.

De manera similar, muchas personas sienten que el procesamiento de la lógica empresarial son solo varios bucles y juicios condicionales. Mientras la lógica sea un poco más rigurosa, las funciones no serán un problema y todo. Se implementará. De hecho, eso es todo. Ésta es la raíz de su falta de interés en la lógica empresarial.

Entonces, ¿por qué no piensas en: cómo utilizar bucles y juicios condicionales para mejorar la eficiencia? Una vez cumplidos los requisitos funcionales, ¿hay áreas que se puedan optimizar? ¿Se puede mejorar el rendimiento?

De hecho, el progreso y la acumulación de esta tecnología radica en si tienes mayores requisitos y objetivos para ti mismo en tu corazón. Esta es la verdad y la lengua vernácula. Mucha gente siente que es suficiente implementar requisitos funcionales y satisfacer a los usuarios.

Luego, este proyecto se termina, y cuando el siguiente proyecto encuentra una lógica similar, se maneja de la misma manera y se termina nuevamente. Cada proyecto y cada función se maneja de esta manera repetidamente, sin pensar nunca en el método de implementación óptimo. ¿Sientes que puedes Progresar? ¿No puedes enojarte? Diez años de trabajo día a día, 10 años también acumulan un año de experiencia laboral, que se puede utilizar repetidamente.

La mejor manera de hacer lógica de negocios es pensar en cómo lograr la simplicidad

Básicamente, cualquier programador que no sea estúpido puede implementar una función a través de la lógica de negocios. Una cosa es hacerlo bien, otra cosa. Lo más importante es la simplicidad. Si queremos hacerlo, tenemos que encontrar la mejor manera de hacerlo. Bueno aquí tiene muchos significados.

Por ejemplo: ¿puede el código de lógica empresarial que escriba ser preciso, estable, eficiente, fácil de leer, fácil de expandir, fácil de mantener y tener una gran compatibilidad? Pregúntate, si puedes hacer esto, sería genial. Si no puedes hacer eso, todavía estás lidiando con el nivel básico, por supuesto que no, y esta es tu oportunidad de mejorar tus habilidades en el trabajo. No digas que no tienes tiempo, todas son excusas.

Luchar por la excelencia es la eterna búsqueda de la simplicidad en el código y también es el proceso mediante el cual mejoramos continuamente nuestras capacidades en el procesamiento del código de lógica empresarial.

Es fácil para mí ser complaciente y complaciente aunque estoy en un nivel junior siento que estoy bien. Aprende habilidades superiores, por lo que las habilidades superiores soy yo. Lo que se acumula paso a paso en el procesamiento de la lógica empresarial no es que tengas que hacer un trabajo elemental. No es necesario que lo acumule, puede aprender técnicas avanzadas directamente y volverse avanzado.

Me gusta especialmente un pasaje escrito por un internauta en Internet:

De hecho, muchos expertos técnicos y expertos técnicos parten lentamente de la lógica empresarial. acumulé mis pensamientos. Por ejemplo: antes de abordar la lógica de negocios, pensaremos en cómo diseñar la arquitectura para que el código se pueda expandir y mantener mejor. Al procesar la lógica empresarial, piense en cómo mejorar el rendimiento y la eficiencia. Sólo a través de la experimentación, el resumen y la acumulación paso a paso logramos los resultados de hoy.

Por lo tanto, no se burle del procesamiento de la lógica empresarial y no piense que es suficiente para satisfacer las necesidades. Pegar y copiar repetidamente sin pensar definitivamente no funcionará. Definitivamente perderá interés en la programación y, naturalmente, no podrá crecer ni progresar mejor. Debe perseguir requisitos más altos y encontrar intereses más altos en el proceso de programación, para que pueda continuar progresando y avanzando.

El bosque es grande y hay todo tipo de pájaros, no sé a qué proporción de personas te refieres con personas. Entiendo que el código se puede dividir en dos categorías: 1: Barra de herramientas o clase de marco 2: Clase empresarial. Al escribir clases de herramientas, nos enfocamos en ser robustos, escalables y reutilizables; cuando escribimos clases de negocios, nos enfocamos en una lógica rigurosa, sin lagunas y simplificando la complejidad. Después de todo, a veces los requisitos o el negocio no tienen clara la lógica que quieren. A veces ni siquiera es posible comprender procesos comerciales complejos, y mucho menos escribir un buen código. Por supuesto, las herramientas avanzadas, las herramientas fáciles de usar y los marcos excelentes requieren un conocimiento técnico profundo, y hay más cosas a considerar además del código comercial, pero esto no significa que escribir código comercial sea de bajo nivel. Por supuesto, no importa qué código escriba, lo copiará y pegará por completo sin considerar cómo combinarlo con el escenario real, y no pensará en por qué. ¿Existe una solución mejor que sea relativamente baja?