VB   发布时间:2022-04-03  发布网站:大佬教程  code.js-code.com
大佬教程收集整理的这篇文章主要介绍了[技术讨论]代码编写能力与管理手段的配合大佬教程大佬觉得挺不错的,现在分享给大家,也给大家做个参考。

1、起言

西西 1小时前

青润,来点评一哈我在16楼的发言可好?http://topic.csdn.net/u/20091201/18/f3d35634-a780-4b9f-9a6d-acaaa24ac0ac.html

2、对话

看到后,我过去看了一下,下面是我的回复:
西西给我发消息,让我过来看看。
整体上西西说的很不错了。表扬的话不是我擅长的,我擅长批评,所以,大家多多包涵。
循序渐进,按照规律办事,这是做任何事情的基础,违反规律必然会受到惩罚,自己想想,我们写代码的时候其实也是一样的。
不过,关于西西提到的(4)测试驱动开发、步步为营,这里有一个问题不好控制,比如说,写代码时候的思路,不知道大家是否有过这样的经历,反正我有过很多 次,有些时候,我们对一个模块考虑了很久都无法下手,或者写出来的代码总是磕磕绊绊的,流畅性很差,但是,在一些特殊的时候,头脑中就很有灵感,一两个小 时可以写出以前几天甚至十几天都写不出来的代码速度和代码质量,当遇到这个情况的时候,步步为营反而会影响思路的展开,形象一些的比喻就是:胸有成竹的那 种感觉,或者如同王羲之写兰亭序那样,纵横开阖,一泻千里,痛快淋漓之至,这时候写出来的代码质量也是非常之高。
我02年5月在上海做权限系统开发到第三个版本,从一对n到m对n授权(每个人可以接受多个不同的权限,每个权限分配给多个不同的人)版本修改的时候就是如此,全部代码在三四个小时内一气呵成,完成后,一次通过全部测试。
这个时候如果有人让我步步为营,我估计非要拿刀把他劈了不可。

软件开发是个人性化很强的过程,一切都是人为,一切都是与人相关,管理手段和措施都应该围绕着人,如何激发人的主动性和促使人的积极性提高而活动,当然,在国内还很少有管理者能做到这个层面,包括外企业是如此。
软件开发中的随心随意也应该有所控制,但是控制到底到什么程度,就需要管理者自己的经验和胆量来作决定了,至少目前做出这样的量化是比较困难的,所以,也 许说水无常形,事无常规更合适,不过,这就要看管理者了,不是任何人都应该去享受这样的管理的,毕竟人、公司、团队千变万化。

好了,其他的就不多作评论了。

引用 16 楼 slowgrace 的回复:
给你另外一个视角供你参吧。

我觉得要一开始就把代码的整体结构(我没用“架构”这个词,因为“连连看”是个不算大的应用)写的很好、很科学是不大可能的,所以有人提出软件开发中要“拥抱需求的变化”。

为什么不可能呢?因为软件的需求很难在最一开始想得非常清楚,即使是专业人员也做不到。(跑点题,其实我觉得所有事情都不可能一开始就想得很清楚,都得边 做边调整)。所以,可能最佳的工作方法像开车的时候把握方向,你不会一直沿一个方向不动,你会向左调一点、再向右调一点,然后持续一阵,然后路况变化,然 后你再继续左右微调。(这个例子不是我举的,是“极限编程”的作者在他的某本书的前言里提到的,我用自己的话复述一哈:)

既然软件在开发的过程中不可避免地要“返工”,我们不妨在开发软件之初为未来的“返工”打好基础。有一种打基础的方法叫“测试驱动开发”,这个的基本思想 就是在你开发的过程中你先写好测试,如果你要返工,没关系,你尽管改,但是改了之后要确保之前你写下的所有测试仍然能够通过。

还有一种为“返工”打基础的方法叫“重构”。别被这个词吓到,它无非是指,如果你遇到重复的代码,记得把它剥离出来成为一个单独的单元(或函数,或类的方法),以便日后你要返工的时候只要改这一处,而不是满世界重复地修补。

还有一种为“返工”打基础的方法叫“路标”。这是我杜撰的词。其实就是注释。要知道“好记性不如烂笔头”,甭管你多年轻、记性有多好,你也会忘记之前你的 逻辑、你的用意的。为了返工时不至于太难过,给你的每个函数每个模块加上注释头吧,M-ZTools可以帮你做得更容易一些。

“重构”和“路标”我做得挺多,我觉得在VB里还是很容易做到的,只要你足够有心。“测试驱动开发”我曾经尝试做,但是后来因为要学习些基础知识,暂时搁 置了。也曾经和赵老虎等童鞋探讨过在VB里这样做的可能,也还没有得到让我信服的结论。但不管是否要像“测试驱动开发”倡导的那样先把测试集写好吧,至少 你要做到“步步为营”。所谓“步步为营”是指,每做完一小段代码就立刻测试,确保你的代码可以正常工作,切忌写了一大堆代码,还没有任何测试。

对了,还有,你得有“地图”(这个也是我杜撰的名词)。所谓地图就是指对你的软件的整体描述文档,也许只是一个简单的框图。这个非常重要。一开始写代码的 时候,你觉不到它的重要,代码量增加后,你就需要它了。你需要这个地图告诉你,你的软件包括哪些模块,它们之间是什么关系,你的比较大的几个模块分别实现 什么功能,其中包括哪些函数过程方法属性,你要分门别类的描述它们,省得写重复的代码。

对了,还有一点,保持代码短小,据说是比较推荐的做法。如果功能复杂,不妨把它分割成几个sub,在主sub力分别调用这几个sub。这样你的代码逻辑看起来会很清晰。其实这也是一种重构

小结一下:
(1)路标
(2)地图
(3)重构:让代码简短无重复
(4)测试驱动开发、步步为营

3、总结

从软件整体上看,国外的管理强于国内,国内的管理大部分比较松散或者过于苛刻,差别就在于对度的把握上。可以说过于苛刻或者过于松散的管理都不利于程序员更好的发挥自己的主观能动性去创造更好的价值。
水无常形,地无常势,事无常规,人无常念,并不是否定必然关系或者否定管理或者否定稳定,其实是在另一个层面对稳定,对必然对管理的肯定。
——其实仔细看看就明白,这段话说得就是辩证法的内容,是我们初高中时候学过的政治理论课上讲过的东西,只是当时我们都无法理解,也不会应用,强硬的灌输,并没有带来太好的效果。

大佬总结

以上是大佬教程为你收集整理的[技术讨论]代码编写能力与管理手段的配合全部内容,希望文章能够帮你解决[技术讨论]代码编写能力与管理手段的配合所遇到的程序开发问题。

如果觉得大佬教程网站内容还不错,欢迎将大佬教程推荐给程序员好友。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。