※ 引述《EijiHoba (Feel)》之铭言： : 我不太会形容 : 像是 : 教你设计开发一套系统的书 : 像是人事系统、租片系统、进销存之类的 : 我看完洪维恩 Java 2-JDK 5.0教学手册（第三版） : 还是不知道要如何写出一套小型的系统 : 现在网页开发的书在後面章节都会教你要如何开发一些常见的系统 : 像是会员注册、讨论区等 : 有人有看过这样的JAVA 书吗？ 大略讲一下设计一个系统的几个门槛。 因为有人问系统的开发时间，基本上每个系统的状况都不太一样， 试着就共通得部份抽一点东西出来讨论。 --------------------------------- 一个网站先不论介面什麽的， 光是报表这东西就好了，十个系统就可能有一百种不同的报表， Google analytics 写得这麽密密麻麻，其中很多资讯还算是很精简的。 功能清单是第一个门槛，也就是你到底有多少事情要做多少子系统要写。 基本上这部份算是需求分析， 新手练习时可以挑一个现成的需求清单来 clone， 说穿了，也就是找一个活在线上的网站来仿造，这样比较不用烦恼这块。 但是真正工作上这块会吃掉很多时间，而且决定你做的东西是不是做白工。 --------------------------------- 你现在有了功能清单了，假设是作个 blogger 好了， 你可能会觉得， 会员登入写完，网志写完，回应写完，分类写完，相簿写完， 这几个分开写完，事情就结束了。 错！ 下一个问题是资料彼此之间的逻辑性， 以 blog 而言，会员可以发网志、发留言、回应留言。 所以你会有所谓的 relation ，这种 relation 牵扯相当的广， 这不只是资料库的范畴，还有资料逻辑、程式设计的部份。 举个例子，就拿回应这件事情好了， 会员回应理所当然的给会员 id 。 （真的这麽理所当然吗？ 我也看过把很多会员资料在回应里也写一份的怪系统，请不要这样做。） 今天 user 没登入怎麽办，要使用者登入，就又牵扯到登入流程， 可能会做访客留言，访客留言的会员 id 该怎麽给，该怎麽订游戏规则。 做了访客留言後，今天你後端报表要统计各会员留言数量的时候， 是不是就要针对某个特定 id 或者某个特定规则去作处理。 做系统多得是这种需要通盘考量的东西。 新手跟老手的差别就在於能够预先看出这东西的影响范围， 并且给予这些东西预先适当的处理。 OO/软体工程什麽鬼的，基本上都是用来解决这个问题。 拿重构来说好了，一开始东西重复的程式码可能会散落在各地， 所以做集中化、抽象化的处理，这是一种很常见的重构行为。 於是我们原本修改一个逻辑需要修改十个地方的， 重构完之後只需要修改一个。 在一些一开始就知道比较有可能频繁异动的元素上，就会得到很大的回馈。 软体工程最後学习他的目的都是为了解决实务， 而不只是为了「用一个看起来很标准的作法」。 个人认为要在专案谈软体工程引入之前，那个人必须非常掌握专案的需求， 了解专案中的一些细节逻辑，他才有办法掌握到真正的核心。 如果过於拘泥於某些固定作法，碰到一些特化的程式逻辑时很有可能死很惨。 --------------------------------- 即使是一个最最简单的留言板系统， 也会分成有没有会员系统，有没有验证码， 能不能访客留言， 如果可以，访客能不能编辑文章（给一个code让他们可以输入 code修改）， 发文之後要不要先让管理者做留言审核， 或者能不能让管理者选择其中几篇不需要显示。 而这些不同的功能其中又有不同的状态，这些状态值怎麽去设计， 会随着不同专案不同需求而有不同的考量。 --------------------------------- 即使是资深的专案开发者，如果没有先讲清楚， 突然从只允许会员留言变到可以允许访客留言， 这麽看似简单的需求异动，都有可能因此造成一堆问题。 因为一开始的需求是只允许会员留言，所以一定有做权限控管， 能不能找到对应的权限区块，并且正确设定允许访客， 而且没有设定到不该设定的地方，这都是可能很繁琐的事情。 当然有的资深设计者可能一开始就会设计角色权限， 但是也有其他资深设计者会觉得简单的留言板功能干麽做这麽复杂而没做。 这没有对错，纯粹是一开始对目标设定的差异。 --------------------------------- 那你可能会问，既然这样，如果给定固定需求，那总是能写出一本书来吧， 事实上即使是同样的需求也可能有十种作法，而且没有对错， 写这种书被 challenge 的空间太大了。XD 而且要考虑到每个细节来讲，以ERP或进销存而言， 这本书大概少说三千页起跳，不写细节就又失去写书的目的。 就跟上面某人说得一样，简单带过，重点打马赛克。XD 重点是，看完这本书， 如果你还是只会写他所教你的系统，那一点意义也没有。 现实世界需要得是实作的方针与能自主设计的思考模式， 资深的人能带给新手的，一个有状态的留言板实作已经很够了。 前面有人说後端用 ORM ，用 hibernate 就够了，只要专心刻 UI， 那是已经把资料逻辑的那段成本当成理所当然的前提了。 即使用 ORM 、 hibernate ， 一样要注意资料安全 （ex. SQL Injection）， 组 HQL 如果还是很白目的把字串扔进去组 Query ， 而不是透过 setParameter 操作，一样也是照死。 一样要处理各种资料的状态、逻辑设定。 一样要处理权限控管，资料检查等细节。 这些东西这样看起来好像很吓人，其实也未必， 就是每个环节每个环节要一步一步去检视，更重要得是经验与耐心。 新手写得系统是不堪一击的，但这没有关系，被打爆了就会知道哪里有问题。 每个人都是这样走过来的。 最重要的事情是，系统设计是没有标准答案的， 领域太广，东西太多，状态太多，导致每个人都是见招拆招。 所以这条路上你也不会有太多机会碰到什麽老师。 -- 网页上拉近距离的帮手 实现 GMail丰富应用的功臣 数也数不清的友善使用者体验 这就是ｊａｖａｓｃｒｉｐｔ 欢迎同好到 AJAX 板一同讨论。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 1.34.116.11 ※ 编辑: TonyQ 来自: 1.34.116.11 (07/16 03:54) ※ 编辑: TonyQ 来自: 1.34.116.11 (07/16 03:54)