业务和技术哪个重要

先要知道业务和技术是什么。

业务

什么是业务，可以理解为做什么事。
业务主导技术，但是无法脱离技术，因为无论如何要有一种实现方式。
业务更宏观。

技术

什么是技术，用什么方式。
技术可以支持业务， 但是以业务为前提。
技术更微观。

他们是相辅相成的。

草船借箭说明业务和技术

业务和技术	周瑜	诸葛
需求	火攻曹操，需要10万只箭	成
实现方式	造箭
多少人	2000人怎样	500人
多少天	10天够不	3天
合同	我跟客户(孙权)签了合同的，10天搞不定要赔偿	行，搞不定我赔你条命
结果		去曹营逛该一圈即可

业务要做什么：
和客户沟通： 主公，火攻破曹的事交给我您放心
理解需求： 要10万只箭
评估工作量：我知道10天一定完不成，害死你妥妥的
拿下合同：

技术要做什么：
理解需求： 要10万只箭
拆分功能：借船，扎稻草人
付诸实现： 带上船去逛该

高级技术

功能拆分，
不用告诉他们如何带兵，如何打仗，只要告诉他们去干嘛就行了。

架构

架构的重要性：
架构好比是阵法，开发好比是战士。
架构的好坏决定了是一字长蛇阵，还是八阵图。

主管要做什么事情

主管这个层面既要懂业务，也要懂技术，更加宏观。

开发的注意点往往在业务和实现方式上。(范围：多个功能模块，或多个项目)
业务的注意点在项目的。(几个项目)
主管的注意点： (所有项目)

从层级方面来说，主管肯定要高很多。
例如：
主管不必知道spring如何配置，但是知道微服务架构的优点。
主管不必知道如何实现高并发，但是知道高并发的效果。
人员的管理，面试的时候一眼就能看出是个什么人，适不适合这个岗位。如何凝聚团队，鼓舞士气。
协调资源，合理分配资源，以保障大局为前提。

摸索代码的时候从业务入手还是代码入手

当然是业务入手，因为方向更明确。
举个例子：
目的 去上班。
代码实现 坐地铁。

如果从业务角度，可以知道上班是目的，坐地铁是手段。
如果从代码角度， 有点本末倒置的意味，因为可以 坐地铁/坐公交/开车 。

业务可能是最后一根救命的稻草

假设一个场景，代码经过了无数手，到底什么逻辑早已无人知晓。换谁来对接，都无比头疼。
但是如果熟悉业务的项目经理还在，或者有一份清晰的需求文档。
靠着这点业务还可以补救，甚至推翻重来也不是难事。
但是如果连业务也不清楚，那。。。自己看着办吧。

一个定时任务就能有很多问题

这个定时任务的场景是什么?

哪些数据会进入该定时任务?
未审核的 或者 创建时间一个月内失败的。

定时任务的执行时间是?间隔?
每天2点一次。 或 每20秒一次。

定时任务的鉴权是通过什么机制?
是通过角色，还是其他。

定时任务的主要逻辑是什么?(这一块比较复杂，可以衍生出很多问题)
例如，会调用哪些接口，校验逻辑，判断逻辑，是否入库，会入哪个库呢?