V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  V2XEX  ›  全部回复第 1 页 / 共 2 页
回复总数  37
1  2  
2019-03-01 22:26:23 +08:00
回复了 sdushn 创建的主题 Android 新入行,求教安卓学习之路
卧槽,我们告诉领导说以后要培训我们搞 app,怎么整(原来是搞 java 后端的)
2019-03-01 22:20:27 +08:00
回复了 V2XEX 创建的主题 程序员 今天换回薄膜键盘
@shanlan
@ericbize
@gzlock
你们讲的这些问题我从来没有遇见过啊,貌似很多人力推机械也不是因为“薄膜键盘故障率高”吧?
相反地,那些便宜机械没用多久会有卡顿、粘滞情况甚至会滋滋作响(别问我这么知道的,匿了),此种情况下的机械键盘手感只能用恶心来形容,这个手感变异的情况在薄膜键盘上是不可能出现的。
2019-02-24 00:36:04 +08:00
回复了 fengleidongxi 创建的主题 程序员 求推荐核显笔记本电脑
可以看看 nuc
2019-01-28 19:32:26 +08:00
回复了 flyindance 创建的主题 Java # querydsl
orm 就 orm,sql 就 sql,你写这个比原生 sql 好在哪?少打几个字吗
2019-01-21 17:03:16 +08:00
回复了 V2XEX 创建的主题 全球工单系统 Firefox 插件无故丢失!
@xuyuehang

插件都还能用,懒得折腾了.真的只是个浏览器而已,不是不可替代的,再出什么问题直接换了了事
2019-01-20 17:59:52 +08:00
回复了 ranleng 创建的主题 全球工单系统 微信朋友圈 bug. 字体超级大。
每一次想你,我都要提醒自己什么
2019-01-09 09:53:58 +08:00
回复了 V2XEX 创建的主题 程序员 两个含有大量重复字段的表需要设计成一张表吗
@d3vil
感谢您的回答,工程的问题涉及到方方面面,有时可能需要将视野放宽才能解决。
至于我说的“浪费空间”的空间,也许我的表达不太准确……我并是不指浪费了物理意义上的空间,而是设计了两张包含大量的重复字段的表让我有种“ repeat your self ”的冗余之感,当然设计表不同于写代码,也许这么设计也没问题?


此项目确实只是个小项目而已,但如果不加思考闭着眼睛那就是真的 it 民工了
2018-12-19 10:02:14 +08:00
回复了 ukipoi 创建的主题 Java 请教一下 Java MVC 设计里业务层的'业务'是什么?
@passerbytiny 你总结得不错
还记得刚开始学框架时心里就一直有一个疑问:所谓的 MVC 分层的这个 m 为何没有按“面向对象”的思想承担起属于自己的“行为”。
依你看,现在把所谓的“业务放到” pojo 里的做法是否妥当呢?
java8 及其以后的各版本解决了很多问题了,不知道还有必要学 kotlin 不
@no1xsyzy 我想了下,感到这确实也是个经验问题。
开始我假设的情况是“定需求"这个环节能做到最好,那么开发过程中很多看似由程序员造的坑即可避免(当然,在这种需求都给清楚了的情况下,程序员还能犯错那自然是难辞其咎的)。

然而我假设的这种条件是苛刻的,作为一个开发者自然不能去要求其他人(甚至是上司、客户),把“定需求”这个环境做得完美,在实现需求的过程中要做的工作也不止”按图画画“这么简单,有经验的人听到别人说了 1+1 自己马上能想到 10+10 甚至开始为 10x10 做准备了,我在写代码前确实“想”得少了,就自身来说还是个经验问题。

下次写代码前还是得多花时间去“想”,这样在起步阶段也许会慢,但是把这个工作做了,那项目将会更健壮,容错率也更高。
@no1xsyzy 我只是举个例子而已……那以后我还要加其他东西呢?你势必要写其他的方法、类,把可重用的东西抽象,这个谁都知道。
如果你开始就知道要接收用户输入按需打印,那你大可以规划一个输入模块,一个计算打印内容的模块,一个打印模块等,代码不仅井井有条、漂漂亮亮,还利于维护拓展,这就是你说的“模块划分很好”了,但是在开始做的时候没人告诉这些,加上时间紧任务重,我想是个正常人都直接写个 system.out.print (“ hello world ”),以后改什么直接在上面加,这样久而久之垃圾代码就出现了…

还有,你自己给自己定的需求,别说过段时间改一次了……可能这一秒跟下一秒是完全不同的两个想法,那直接抄起键盘就开干,但是你摸良心说说这和客户\产品经理给你改的需求是一回事不……
@no1xsyzy 发现模块化做得很好是什么鬼。我说的改需求是:开始只要你打印一个 hello world,后来要你打印十次,再后来要你根据我输入的次数打印并且还要附带我输入的内容……这种的改需求你能在一开始就预料到了?

如果一定要说面对频繁更改的需求,并在开始写代码前就能预料到客户想法并写出条理清楚、结构清晰,可维护性高的代码如此简单的话,我想“扫码改需求”这种事情就不会成为程序员们所调侃(单自己做的 toy project 不在我说的范围内,产生需求和解决需求都是自己,没有什么东西在约束和评价,与实际多数人都在从事的开发工作不是一回事)
@yfl168648 确实是个好思路

@Kiske
1、单就现在的简单需求(真的不考虑后续维护)来说,两种做法哪种更优?
2、个人感觉 find in set 不如 like 啊,因为前者的“分组”操作是一个开销,我已用 uuid 储存(非自增 id ),不会出现误查的情况 。不知 MySQL 的 like 查询是否有短路机制。
3、不瞒你说,我想在在搞的东西需求简单,还真想过把对象全转 json 存数据库,但考虑到数据库操作 json 肯定要经过解析这一步,每条数据都解析一遍开销略大,罢了。你讲的维护的事情涉及到东西很多,有时候不是程序员的水平不行,迫不得已写垃圾代码谁也没办法(每天都有新需求,每天都要改需求,你懂的)。
4、关于项目分层,我觉得 mvcs 的分层好像和“面向对象”的思想有些出入,本想在本帖一并讨论,但又感觉两者非同类问题。不日我将另发一帖讨论。
@MegrezZhu
不是啊……
1 将已读用户写入帖子表意思是把 uuid 写入帖子表的 readers 字段并用逗号分隔,比如像这样:uuid1,uuid2,uuid3
某个帖子每被浏览一次就更新对应帖子的这个字段
2 删除是指帖子可能会被删除,而不是删除浏览记录,如果有中间表那对应帖子的所有浏览记录都得删,不知对比将帖子整个删除这是否是个额外的花销(软删除同理)
@MegrezZhu 有 n 个帖子,m 个用户,那么这张中间表至多就会有 m × n 条记录,以后每新发一个帖子至多会增加 m 条记录。还需要考虑删除情况……这样的开销对于原来直接将用户 uuid 写入帖子表某个字段来说不知道哪个更优?
@xiangyuecn 等我意识到这么设计表有多蠢的时候就会扇自己两巴掌
@MegrezZhu 但是这么设计的话这张中间表的记录数很容易就是几何级数增长啊,而且当有删除需求时这张表将承载更多任务
@Inside 那就这个功能来说,数据库应该如何设计呢?请指教……
@xy90321 其实就算不全拿出来,统计的根本逻辑也是在数据库中实现了,两个做法的区别就是统计的逻辑放在哪里
2018-12-04 21:30:35 +08:00
回复了 Gaussen 创建的主题 程序员 有些迷茫,希望得到一些指点。
我最近也有些迷茫。
这些所谓 的“技术”,如果是自学,但原来的公司用不到,自己折腾能折腾出什么有价值的玩意呢?毕竟这些东西都是为了产出,为了服务“项目”而生的。
但要是不学,去到稍大规模的公司,这些都是招聘的要求……
1  2  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2650 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 66ms · UTC 15:49 · PVG 23:49 · LAX 08:49 · JFK 11:49
Developed with CodeLauncher
♥ Do have faith in what you're doing.