来源: 网络整理 时间: 3天前 人气: -
朋友李明，做软件开发快八年了。
之前他在一家公司做后端源码资源，后来出来自己单干，接各种外包项目。
上一年秋季, 他承接了一个项目, 该项目是关于供应链管理的, 其客户乃是一家中型批发商, 这家批发商提出要求, 要制作一个微信小程序, 此小程序需具备随时能够查询库存的功能, 还要拥有下单的功能, 以及查看报表的功能。
刚开始的时候, 李明认为这项工作规模不算大, 只需套用现成的模板, 对界面进行修改, 再添加几个接口, 一周时间便能够交货。
他自信满满地答应了，结果刚开工才发现，事情没想象中简单。
随着与客户交流的深入, 客户所需呈现出不断增多的态势, 得按照月份来自动生成报表, 库存预警需做到实时推送, 并且还得和客户的ERP系统进行对接。
到处都是硬编码的模板代码, 想要添加功能, 牵一发就会动全身, 改到最后, 连自己都看不懂了。
到了交付前两周，客户不满意，说功能对不上，页面也卡顿。
李明慌了, 于是只能熬夜去重写, 在那段时间里, 基本上天天都是凌晨两点才睡, 依靠着咖啡来延续性命。
最后虽然按时交了，但利润薄得可怜，还落了一身毛病。
这次经历让他彻底想明白一件事：技术开发网站开发，不能总想着走捷径。
诸多的人进行询问, 于开展项目之际, 究竟是应当采用现成的模板, 还是要从源码着手去进行开发呢?
李明说，这要看项目的生命周期。
要是仅仅去做一个属于短期范畴的活动页, 又或者是那种一次性的展示类型的小程序, 那么模板是足够使用的, 能够迅速实现上线, 并且成本也是比较低的。
可是要是处理那种得展开长期运作、得不间断进行迭代的生意系统, 源代码运用则是仅有的挑选。
源码进行开发所具备的好处是, 代码的结构呈现出清晰的状态, 逻辑能够加以控制, 后续增添功能以及修改逻辑都存在着可以依据的内容。
并且, 源码是掌握在自身手中地, 并不存在会被供应商进行绑定地那种问题, 去更替人员来做维护, 以及进行迁移部署都会相较于便利地。
短板同样显著, 耗费成本高昂, 所需周期漫长, 要有专业的技术团队, 前期投入规模巨大。
李明, 如今跟客户谈论项目之时, 总会主动去建议采用源码开发方式, 哪怕会耗费更多一点时间, 可这也比后期出现返工情况要强得多。
他讲, 技术人员所具备的专业价值, 是呈现在此处的, 在于助力客户躲开后续的坑。
这几年, 小程序开发特别火。好多客户一上来, 就要求做小程序。他们觉得, 小程序流量大, 而且门槛低。
但李明说，小程序开发不是简单套壳，有很多坑需要提前踩清楚。
微信环境之中运行着小程序, 内存以及计算资源均存在限制, 一旦页面数量增多, 并且数据变得复杂, 便极易出现卡顿现象。
小程序存在着诸多能力, 这些能力都对微信开放接口有所依赖, 就像定位能力、支付能力以及订阅消息能力一样依靠它, 一旦微信的策略发生调整, 那么可能就需要进行大幅度的修改。
提交小程序版本这件事是需要进行审核的, 每一次出现小的改动, 都得去走相应的流程, 而在处于紧急情况的时候, 是很难做到快速去做出响应的。
所以, 李明如今在做小程序项目时, 都会预先向客户将那些风险讲述明白, 从而防止后续出现扯皮状况, 最终有效避免后续纠纷产生。
他还向客户提出建议, 核心的业务系统做成H5比较好, 或者弄成独立的APP也行, 而小程序当作引流以及辅助的工具更为恰当。
除了技术本身，李明觉得跟客户沟通同样重要。
很多项目出问题，不是技术不行，而是需求没对齐。
客户想要的和自己理解的，往往差很远。
他讲, 他如今承接项目, 首要步骤并非编写代码, 而是耗费大量时间同客户交流需求。
将功能予以拆分细化, 逐一对其进行确认, 甚至于绘制出原型图, 从而让客户能够直观地看到相应效果。
客户确认签字后，再开始开发，中途改需求要走变更流程。
这个方法听上去麻烦，实际上省去了大量返工的时间。
他还讲了, 存在一些客户, 就技术方面是并不了解的, 会提出来一些不符合实际情况的要求, 像是“三天上线全套系统”这种。
此时, 并非能够径直拒绝, 而是得给出专业的建议, 阐明风险以及可行的方案, 从而令客户自行去做出选择。
技术服务本质上是帮客户解决问题，而不是炫技。
李明现在带一个五人的小团队，两个后端、两个前端、一个产品。
他说，团队配置要根据业务类型来定。
如果主要做小程序和H5源码暴富，前端和UI的比重可以大一些。
如果做的是后台系统和数据对接，后端和测试更重要。
他还特别强调，团队里必须有一个人懂产品。
技术人员极易坠入实现细节之中, 从而忽视用户体验, 此时, 有产品思维者参与进来, 便能够规避诸多返工情况。
另外，代码规范和文档也很重要。
处于项目交接这个阶段的时候, 要是不存在文档这种东西, 那么接手过来的那个人就只能再次去读代码, 如此一来效率是极其低的。
李明如今规定, 每一个项目都得拥有完备的接口文档, 还得有部署文档, 以及常见问题手册, 以此便利后续的维护工作。
聊到最后，我问李明，技术开发这个方向，接下来怎么走？
他讲, AI针对开发所产生的影响正日益呈现出增大的态势, 诸多具备重复性特征的工作将会被予以替代, 像基础的CRUD, 还有简单的页面搭建。
但是, 核心逻辑设计这一事物, 架构选型这一事项, 业务理解这一要点, 暂时还没办法脱离人。
因此, 他向年轻的开发者发出建议, 不要仅仅去学习语法以及框架, 而应当更多地去了解业务, 进而培养产品思维。
技术只是工具，解决实际问题才是价值所在。
他针对我的客户给出了一条忠告, 那就是, 寻找技术开发团队的时候, 不能仅仅只关注价格, 而应该去查看案例, 去考量沟通情况, 去审视长期服务的能力。
价格较为低廉的方案, 常常是花费最为高昂的, 这是由于后续维护以及迭代成本极有可能会远远超出起初的预期, 结果就是这般。
李明的故事，其实在很多技术人员身上都能找到影子。
从事技术开发工作, 说到底这是一场漫长的跑步比赛, 比拼的并非是某一时瞬间的速度, 而是长久时间的稳定性。
选对方向、打好基础、做好沟通，才能在行业里走得稳、走得远。
