1. 聚能聊>
  2. 话题详情

程序员何苦为难程序员,那些程序生涯中踩过的坑

程序生涯中,总会遇到各种各样的坑,就像人生道路一样。这些坑,有些是别人给你挖的,比如维护别人的代码,而有些是自己给自己挖的,比如不写注释,不写文档,代码重构的时候全靠缘分了哈!
u_3811460774_2598021208_fm_26_gp_0
每个人写码的习惯 写码的逻辑都不一样 所以当我们熟悉的章法被打破了 就会不习惯 甚至看不惯 当然其中确实大家写码水平高低不平 不排除有代码真的很烂的情况 例如一开始业务很简单 实现很简单 不用费心设计代码模型 想到哪里写到哪里就可以了 之后业务扩张 复杂度增加 上线时间紧迫 于是紧急完成任务 写了一堆不是很优雅的代码 如此以往 这个代码就没法维护了 牵一发而动全身 后面的人又不敢大改了 想要重构费时费力不讨好 接着写呢 恶心代码一大堆 进退两难 特别是多人维护的时候 这种现象更明显
u_2338997326_1088558702_fm_11_gp_0_jpg
其实对于写代码遇到的坑,很多都是前面的人写后留下的,后续接手的人抱怨这也是常事,当然最可恨的就是,这个坑是自己留下的啦!

话题:
1,你在日常的开发中遇到过哪些坑?
2,你在项目的开发中,是否曾经给自己挖过坑?
3,在我们的项目开发中,怎样能尽量少给别人挖坑,当然也要少给自己挖坑?

参与话题

奖品区域 活动规则 已 结束

  • 奖品一

    阿里云代金券 x 3

  • 奖品二

    数据线 x 1

  • 奖品三

    蓝牙手环 x 1

36个回答

2

微wx笑 已获得阿里云代金券 复制链接去分享

1,你在日常的开发中遇到过哪些坑?
遗留问题,如何代码不规范,变量名没有实际含义,没有注释,没有相关的文档;
框架、接口类的行为与实际表现不一致等;
文档不全不细,很多地方要自己摸索等;

2,你在项目的开发中,是否曾经给自己挖过坑?
其实在开发中,我觉得需求了解的不够,没有认真深入的思考,那就是在经给自己挖大坑;
虽然可能面临时间紧、任务重,所以很容易一个需求拿过来就做,
但做的过程中就可能遇到各种问题,所以就要改改改,最后下来,反而浪费了很多时间,工期拖延的更久。

3,在我们的项目开发中,怎样能尽量少给别人挖坑,当然也要少给自己挖坑?
如上面说的需求了解的不够,没有认真深入的思考要避免,应该引入正规流程,流程图之类的不可少;
代码编写要规范,注释让人一看就懂,不然的话可能过不了多久,自己再去看的时候,就不知道当时是什么思路了。

求代金券~

景凌凯 回复

笑兄都用代金券做什么了,指点下

评论
1

大河人家 已获得数据线 复制链接去分享

1,你在日常的开发中遇到过哪些坑?

前边的代码和后边的不兼容,多人合作开发的风格不同,写代码前缺少规划,写代码之前规划过度,低估代码质量的重要性,选择1号方案,吊死在一棵树上,闭门造车

2,你在项目的开发中,是否曾经给自己挖过坑?
不使用封装
这一点不只是针对使用面向对象语言的例子,封装总是有用的,如果不使用封装,会给系统的维护带来很大的困难。

在应用程序中,每个功能要与用来处理它的对象一一对应。在构建对象时,除了保留被其他对象调用时必须传递的参数,其他内容都应该封装起来。

这不是出于保密,而是为减少应用程序不同部分之间的依赖。坚持这个原则,可以使你在对类,对象和函数的内部进行更改时,更加的安全,无需担心大规模的毁坏代码。

对每一个逻辑概念单元或者块都应该构建对应的类。通过类能够勾画出程序的蓝图。这里的类可以是一个实际对象或一个方法对象,你也可以将它称作模块或包。

在每个类中,其包含的每套任务要有对应的方法,方法只针对这一任务的执行,且能成功的完成。相似的类可共同使用一种方法。

作为新手,我无法本能地为每一个概念单元创建一个新类,而且经常无法确定哪些单元是独立的。因此,如果你看到一套代码中到处充斥着“Util”类,这套代码一定是新手编写的。或者,你做了个简单的修改,发现很多地方也要进行相应地修改,那么,这也是新手写的。

在类中添加方法或在方法中添加更多功能前,兼顾自己的直觉,花时间仔细思考。不要认为过后有机会重构而马虎跳过,要在第一次就做对。

总而言之,希望你的代码能具有高内聚性和低耦合性,这是一个特定术语。意思就是将相关的代码放在一起(在一个类中),减少不同类之间的依赖。

3,在我们的项目开发中,怎样能尽量少给别人挖坑,当然也要少给自己挖坑?

1,遵守代码规范
2,使用配置文件
3,不使用不必要的条件语句或临时变量
4,注释必不可少,但是不要泛滥

0

桥西侧 已获得蓝牙手环 复制链接去分享

01 没有合理计划

高质量的代码从来不是一蹴而就的。它需要经过思考,调研,计划,疯狂写,测试,改进一系列周而复始的过程,百转千回,方能炼成。

新手最常犯的错误之一就是拿到任务,没有任何调研和计划就开写。

小程序或许还行得通,如果是一个非常大且复杂的项目,基本就狗带了...

02 过度计划

凡事过犹不及。永远没有一个完美的计划,计划也总是在变化。

所以开始有一个大体的规划后,就要开始想怎么着手去写代码了。

要在过度计划和计划不足间追求一个动态平衡,才能写出最优代码。

切忌一下子把一个大程序中所有的feature一步一步全部考虑周密。

在写代码的过程中,你需要随时准备添加,删改feature以及debug,保持高度灵活性。计划重要,但开始写更加重要。

03 不关注代码质量

混乱代码基本等同于垃圾。编程的本质是和别人交流关于问题的解决方案,力求清晰简洁。

一些代码在写的时候需要注意如下小细节:

注意缩进和大小写

每行别超过80个字符

function长度别超过10行

变量名能够不言自明,不易混淆

大多数时候,短代码比长代码好

“想象后面接管你代码那人是个有暴力倾向的精神病,一旦写不清楚,他随时到你家找你”

04 想到一个方案就开写

刚开始编程时候,往往想到一个方案就开始写,很少考虑这个方案的时间空间复杂度或者潜在的错误。

一个问题如果你没有想到多个解决方案,很可能是你并没有真正理解这个问题。

程序员的工作重点并不是找到一个问题的答案,而是找到一个问题最简单的答案。

这里简单的意思是这个方案可以正确解决问题,同时又简单易读懂。

这个时候需要开阔思路,去google一下其他方法,综合评定下,选一个可以解决问题并且最简洁的。

05 不用封装

封装,简单理解就是把一系列的数据放在一个类中。不用封装常常会造成严重的系统维护问题。

新手程序员,很难按照直觉建立一个类,或者决定类里面放什么。

如果你想改个东西,发现需要同时改更多其他的feature,这个时候得重新想想是不是自己开始架构架错了 。

就整体而言,你的代码需要高聚合性和低耦合性。

06 没有正确选择数据结构

新手程序员常纠结在算法上,其实熟练掌握每种数据结构的优缺点更能让你在编程中如虎添翼。关于正确使用数据结构的建议 :

多使用map来代替list

多使用栈来优化循环

让现有程序更乱

在一堆已经很乱的程序里面找到正确位置并且添加新的feature,类似于向乱成狗窝的房间里随手扔进一个新东西 —— 让现状变得更乱,并且你也找不到新东西放哪了。

正确的做法是先把现有的整理干净,然后再往里面填加新东西。

以下是一些错误的做法:

仅仅为改一行而复制粘贴一整段代码

不用配置文件

用没必要的if条件语句和临时变量

关于上述的第三点,请看下面的例子

改动前的代码:

把不必要的if条件语句稍加改动,编程的样子就清晰多了:

07 不写测试

如果没有自动化的话,在建网页过程中,一般你会每写几行就刷新下来测试。

手动测试并没有什么错,但是更多你要考虑的是,怎么让测试这部分自动化,基本上是人做人该做的事情,电脑做电脑该做的事情。

制造并使用工具,是人和动物的本质区别。

“以测试为目标编程”并不是一句空话,甚至你可以在写程序之前先想想怎么设计测试程序。

08 没找对工具

锤子可以将一个钉子砸进墙里,但却不能把螺丝拧进墙里。不能说仅仅因为你喜欢用,或者你这把锤子在亚马孙上面五星好评,你就非要用它做它并不能胜任的事情。

新手需要多了解现在手头上工具的优缺点和局限性,然后多去了解,多去学习新工具,力求用最合适的工具最高效的干活。

没意识到程序问题

会造成数据问题

新手开始往往不会想到数据和代码之间的这种关系,有bug的代码很可能持续带来数据一致性的问题。

为避免此类问题,可以选择用多层数据验证方式,在前后端,网络传输和数据库这些地方都加入数据验证。

如果无法办到这些,至少在数据库层次加入以下限制。

能够熟练应用:

NOT NULL

UNIQUE

CHECK

PRIMARY KEY

FOREIGN KEY

09 对Code Review持怀疑态度

新手常把code review当成负面的东西,所有比较抵触,消极对待甚至害怕。

请点击此处输入图片描述

Code Review其实是一个很好的学习过程。

一朝为程序员,你需要接受这个过程并学会享受其中。

很多时候,code review会教你一些你不懂的东西,请用积极热情的态度去迎接你的reviewer。

10 不用版本控制

新手程序员常常忽略用版本控制软件,比如git的重要性。

版本控制并不只是指把你改好的东西汇入别人的程序里面。

版本控制更多是关于一部开发的历史。

从这里面能够帮我们和后续的开发者提供最一手,最全面的信息,来了解现在的代码是怎么一步一步得来的。

版本控制意味着可恢复性。 Git甚至可以通过二分法查找到当初引进bug的那个commit是源自哪里

0

浮生递归 已获得阿里云代金券 复制链接去分享

1,你在日常的开发中遇到过哪些坑?
自己的坑:软件越写越复杂,等回头看最初的模块时,发现并没有写相关文档,自己也看得一头雾水。
别人的坑:没有文档的结果,就是代码根本没办法读,只能全部重构,彻底重写。

2,你在项目的开发中,是否曾经给自己挖过坑?
有,曾经追求代码简练,输入迅速,结果过头了。比如定义的时候,直接用a=xxx,b=xxx之类的单字母缩写。最后,你懂的。很快就忘光了各自都是什么单词的缩写。

3,在我们的项目开发中,怎样能尽量少给别人挖坑,当然也要少给自己挖坑?
就跟忠孝难两全一样。很难做到又高效又规范。要少挖坑,就要讲究规范。过于规范,效率就上不来。抛开一切文档规划什么的,3天的开发,可能一天就能完成。但是运气不好的话,日后填坑可能要6天。只能尽量折中吧。尽量规范,又要注意尺度。

0

海阔天空yy 已获得阿里云代金券 复制链接去分享

1,你在日常的开发中遇到过哪些坑?
1 变量明名不规范,有的是拼音加英文,有的是a,b,c,之后再来改动代码的时候,简直要疯
2 需求没明确就开始着急着开发,开发到一半再接着看需求发现,不是自己想的那样,还要重头改。
3 自己的代码不测试,只写不测到最后整合的时候,就是跑不起来,不知道问题出在那,苦B的一个个查,一个个改
4 不安排好时间,总认为不需要花太多时间,开始也不紧张,到最后发现问题越来越多,上线时间一直拖了再拖.
5 代码没注释,这个就不用多说了,你写的代码如果写的本身就烂,还不加注释,交给别人维护的话,被人打死都不奇怪。
等等
2,你在项目的开发中,是否曾经给自己挖过坑?
自己估的时间太少,为了按时完成任务疯狂加班,结果还是有问题
复杂的代码没写注释,过几天自己再维护,都看不懂了...

3,在我们的项目开发中,怎样能尽量少给别人挖坑,当然也要少给自己挖坑?
需求阶段:一定要明确好需求,确定好了需求再做
设计阶段:要反复论证,自己的设计方案对不对,是不是能满足需求,并且要多和需求人员沟通
开发阶段:严格定制开发计划,明确分工,谁该做什么,什么时候该完成什么
项目管理阶段:明确每个分工的负责人,要尽可能准确的估算好开发时间,预留出足够的测试时间。任务要尽量往前赶,不要都留在最后。因为以后你也不知道会遇到什么问题,也许项目遇到难题,也许客户要改需求,等等。

海阔天空yy 回复

PS:想要数据线或手环

评论
0

王子健77 复制链接去分享

30岁开始编程有没有出路

ilaoniu 回复

没基础还是算了吧,编程要学的东西太多了,吃不消

景凌凯 回复

如果您真想从事编程的话,只要用心,什么时间都是不晚的。

评论
0

1309544984018831 复制链接去分享

没有压力就没有动力

我在蓝天 回复

比如说你的压力有多大?

景凌凯 回复

哈哈

评论
1

chao_chao_chao 复制链接去分享

这也是我数年前的事情了,那时也是写代码,最大的难题就是接手别人代码,那是相当 痛苦的一件事,完全不如自己来写,因为每个人写代码都有一套自己的思路,另外少踩坑最关键的还是研发统一制定开发规范,加上注释等

诸葛懒鬼 回复

命名规范,注释、需求、设计文档应该都是属于公司的制度,制度不完善,自然有各种漏洞。就像道德是约束自己的,法律才是约束大家的。

评论
0

nextabit 复制链接去分享

还好,尽量让自己满意就行。

景凌凯 回复

嗯嗯,自己满意,才是真的满意。

评论
0

1147445836230454 复制链接去分享

对阿里云还不是很懂,学习学习

景凌凯 回复

社区很多大佬的,都是你的资源

评论
0

我是长安 复制链接去分享

25岁开始学Java编程有没有出路?

景凌凯 回复

只要用心,什么时间都是不晚的。

评论
0

weiwang 复制链接去分享

程序员说产品坑,产品说程序员不按自己思路来坑自己

景凌凯 回复

那,自己设计,自己开发吧,什么产品的,不要不要la!

评论
0

1371345839508515 复制链接去分享

第一次接触,人生路不熟,请多指教

景凌凯 回复

好的,好的

评论
0

1903645834427466 复制链接去分享

你好,在吗

景凌凯 回复

有什么疑问吗?

评论
0

wangccsy 复制链接去分享

天天都在踩着各种坑前进。

0

老冯司机 复制链接去分享

客户需求反复无常,要杀人的心情啊

0

1083514732802325 复制链接去分享

论互联网人与IT人的区别!

0

1083514732802325 复制链接去分享

一头再牛逼的程序猿也干不过一只天马行空的产品经理😂

0

爱师德家教 复制链接去分享

???

0

漠北12333 复制链接去分享

后期都会有自己不满意的地方,尽管当时已经做的很满意了

2