This topic created in 2635 days ago, the information mentioned may be changed or developed.
Supplement 1 · Aug 16, 2019
主要是看很多设计模式的书都会写，“要做有弹性的设计” 或者类似于“现在需要一只灰兔子，以后可能需要一只蓝兔子”，这里的蓝兔子大佬们写代码的时候会怎么考虑呢？
 |
1
把自己的智商拉到跟产品或者客户同一水平后考虑。
|
3 |
fox0001Aug 16, 2019 via Android
2
会考虑设置一些灵活的参数
|
 |
itskingnameAug 16, 2019
3
项目的第一个版本我不会考虑需求以后太大的变化。
从第二个版本开始，通过对比第二个版本和第一个版本的差异，来预估以后需求变化的频率和程度。 |
 |
AngryPandaAug 16, 2019 via Android
4
想的太多的结果是，哎呀，项目 delay 了，绩效被扣了
|
 |
qdlAug 16, 2019
5
想那么多做什么，老夫拿起键盘就是干....🐶
|
 |
xiaoyang7545Aug 16, 2019
6
我们经常出现后面的需求跟前面的需求逻辑上完全冲突。所以考虑那么多好像没啥用，还是得改。
|
 |
jacsiceAug 16, 2019
7
一楼说的精辟啊，别自己瞎捉摸，产品的思路你跟不上。。。
|
 |
TobiahShawAug 16, 2019
8
可以稍微考虑，别考虑太多，具体原因同 1 楼，会让你考虑的东西完全没用
|
 |
EgflyAug 16, 2019
9
会做一些预留吧，从业务的发展的趋势来考虑。这些预留大多数是数据库设计上
|
 |
q8164305Aug 16, 2019 via Android
10
写代码的时候都是怎么快怎么来，从来不考虑扩展，有时间再重构
|
 |
lizhendaAug 16, 2019
11
别想太多，尽量最简单实现，解耦，内聚。因为你会发现需求变更完全是推到重做，所以，不要提前优化
|
 |
VegetableAug 16, 2019
12
看产品水平.
|
 |
good1uckAug 16, 2019 via Android
13
基本都是建议怎么快怎么来的
|
 |
mcfogAug 16, 2019 via Android
14
当然要考虑，但是什么叫多大程度？怎么个设计架构，花多少精力在预备未来的需求变更上这个东西本身就是考虑的结果
|
 |
PythonKGBAug 16, 2019
15
这东西跟产品水平根本没关系
大部分看需求方的要求 比如我们的客户是政府客户，他们说要修改，前后逻辑都是违背的，项目经理控制失败了（政府你怎么控制？） 这个时候产品只能硬着头皮和技术去改动。 技术当然要考虑好变更甚至重做的可能了。 |
 |
gabezhaoAug 16, 2019
16
产品的思路和你不一样的，想多了没用
|
 |
tabris17Aug 16, 2019
17
看有多少时间了
|
 |
lazypuAug 16, 2019
19
我尽量一个方法做一件事，至于其他的，特别是需求的变动，比女人的心思还难猜。
|
 |
archersgzAug 16, 2019
20
别多想，快最重要．
|
 |
viator42Aug 16, 2019 via Android
21
还是应该预留一些
|
 |
akiraAug 16, 2019
23
会考虑的，但是会不会去实现就不一定了
|
 |
BALDOORAug 17, 2019 via Android
24
见过功能小改三遍代码不动的应届新人，真的牛批
也见过小改一点然后改一处代码 N+年的领导，也牛批 嗯，…… 我……我在摸鱼呢…… |
 |
wemoreAug 17, 2019 via Android
25
已经被用户坑多了放弃思考，顶多把一些单选的内容以多选为前提设计（个人经验哈）
|
Select Language