![]() | 1 phpcxy 2019-08-16 09:16:02 +08:00 ![]() 把自己的智商拉到跟产品或者客户同一水平后考虑。 |
2 fox0001 2019-08-16 09:25:19 +08:00 via Android 会考虑设置一些灵活的参数 |
![]() | 3 itskingname 2019-08-16 09:38:30 +08:00 项目的第一个版本我不会考虑需求以后太大的变化。 从第二个版本开始,通过对比第二个版本和第一个版本的差异,来预估以后需求变化的频率和程度。 |
![]() | 4 AngryPanda 2019-08-16 09:39:44 +08:00 via Android 想的太多的结果是,哎呀,项目 delay 了,绩效被扣了 |
![]() | 5 qdl 2019-08-16 09:42:30 +08:00 想那么多做什么,老夫拿起键盘就是干.... |
![]() | 6 xiaoyang7545 2019-08-16 10:05:09 +08:00 我们经常出现后面的需求跟前面的需求逻辑上完全冲突。所以考虑那么多好像没啥用,还是得改。 |
![]() | 7 jacsice 2019-08-16 10:17:0 +08:00 一楼说的精辟啊,别自己瞎捉摸,产品的思路你跟不上。。。 |
![]() | 8 TobiahShaw 2019-08-16 10:24:12 +08:00 可以稍微考虑,别考虑太多,具体原因同 1 楼,会让你考虑的东西完全没用 |
![]() | 9 Egfly 2019-08-16 11:17:28 +08:00 会做一些预留吧,从业务的发展的趋势来考虑。这些预留大多数是数据库设计上 |
10 q8164305 2019-08-16 11:28:18 +08:00 via Android 写代码的时候都是怎么快怎么来,从来不考虑扩展,有时间再重构 |
![]() | 11 lizhenda 2019-08-16 11:40:30 +08:00 别想太多,尽量最简单实现,解耦,内聚。因为你会发现需求变更完全是推到重做,所以,不要提前优化 |
![]() | 12 Vegetable 2019-08-16 11:42:12 +08:00 看产品水平. |
13 good1uck 2019-08-16 12:26:07 +08:00 via Android 基本都是建议怎么快怎么来的 |
![]() | 14 mcfog 2019-08-16 13:17:03 +08:00 via Android 当然要考虑,但是什么叫多大程度?怎么个设计架构,花多少精力在预备未来的需求变更上这个东西本身就是考虑的结果 |
![]() | 15 PythonKGB 2019-08-16 16:07:33 +08:00 这东西跟产品水平根本没关系 大部分看需求方的要求 比如我们的客户是政府客户,他们说要修改,前后逻辑都是违背的,项目经理控制失败了(政府你怎么控制?) 这个时候产品只能硬着头皮和技术去改动。 技术当然要考虑好变更甚至重做的可能了。 |
![]() | 16 gabezhao 2019-08-16 16:19:46 +08:00 产品的思路和你不一样的,想多了没用 |
![]() | 17 tabris17 2019-08-16 16:20:22 +08:00 看有多少时间了 |
19 linxl 2019-08-16 17:23:12 +08:00 我尽量一个方法做一件事,至于其他的,特别是需求的变动,比女人的心思还难猜。 |
20 archersgz 2019-08-16 18:05:11 +08:00 别多想,快最重要. |
![]() | 21 viator42 2019-08-16 18:08:11 +08:00 via Android 还是应该预留一些 |
![]() | 23 akira 2019-08-16 22:06:33 +08:00 会考虑的,但是会不会去实现就不一定了 |
24 BALDOOR 2019-08-17 10:47:26 +08:00 via Android 见过功能小改三遍代码不动的应届新人,真的牛批 也见过小改一点然后改一处代码 N+年的领导,也牛批 嗯,…… 我……我在摸鱼呢…… |
25 wemore 2019-08-17 22:16:15 +08:00 via Android 已经被用户坑多了放弃思考,顶多把一些单选的内容以多选为前提设计(个人经验哈) |