作者TonyQ (沉默是金。)
看板Soft_Job
标题Re: [闲聊] 环境令人无力orz
时间Mon Mar 29 13:55:07 2010
※ 引述《superpai (超级白)》之铭言:
: → atst2:个人很有兴趣想听听对"工程"不同的想法,Tony兄愿意分享一下 03/29 13:04
: → atst2:吗? 想法不同是一定会的...也请让在下参酌看能否有所助益? 03/29 13:04
整理一下也好,其实很多想法都是自己从过去经验得来的,
所以本来就是应该拿出来一起讨论甚至是来让人指责的,
推文这样讲其实我也觉得蛮混乱而且有一些矛盾,
有些条件假设跟环境假想没办法说得很清楚。
当然讨论这个话题前,我非常同意原PO根本就找错战场做错事;
这点是毋庸置疑的。
但是我这篇要说的是,因为现在已经有一连串的既有结构,
所以「就工程的观点」,新的结构必须舍弃而配合旧有的结构;
这点我是不认同的。
我认同的是「就成本控制的考量下」,
只解决最低程度的问题(能解决使用者碰的到的问题),这是我认同的。
换做是我在赶deadline一样是要求到哪里就做哪里,
所以我才说原PO找错战场做错事。
-------------------------------------------------------------
所谓的(软体)工程是指从事前的问题定义到进一步的问题规划,
再到找解决问题的团队(人)、到解决问题,
(依照不同工作模式可以有不同的作法)
到软体完成後,後续的需求维护的处理等。
其中在实作问题的部份应该尽量地将问题拆解出结构、介面分明的子问题,
以个别击破的方式来进行系统的设计,
并且再试着实际演变的需要来调整、重新设计系统。
-------------------------------------------------------------
所以「以工程观点」来看原本的两个问题:
1.就既有的模组已经很多,所以新的模组都需要遵循旧的模组而言
这一块最大的问题应该是「你新的模组会不会破坏掉旧的模组」。
首先良好工程的定义,应该是要遵循最大可能性内,
以定义出合作的介面来实做,以达到最大的相容性。
以这个例子而言,table design 跟css design 其实要拿来相比的前提下,
几乎都是版面最外层的 layout ,
不太会有 table 跟 css layout 混用的情形,
就算有混用的情形,其实css box 跟table box 也不会有打架的情形,
所以要说旧的模组因为新的模组而不能用,我觉得可以打个问号。
(当然不排除是小弟才疏学浅没考虑到所有的情形)
但是也不应修改旧的模组来适应新的模组,
理想的作法应该让两者并存,才磨的出弹性。
通常是在於因为环境的改变跟知识的获得,旧的模组不堪使用,
且旧的模组可以用更有效率的方式组织,这种时候我们才会去重构,
而重构本身是一种加速作业处理的方式。
如果真的要采用工程的状况,
才更该因为加入了新的元素而把介面定义的更加清楚,
让这个工程结构更形稳定,css也行、table也行,取得更大的弹性。
至於人员维护,现在学 css的人只会更多不会更少,
table 现在仅剩的舞台的只是「区块式」的编排,
现在举凡各类样式设定,只要有搭配到js做互动的应用,
几乎都是以 css 的应用为主,再者 margin,padding,
border,background-position等属性,css spirit 等设计方法;
还有一些常见如hover等状态,另外就是position定义位置的弹性,
在在都是需要 css 的大力配合。
(这边是从目前实务上的需求面来看,不是说原po的公司。)
2.再来需要讨论的是 table design / css design的效率跟必要性。
如果今天这个介面完全不需要修改的前提下,table 约等於 css ,
只要一有介面修改得情形,css 绝对乐胜 table design。
(先假设以原po的条件已经能够掌握 css ,
不会有o版友碰到的那个状况。XD)
再来是技术因素, dom 物件量的数量(影响到页面执行时间)、
程式码的乾净程度跟资料量(影响到载入速度跟review的速度),
因为以上的影响,所以连 js 的效果都变得好写不少。:3
(写js一直在爬好几层的td是很可怕的事情。)
这一块是只要是有在这一个小圈子打滚的人,都会认同的压倒性胜利,
不过很可惜不在这个圈子的人就完全感受不到。
-------------------------------------------------------------
我是认为就工程的观点而言,纳旧入新才是更能稳固地基的作法,
难道哪天招不到用 table 设计的人公司就要倒了吗? XD
这样就是所谓「工程」的精神吗?:)
-------------------------------------------------------------
我再次强调,这整篇文章都只是在陈述「(软体)工程」之於专案,
应该是一种开放改革的态度,而不是封闭守旧的藉口。
原po 的问题不应该以工程角色来扣帽子。
--
▄▅▆▇███▇▆▅▄▃ ╰┼╯─╮ ╮
◥███████████◣ ╰┼╯=│=│
◥██████───────◣ *. ╯ ╯ ╯ の 物 语 .*
◥███████──────◣ ~ ◢◣ ◢◣
◥██████───────◤ ◥◤* 空白的世界.翼
*◥◤
◥██▁▂▃▄▅▆▇███▆▅▄▃▂▂
~telnet://tony1223.twbbs.org
--
※ 发信站: 批踢踢实业坊(ptt.cc)
◆ From: 114.136.233.146
※ 编辑: TonyQ 来自: 114.136.233.146 (03/29 13:59)
1F:推 atst2:感谢分享^^ 03/29 15:59
2F:→ atst2:另外,补充一下,个人并不认为"新的结构必须舍弃而配合旧有的 03/29 16:01
3F:→ atst2:结构", 我的态度应是您所述"在成本考量下"应采取不同的作法. 03/29 16:01
4F:→ atst2:只是在连续的推文下,以及原来的资讯中,表达的不好, 还请见谅 03/29 16:02
5F:推 leicheong:这里有一点想问一下, 为什麽有getElementsByName()和 03/29 20:15
6F:→ leicheong:getElementById()的情况下还会需要超过需要的多层loop? 03/29 20:16
7F:→ leicheong:会出现这情况的话完全是因为建构不够严谨, 和是不是用 03/29 20:18
8F:→ leicheong:CSS排版无关吧... 03/29 20:19
9F:→ leicheong:话说我现在的公司还在用NT4的domain, table排版这玩意 03/29 20:21
10F:→ leicheong:在可见的20年内应该还会有人用吧... 03/29 20:22
11F:→ leicheong:说到table排版, 有一点是CSS完全没法做到的. 就是在 03/29 20:22
12F:→ leicheong:text mode browser内有条理地显示. 因此一些像web admin 03/29 20:23
13F:→ leicheong:类的网页我完全不建议用CSS排版的... 03/29 20:24
14F:→ leicheong:因为开机速度的关系, 我的Linux伺服器是一向都不装X的. 03/29 20:25
15F:→ TonyQ:就算是这样,有多层table造成dom过多让js有关内容操作起来 03/29 21:41
16F:→ TonyQ:很肥很难操作是不争的事实。(特别是dnd类的操作特别明显 03/29 21:51
17F:→ TonyQ:另外就是在动态增删资料时,需要去塞一些dirty code是很繁琐 03/29 21:52
18F:→ TonyQ:的。至於text mode browser......@_@ 这不是我所了解的 XD 03/29 21:53