首页   注册   登录
 yulitian888 最近的时间轴更新

yulitian888

V2EX 第 219829 号会员,加入于 2017-03-09 09:32:33 +08:00
今日活跃度排名 13691
yulitian888 最近回复了
1 天前
回复了 default7 创建的主题 程序员 程序员一直进小作坊的结局会怎么样
@default7 CURD-->CRUD???
要说不难的话,并发和隔离级别算不算 CRUD ?难不难?还真不难,但是面试遇到好多人(实际上是大多数人)横竖就是不会怎么办啊?
级联更新和级联删除算不算 CRUD ?难不难?也真不难,但是实际上这块出的 bug 最多最常见!
事务 /分布式事务处理算不算 CRUD ?性能调优算不算 CRUD ?嗯,再想想,CRUD 真的不难吗?

to 楼主:上面说的这些,不论是小厂还是大厂,都是需要掌握的基本功。但是在大厂环境下,由于分工原因,基层码农很可能不会接触到(上层框架封装好的可能性很大),从而无法打牢基本功。反而是小厂,比较容易提升一些。当然,小厂也不能待太久了,树挪死,人挪活。
15 天前
回复了 zero47 创建的主题 程序员 关于数据加工,前端后端责任讨论
来来来,举几个例子:
1、前端需要显示时间,但是要按照客户所在的时区和不同的 Format (“年月日”/“月日年”)呈现时。
2、终端存在多语言客户时。
3、多个终端( Web、APP )取同一个后端资源且输出内容稍有不同时。
4、前端请求数据过大,存在优化空间时。如若干个小的 tree 或 list 返回在前端拼装成 list 输出,要比后端直接提供 list 传输量小。
5、后端 API 不是自己的项目所提供的。

以上情况,谁会选择让后端处理,那才是见了鬼,尤其是情况 5。

但是另一些情况则刚好相反,比如楼主说的查询优惠券,交给前端处理才是脑子进水了。
所以这个问题根本没有标准答案,一切都要依据实际情况具体分析决定。而且摆在面前的选项绝对不是非此即彼的,某些时候是需要前后端各做一部分数据操作,两端同时处理的。
26 天前
回复了 javaWeber 创建的主题 程序员 如何对待团队里水平比较差的成员?
跟不上团队节奏的人,丢到别的团队,或者直接开掉吧,对大家都好。
跟得上团队节奏的人,这个问题还是个问题吗?
34 天前
回复了 Oreo007 创建的主题 程序员 今天从同事口中听到一个词:希哈值
楼上听说过一种读做“滴嗨”的编程语言吗?
对,就是那个“滴嗨”,原名叫做 Delphi 的!
40 天前
回复了 zarte 创建的主题 .NET .net 页面跳转报正在中止线程错误
因为没有结束请求的响应过程,加上 CompleteRequest 就好了
我写的一个扩展方法,直接引用了就可以用 response 实例.RedirectTo("地址")来跳了

public static class HttpRedirect
{
public static void RedirectTo(this HttpResponse response, string url)
{
if (response.IsRequestBeingRedirected)
{
return;
}

response.Redirect(url, false);
var context = HttpContext.Current;
if (context != null)
{
context.ApplicationInstance.CompleteRequest();
}
}
}
42 天前
回复了 shuAS 创建的主题 程序员 api 接口如何做到毫秒级响应?
@xiaobai987 百兆的效果属于肉眼可见差异水平,千兆就属于肉眼不可见了
43 天前
回复了 shuAS 创建的主题 程序员 api 接口如何做到毫秒级响应?
什么用途 /性质 /功能的 API ?
一个请求的毫秒级响应还是并发请求的毫秒级响应?
嘛都不说,没头没脑的问题,没法答
影响程序相应的最大瓶颈一般都是 IO。一般而言 IO 速度最慢的顺序是:网络>HDD>SSD>RAM>寄存器,自己分析哪块是你的 API 瓶颈,再具体想办法优化就是了。

不过我也见过有些啼笑皆非的负优化。
某人企图用 Redis 提升查询性能,但是把 Redis 部署在局域网另一台机器上。好巧不巧的是,路由器上被人插了一个百兆设备(路由器自适应降速到百兆了),然后在这个“百兆局域网”里的 Redis 不光没能提速,反而降速了。
51 天前
回复了 v2overflow 创建的主题 程序员 存储过程真的很难么?
@rockyou12 so?不同数据库的区别是客观存在的能说明什么?抛弃个性化功能,只使用共性功能是唯一正确的选择吗?呵呵呵~~~
真实项目中,数据库更换的概率实际发生的情况极少,而且几乎都是本地库上云,或者 SQL 换成 NoSQL 的迁移方案居多。类似 MySQL 换 Oracle 啊,SqlServer 换 MySQL 啊,这种事情只存在于培训班的老师嘴里
51 天前
回复了 v2overflow 创建的主题 程序员 存储过程真的很难么?
"因为存储过程太复杂,后续的人不好接手"
前半句是错的,后半句不完全对。
存储过程(语法)本身不复杂,就是纯粹的 SQL 语法,复杂的是用存储过程编写的查询逻辑。而这种复杂的逻辑,无论是用存储过程还是用程序代码来实现,都不会变简单。
至于后续的人好不好接手,取决于对业务的熟悉程度,对数据表的熟悉程度,而不是取决于实现方式。只要文档缺失,你换成 java 写一样复杂的逻辑,难道就好接手了吗?

“要求所有数据的处理都读出来用 java 程序处理”
嗯,那么应该让这个领导试试看做千万级的数据表同步功能试试看吧?不复杂,A 表到 B 表,结构一致,不跨库,做程序维护一下数据同步就好!

实际上如果存储过程真的这么罪大恶极,那么它显然不会成为行业标准( SQL 99 )的内容,早就应该被历史的车轮碾成渣渣了。放弃存储过程意味着什么呢,各种数据库技巧,比如临时表、表变量、已缓存的查询计划等众多数据库特性基本等于不存在了。这种把数据库打成残废的招数,呵呵呵~~~~

另外,前面有人说不能源码管理,纯属胡扯。所有能写成脚本的东西都可以被源码管理起来。
@geelaw 然而你说的这种写法并没有生效,这也是我第一时间想到的写法,然并卵
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2718 人在线   最高记录 5043   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 16ms · UTC 11:17 · PVG 19:17 · LAX 04:17 · JFK 07:17
♥ Do have faith in what you're doing.