r*******n
发帖数: 3020 | 1 做软件产品最重要的是软件运行强健，
所以写代码考虑多种可能的情况，
而这个又很靠经验。
大家能不能谈这方面的经验。 |
g*****g
发帖数: 34805 | 2 Unit test and refactoring, you may use generated UML to see
if there's unnecessary coupling. Generally, I would be more
concerned about bad coupling than bugs. If you code is well
structured, it's easy to fix bugs, when it's not, it can be
difficult and bring new bugs in your fix. That's why I like
refactoring if I smell something bad even when there's no bug.
【在 r*******n 的大作中提到】
: 做软件产品最重要的是软件运行强健，
: 所以写代码考虑多种可能的情况，
: 而这个又很靠经验。
: 大家能不能谈这方面的经验。
|
a****l
发帖数: 8211 | 3 1.不赶时间,不熬夜.
2.仔细干,多画图,多思考,多实验,多查资料,不要老想着直接码代码出程序.
3.不要玩技巧,老实的写简单的程序.不要写那种用来做考题的希奇古怪的语法组合.
【在 r*******n 的大作中提到】
: 做软件产品最重要的是软件运行强健，
: 所以写代码考虑多种可能的情况，
: 而这个又很靠经验。
: 大家能不能谈这方面的经验。
|
X****r
发帖数: 3557 | 4 个人看法：
1.想好了再写。先确定设计和接口再具体实现。设计和接口注意一定的通用性和扩展性
。实现的时候注意封装而不要抄近路。当你感到有迫切的抄近路的需求的时候多半说明
你的设计有问题。随着代码的发展和需求的变化原来的设计和接口一定会过时，所以要
有重构(refactoring)是开发中的常态的准备。
2.测试，测试，测试！从单元测试到集成测试，都要自动化，并且覆盖面尽可能得广。
测试是软件质量的第一道也是最后一道防线。
3.Code defensively（不知道中文怎么说）。首先是代码单元（比如函数和方法）必须
完全实现所宣示的功能而不依赖于额外的假设，比如按一定格式输出一个数，如果这个例程
没有声明只接受一定范围的数的话（除非有这样的必要，不然一般也不应该有这样的声
明），即使在当前的程序里这个数不可能超出这个范围也不要依赖于这个条件。更进一步
的，即使输入不完全符合接口，根据情况也可以考虑尽可能地完成操作，不过这种情况下要
留下记录，而且未必适合所有情况。
4.代码的可读性也很重要。没有比改一段自己还不太明白的代码更容易造成隐患的了。
【在 r*******n 的大作中提到】
: 做软件产品最重要的是软件运行强健，
: 所以写代码考虑多种可能的情况，
: 而这个又很靠经验。
: 大家能不能谈这方面的经验。
|
m*****r
发帖数: 130 | 5 我觉得看看成熟的好代码比较好，coding是个很灵活的东西，好的设计可以减少各个模
块间的耦合，好
的coder能很好实现每个模块，这算是大的方面的2点。
这个我觉得还和个人的追求有关，有的人糊弄事，有的人精益求精。
【在 r*******n 的大作中提到】
: 做软件产品最重要的是软件运行强健，
: 所以写代码考虑多种可能的情况，
: 而这个又很靠经验。
: 大家能不能谈这方面的经验。
|
r*******n
发帖数: 3020 | 6 could you pls give a simple example you smell bad?
【在 g*****g 的大作中提到】
: Unit test and refactoring, you may use generated UML to see
: if there's unnecessary coupling. Generally, I would be more
: concerned about bad coupling than bugs. If you code is well
: structured, it's easy to fix bugs, when it's not, it can be
: difficult and bring new bugs in your fix. That's why I like
: refactoring if I smell something bad even when there's no bug.
|
g*****g
发帖数: 34805 | 7 Addison Wesley - Refactoring Improving the Design of Existing Code
You can check this book for examples. I can't sum up better.
【在 r*******n 的大作中提到】
: could you pls give a simple example you smell bad?
|
r*******n
发帖数: 3020 | 8 关于2里的“多查资料”是指查哪方面？业务逻辑方面？
我觉得查资料是耗时多，不好控制进度的重要原因。
【在 a****l 的大作中提到】
: 1.不赶时间,不熬夜.
: 2.仔细干,多画图,多思考,多实验,多查资料,不要老想着直接码代码出程序.
: 3.不要玩技巧,老实的写简单的程序.不要写那种用来做考题的希奇古怪的语法组合.
|
r*******n
发帖数: 3020 | 9 Thanks
【在 g*****g 的大作中提到】
: Addison Wesley - Refactoring Improving the Design of Existing Code
: You can check this book for examples. I can't sum up better.
|
g*****g
发帖数: 34805 | 10 Actually I kind of oppose this, not saying you shouldn't
try to know about business logic before you proceed. But
I like to go down to details only when necessary, and I
like test driven approach that you can have short iteration
and visible milestone and others can be involved in testing
early, this is a principle in all agile methodologies.
【在 r*******n 的大作中提到】
: 关于2里的“多查资料”是指查哪方面？业务逻辑方面？
: 我觉得查资料是耗时多，不好控制进度的重要原因。
|
|
|
r*******n
发帖数: 3020 | 11 还是关于查资料，
比如 客户要求加入新的功能，而我又不确信能做，
需要查资料，甚至要写一点测试代码，
那这个时间怎么算？
或者说合同里没有直接拒绝，或作为下一个版本功能。
【在 g*****g 的大作中提到】
: Actually I kind of oppose this, not saying you shouldn't
: try to know about business logic before you proceed. But
: I like to go down to details only when necessary, and I
: like test driven approach that you can have short iteration
: and visible milestone and others can be involved in testing
: early, this is a principle in all agile methodologies.
|
x****u
发帖数: 44466 | 12 顶这个，强烈同意。
【在 a****l 的大作中提到】
: 1.不赶时间,不熬夜.
: 2.仔细干,多画图,多思考,多实验,多查资料,不要老想着直接码代码出程序.
: 3.不要玩技巧,老实的写简单的程序.不要写那种用来做考题的希奇古怪的语法组合.
|
o******r
发帖数: 259 | 13 4.3.2.1
个例程
【在 X****r 的大作中提到】
: 个人看法：
: 1.想好了再写。先确定设计和接口再具体实现。设计和接口注意一定的通用性和扩展性
: 。实现的时候注意封装而不要抄近路。当你感到有迫切的抄近路的需求的时候多半说明
: 你的设计有问题。随着代码的发展和需求的变化原来的设计和接口一定会过时，所以要
: 有重构(refactoring)是开发中的常态的准备。
: 2.测试，测试，测试！从单元测试到集成测试，都要自动化，并且覆盖面尽可能得广。
: 测试是软件质量的第一道也是最后一道防线。
: 3.Code defensively（不知道中文怎么说）。首先是代码单元（比如函数和方法）必须
: 完全实现所宣示的功能而不依赖于额外的假设，比如按一定格式输出一个数，如果这个例程
: 没有声明只接受一定范围的数的话（除非有这样的必要，不然一般也不应该有这样的声
|
l******e
发帖数: 12192 | 14 three points: design, boundary check, QA
【在 r*******n 的大作中提到】
: 做软件产品最重要的是软件运行强健，
: 所以写代码考虑多种可能的情况，
: 而这个又很靠经验。
: 大家能不能谈这方面的经验。
|
s*****g
发帖数: 5159 | 15 写两遍。
【在 r*******n 的大作中提到】
: 做软件产品最重要的是软件运行强健，
: 所以写代码考虑多种可能的情况，
: 而这个又很靠经验。
: 大家能不能谈这方面的经验。
|
O*******d
发帖数: 20343 | |
