🖐 编程新手问题
!本篇文章过于久远,其中观点和内容可能已经不准确,请见谅!~
想分享的是看到经验不足的开发刚入门时,会遇到的一些问题,能看到经验这个东西是也并不是摸不着,踩的坑多了经验就来了~~
并不是一个很老道、很有经验或者很厉害的开发,但是遇到了很多自己之前犯过的问题。虽然公司项目不大,但是也带了不少实习生,几乎都是初学者,遇到很多编程新手会犯的问题,很多时候经验真的是很重要。更多的时候因为没经验,很多简单的概念或者调试过程就会耽误很多精力,别人的一个小时任务,在很多细节上浪费时间,造成效率低下。
ps: 新手指的是编程刚入门,在没有完整需求说明或者技术栈不熟悉的背景下,而不仅限于工作年限少,很多小项目没有全面的需求文档,还直接面向 c 端,就会出现很多效率低下的踩坑。
新手在做一个功能的时候,关注点大部分是如何成功实现需求,而不是做好功能。
就导致了开发调试的过程中,更强调的是能够从头到位能成功的实现全部交互,所以错误的捕获、处理、提醒等处理经常性的被忽略,所以做出来的东西需要额外花精力补漏洞。
比如在开发前端一个应用页面的过程中,需要获取数据、从本地缓存读取数据、获取浏览器某些数据等,一般初学者会直接心里假设这些数据都能成功读取,或者懒得考虑,所以错误部分没有实现。
fetch('example.com').then(response => response.json()).then(data => {document.getElementById('container').innerHTML = data.message})const divideBy = (a, b) => a / bdivideBy(6, 2) === 3
老鸟的做法会更加严谨,每一个 Promise 的 catch 都会有,服务器返回的数据都要验证 statusCode,本地浏览器的兼容性都要考虑。
毕竟经手的项目都需要上线,在不同的环境下错误非常容易出现,不处理的话会出现问题的,轻则没有反应,重则白屏影响业务,所以做的东西不是当初实习的时候 demo 级别的东西了。
import 'whatwg-fetch'fetch('example.com').then(response => response.json()).then(data => {if(data.status === 0) {const el = document.getElementById('container')if(el) el.innerHTML = data.messageelse console.error('element not found')} else {console.error('json data error', data.status)}}).catch(() => {console.error('json fetch error');})const divideBy = (a, b) => {if(typeof a !== 'number' ||typeof b !== 'number' ||b === 0) throw Error('invaild params')return a / b}divideBy(6, 2) === 3
有条件的用完善的测试条件来测试覆盖。没条件的多踩坑被骂,找到经验就行了。更多的是把错误处理当做编程的一部分,开发远远不仅仅是技术验证范畴,你以为没人会遇到的万分之一错误条件,放大上万倍就是一个必定出现的问题。
作为一个程序员,尤其是在没有完整团队和产品的情况下,做出来的产品非常的程序员风格,不会考虑怎么用,而是考虑实现。典型的场景就是不注重用户体验、没有整体风格和交互体系、技术探究大于产品需求等。
举个小李子,出错信息的时候,程序员经常会将系统的语言告诉用户,比如获取麦克风权限就有很多不同的错误类型,比如权限问题、设备故障、找不到或占用、安全问题等,按照一般理解,我们需要提示用户哪里有问题了,所以将问题告诉用户,但是 95% 的用户其实不明白我们提示的问题的,所以我们只能提示用户能不能用,不能用的时候能不能自动修复,不能修复怎么让用户使用别的途径,最后无法使用直接提示用户无法使用即可。对于用户,我们程序员可以用简短的话告诉他怎么办,而不是教他为什么出现问题。
多了解一些产品的理论和认识,会对编程产生很多好处,对自己的能力也是一种更好的梳理。面向 C 端的产品一定要有专门的精力来妥善处理每一处编程走向,自己手中的产品不是冷冰冰的输入输出,更要站在你的用户群体考虑你所呈现的交互。
这个对于初学者更多些,可能是因为经验问题,或者就是单纯的不知所措。有很多人在程序出现错的第一反应是自己代码出现问题,然后就盯着自己的代码 “看” 哪里出现问题了,而不是去 “调试”。自以为能走通的流程反复检查无数遍,不如打个断点让 debuger 告诉你程序怎么走的。
而且有些人是知道出错了,报错信息提示的很明确,但是不看报错信息,或者不明白提示的错误的含义,可能对英文不敏感,可能觉得自己知道哪里有问题??让我很费解。
刚开始的时候都要提示看错误是什么,看得懂就改,看不懂就搜索,初级阶段的编程,提示加搜索能解决 90% 的问题。
如果没办法在第一时间看到问题:
- 一方面是逻辑问题,比如代码的运行流程,或者代码的调用之类的出现问题,这样的情况简单的打断点或者输出关键数据就能发现问题。
- 另一方面是业务问题。比如产品文档中数据的结构处理出现问题,或者理解错了文档,这个就是业务熟悉程度了。
善其事,利其器。理解 IDE 的输出,理解 SDK、API 提供的信息作为线索。
在我经手的实习生中,学的最快最好的是最会用搜索的。对于搜索的部分,很多也是很意外的不专业,经常看到初学者用一些错误的关键词搜索,或者到百度知道上找问题,点开 10 年前的文章找解决方法,令人很无语。
其实学习技术的时候,直接到项目的官网、源代码的GitHub上找官方文档是最快最好的,很全很详细的一手资料,而且现在附带中文文档翻译越来越多,到官网直接找 get-start 目录了解安装和基本用法,查资料的时候找 APIs 或者 Docs 目录,这些基本上能够保证很好的上手。
有问题的时候,无论是 bing、google,都会显示搜索来源和时间,挑选 Stack Overflow,github,medium,segmentfault,csdn,简书,知乎等,然后看下最近一两年的答案,基本上都能解决大部分的问题。
有条件的踩梯子去 google,没条件的知道到 bing/sogou 上,不是说 baidu 没办法解决问题,而是切身体会到遇到很多次 baidu 翻三页没有一个结果,但是 Google 第一条就是答案,学会找到质量高的地方帮自己解决问题。
如果你要接手另一个人的项目,或者如果你要管控另一个人的项目,或者比较多的是之前开发的某个模块交给你做,你应该怎么上手?一般新手可能就开始从项目入口函数开始看起了,如果是项目交接,可能就开始从头到尾问另一个人过代码和业务了。
这样做没问题,但是严格点这样会被骂的,因为比业务逻辑更重要的是这个项目的目标、阶段目标、现在的状态,还有当前的验收和交付,没错,做了一半的项目介入新人也需要交付的概念。
第一时间应该是交接这个项目目前是什么状态,因为交接不仅仅是代码,还有谁背锅的问题,新手接手一个项目之后,出现问题最多的反馈是,这是上一个人的 BUG,不是我的问题。 不好意思,交接之后,全都是你的问题了。
比如上一个人说项目已经把 A、B、C 需求都完成了,逻辑上没问题,然后你跟着看了这块的业务,虽然还没上线、没测试、没产出,但是看着逻辑没问题,毕竟他说都完了,然后这块算交接完。过两天开始着手深入进一步开发,发现神坑很多,进度在这里卡住了,这算是你自己的进度卡点问题了。
所以接手别人的项目,或者将项目交给别人,第一个概念是交付和验收,毕竟这涉及到对项目负责的问题,其次才是具体的业务逻辑和代码,虽然需要花更多时间。
学习编程、代码,几乎没办法线性的提高自己,没办法像书本似的,第一章变量,第二章语句。这样的提升方法对于大部分人就是没用的,因为这个就像是教你怎么干农活,理论知识很好,但是你花了一个月看书,真实自己上手、看别人的代码实践、看视频等都能把一小时的理论用五分钟演示清楚。知识理论是研究,手艺技能是上手。
这也是我建议初学者先上手再理解的原因,你能改代码,就很容易写代码,仿照着把代码改成满足业务,就能很容易的自己写代码完成另一个任务,慢慢的就能从上层理解底层的东西。
这是很自然的事情,个人的成长也是这样,先看代码、改代码、写代码、出现问题去搜索、然后沉淀技术总结文章。
很重要!上一点说了,不要抱着书啃,因为从 0 学习理论知识对初学者的提高效率很低,但是并不是说理论不重要。在平时的编程中,80% 的时候是业务,也就是解决问题的能力,但是还有 20% 的是 更好 的解决问题的能力,这也是你比别人更好的价值最大化的地方。
算法理论、数据库理论、网络、多线程、消息队列、架构等,这些东西都是很理论的东西,如果你不知道这些,在遇到的时候就会是一个瓶颈。这也不是遇到就能搜两三下就能懂得的东西。
比如处理一个大数组的排序,统计全国人口数据的排序,数据量级在
10^9
,如果使用冒泡排序的 O(n^2)
复杂度需要 n^18
次运算,在普通计算机上(10^9 flops
)需要至少 10^9 秒 = 30 年
才能解决(仅考虑算力),而使用归并排序 O(nlogn)
只需要 30 × 10^9
次运算,普通计算机只需要 30秒
就能解决。所以强烈建议把空闲时间放到这些东西上。
团队协作这个涉及到比较大的范围,比如注释、文档、Git、交接、CodeReview 等。
新手对业务和交流不是很熟悉,所以很大的注意力都在完成任务上了,所以周围支持能力没有那么重视,而这些在团队里还是比较重要的。
- 注释: 团队工作复杂度更高,一些关键点的注释对别人的阅读能起很大的帮助。
- 文档: 很多人不习惯写文档,但是一个项目需要告诉别人背景、目的、状态、启动、部署、调试等,方便其他人介入。
- Git: 这个算是必备技能了。要说的是 workglow 的能力,比如必须保证每个主分支都是能编译的版本,保证每次提交都有说明改动的部分。
- CodeReview: 无论对于初学者还是到一个新环境,都要让其他人 Code Review 下,保证代码的规范是符合团队的。
很不想说,但是还是要说,如果你不是对编程、对业务有很大的兴趣,很难在编程的能力上有很大的精进。因为需要你繁复的练习、需要你花费很大一部分自己的时间,你不喜欢的事情很难坚持下去。
还遇到了很多人,花费了很多的耐心教他,但是总是没办法理解,坐在办公室的效率就是出奇的低,很用功努力的上班,埋怨自己为啥学不会,其实答案就是真的不合适。
对于很多人编程是人生的很重要的事业,可能要持续十年、二十年、三十年~,怎么更好的完成任务就是价值的体现,怎么完成任务、怎么提高能力、怎么实现价值、怎么让自己更好的在现实生活存在,是很重要的。好在有很多人走在这条路上,好在只要努力还是会有很好的结果。
更多的试炼让自己变得更加强大。
—— UBUG
感谢您的阅读,本文由 Ubug 版权所有。如若转载,请注明出处:Ubug(https://ubug.io/blog/coding-badcase)