※ 引述《gname ((′口‵)↗︴<><...<><)》之铭言： : ※ 引述《zanyking (遥远的旅人)》之铭言： : 光是看到第1点就很有感触了... : 打着快速开发的口号,让很多人误以为会用点AJAX,JQuery,ExtJs 之类 : 的API,就能在WEB上吃透透,结果反而忽略了很多基本的东西... : 经常就是看到拿牛刀来杀鸡... : 举个使用记忆体的例子... : 蛮多半途出家的工程师根本就不懂得什麽叫作演算法,资料结构之类的东西... : 要做一些资料运算时,就通通一次拉到记忆体里面就对了... : 反正记忆体很大用免惊的啦~ : 一个阵列里面拉了几十万笔资料,在运作时会稍微有点LAG... : 但是当一个阵列里面拉了百万笔资料时,会发生什麽事? : 是的,运气差一点就当掉而已嘛,没什麽啊... : 然後花了大把的时间在DEBUG为什麽会当掉? 明明程式就没错啊... : 我很想讲, 老兄~ 你要不要考虑把整个DB通通倒进来记忆体会不会方便一点? : 一个select 就 left join 6张表, 资料量大到一整个夸张... 在LV4 还有很多东西算是我个人主观的东西所以我没有提，例如： 『百步法则(hundred step role)』还有『如何吝啬的管理Java记忆体』 Java PG在编写程式的时候常常只从OO抽象的角度去看如何实做，而不能从整个系统 (VM, OS, network)的角度去看『该怎麽选择solution』。 如果你是Java developer，你的工作包括全局的程式架构设计，那你可不是只有 Spring + Hibernate 看个几下会用就可以乒乒乓乓写程式了。 光只是开JPA 的 EntityBean 而已，你就应该得要去思考： Entity的读跟写。只读物件需要每次用还重新跟资料库拿吗？ EntityManager的生命周期大小。EntityManager该活多久？每次Transaction完就重抓 还是一个Request内都用同一个？ ORM one to many时该lazy还是Eager？话说回来one-to-many真的该用吗？你是不是 常常做出『弱水三千只取一瓢饮』的傻事，只因为map.get(pk);程式码很短？ Query发生的多频繁？有多少地方因为架构所以你会做出: Foreach detail in A(while A = select * from orderdetail last year) Sum += detail.getPrice(); 这种令人发指的事情？ 光这个小题目能够继续列下去就还有很多，包括Session Serialization 如何对Bean 做didActivate, doPassivate、Transaction Critical Section的确保、 JPA Provider的选择、second cache 的设定与优化等种种议题... 写程式考虑太多可能会写不下去，不过，如果你想做重要的东西、钱想领的不错， 这些事情就要训练自己去考虑。 : 之前公司有位爱用AJAX的同事,对於AJAX已经是到完全滥用的境界... : 资料量少时还OK,等程式到了客户那里所有的资料都import进来时, : 每次执行就是必当机,後来又得麻烦其它同事去改写架构... : 要建万丈高楼,地基就要挖的深,打的好... : 只是现在很多人都是地面上叠了砖块就在盖楼... 一个系统依据使用者的原始需求、预算、新技术产生的新门槛、Production环境 硬体规格，设计上就会有所不同。 AJAX从2005年到现在也快5个年头了。 Ajax要不要使用、用哪一种Framework、用在哪里是得要先评估的，例如： 这是个CPU Bound的系统，还是IO Bound的系统？ 这个系统会对外开放、还是单纯对内？ 使用人数是什麽等级？ 系统本质是Content Base 的还是Application Base的？ 要不要SEO？ 届时per Session会占多少记忆体？ UI要快还是要满？ (以下10项略)... 有的人跟我说，做网页很简单，大家都去做赚不了几个钱。 我说『观念清楚确实也没什麽，只不过你所谓的网页很有可能跟我所想的东西 差很远就是了。』 -- 我所信仰的科学是一种谦卑的理性，承认自身的无知与渺小才能观察到世界在我们贫 弱的知觉上留下来的痕迹。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 123.193.177.110