前面说了整个软件开发中,目前所处的位置---初级程序员,比起那些上学期间就做了一大堆项目的人来说,我实在惭愧的要命,着实"笨笨地",多么想回,头再来~
想起白胡子了,贼哈哈哈```不可能了>.有点慌了--淡静,淡静,要淡静....
需求分析,数据库设计,架构搭建,静态页面,甚至最终的集成测试--都有专人操作,自己的任务呢????---
比如:1:一个c#的cs结构的项目,大致处理流程为:画面--传递参数parameters类(各个可能用到的值的封装体)--到facade(webserver类完成逻辑处理),调用dao(底层数据的处理,供facade使用);;人员安排:项目经理解决业务疑惑,技术总监负责架构搭建及技术困难,一个小组负责facade的编写(项目时间太紧,原计划dao单独一组负责,没能实现),一个小组完成画面的绘制;;;;自己和几个实习生为最后一组,任务就是照着参考画面拖控件,(参考画面可能是静态的一张图,或者就是用word画的一些框框,或者是一些现有软件的截图),页面的名字都已经定义好了,各个参数,控件命名规则要参照规约,基本上就是来回拖动控件定义名字,进行参数验证,格式转换...最后调用facade(webserver)完成数据处理.
2:一个java的项目cs的,大致流程:采用了spring+struct(说是项目小,就没用hibernate),jsp页面 调用action,再调用server接口,再调用dao接口,用到bean类(数据库表对应的bean);;;;人员安排,一个负责项目,一个搭建架构,一个设计数据库,一组编写代码(因逻辑简单,就按模块分的任务);;;自己任务:看看模块用到哪些表,熟悉表中各字段,把表映射为bean类,编写接口完成对数据库表所需的基本操作(增删改查),完成接口的实现,写service接口,实现接口(就是个dao管理类),再写个action调用service,再在页面显示,还有配置文件,基本上都是照着其他的改下名称即可;;;;
3,一个.net的bs的门户网站上的一小项目,现成的后台(不知道N年前写的另一个项目的后台,没有源代码,不过可以使用),基本流程:超简单,就是查询类似类似新闻的项,然后显示<恨死这个烂项目了,拖了这么久还没完没了的>..人员一个美工,4个程序员负责数据读取与显示.,..没有互动性操作,只是静态显示,全是repeater(我真服了--)且所有页面全是查询的一个表,使用的是一个dao操作类,,,,(我真服了-若不是美工把页面做的还像回事,真难想象它是一个让客户出钱的网站系统,什么技术都没用,新建个dao基类,再针对表写个类调用基类完成对数据库操作,其他的都是页面,超链接-----)
======
说了一堆,忘了想说啥了,,喔,架构,说下架构:<假设需求已经很明确了>::综合一些经历,似乎整个项目中技术上最有含金量的就是:架构的搭建了.<架构丫,架构( ⊙ o ⊙ )！>
前面提到了软件就是完成预定任务的东西..编写软件的语言由低级到高级,不断提高(不断插入中间层的过程[特殊除外])---当然还没到理想状态(直接用语言描述下需求,由代码生成器啪一下一个新软件诞生了...[超低需求除外])---在现有状态下,还得一点点处理,,,且需求不断复杂,以至于一个人无法完成了,那就得合作了,合作就需要沟通了,就需要分工了,分工后怎么能够完美的结合,那就得建立专门的配置程序了.如何分工那就的参照一定的标准了.....哎!!标准确实挺难的呵(最好易理解,最好易复制便于通用,最好能服众,最好大家都采用,最好都一样)...慢慢标准出来了....mvc(挺流行的)....感觉就是个分层,插入层的过程,:::::====原本都在一个文件下,为了分工,把呈现给用户的页面与后台处理分开=====后台处理时,分工,业务逻辑处理与数据库操作(业务无关的)处理再分开====这样就出现了较明显的分工标准,及职责划分,也便于维护,重用,及测试..各层只需考虑本层对下层接口的调用,对上层提供所需接口即可,内部实现可自行定义....搭建过程就是定义各个文件夹以及配置文件的过程,以至于不需要考虑各层如何关联,只考虑自身即可.....如:java的ssh.架构搭建好以后应该有这样的状况,(理想状况)--各个类都在sping内注册,页面只需要调用注册的action,而action呢能够完美地调用service得到想要的结果,,service内部做数据处理并调用dao完成对数据库操作...各人只需在自己负责的模块下建立文件夹以及对应类即可.<>
做web类,项目..避免不了,总得有页面,页面总不能太单一,那就得美工了(什么css,js,html相关)
再然后就是代码编写了以及各个技术上的细节了
再者需要测试了
----- 哎,班门弄斧了,黔驴技穷了----似乎需要很多篇幅来说每一项
