 |
业界资讯 |
在线交易 |
在线源码 |
功能函数 |
开发文章 |
问题求解 |
应用专题 |
| 开发语言 | C C++ 汇编 JAVA
.NET VB DELPHI ASP.NET ASP PHP JSP CGI |
数据库 | Access MySql MsSql Oracle SyBase DB2 | 开发工具 | MS.NET JBuild Frontpage |
网站开发者应该学习什么？
一、网站开发要熟悉页面制作的基本知识 。
html语法，css语法，dreamweave 网页编辑软件。
二、需要学习一些图片和FLash制作和处理软件。
photoshop,firework,flash,swish 等等，如果您是做后台开发，只需要会简单使用就可以了，不需要学的很精通。
三、表单提交客户端处理脚本
使用最多的是javascript。
四、后台处理语言
①asp②jsp/java/serverlet③PHP④CGI/PERL⑤asp.net 精通其中一个就可以开发自己的网站了。
五、WEB服务器的架设和管理
比较通用的 IIS，APPACE,还有很多.....
六、数据库
access,sql server,mysql,oracle 。
七、网络安全基本知识
写代码的时候要注意是否存在益出和注入漏洞。如果是自己的服务器，要熟悉怎么防止黑客攻击，防火墙的安装使用，等等
网站开发可分为页面制作和后台开发两种，页面制作的工作只需要掌握第一和第二条就可以了，而后台开发则初了第二条以外都要掌握。
作为一名合格的IT项目开发人员，按时按质按量完成IT项目的一些建议：
转自51CTO
因为时间是当今社会衡量效率的一般标准，所以因这些事由导致的计划推迟、延误都会最终带来相当规模的财产损失（除了名誉受到损害之外）。
有没有解决办法呢？当然有！合理的计划，良好的执行，考虑到可能会出现的困难，这些一定能确保项目成功执行并完成。大部分项目经理清楚这些，并花大量时间制定项目时间表和交付时限表。然而，常常并导致他们出错的是，他们没能认识到项目计划是一个持续性的活动，必须在项目进展周期中积极地、持续地发生，而不是收到客户预支款项后便告一段落。
在本文中，我将提出一些建议，帮助您有效地进行下个项目的计划，并确保在预算前提下以高质量水平按时完成项目。
问题
首先，让我们看看导致项目延误的几个原因：
◆野心过大的估计和不恰当的任务评估：往往，一个项目团队对于完成既定任务不能做出恰当的时间和精力的估算，而制定出过于积极乐观的时间计划。客户带来的压力也会迫使一个团队去尝试在本已有限的时间内完成过多的任务——这是最终会导致最终产品产生质量风险的自我挫败战略。
◆不合理的项目规模：往往，对于一个团队所给定的时限，一些项目过于庞大。管理人员（或客户）有时在未实际分析项目可行性的情况下，便尝试无理地把尽可能多的特性和发展任务压缩在一起。
◆任务分派不明确：有时，任务没有明确分工，团队成员角色不明确导致成员间的产生误解。
◆缺乏风险管理系统：有些团队盲目自信，相信他们可以在最后一秒拯救一个计划，相信所有危险可以放到第二天的会议上得到解决。这是个不切实际的想法。所有项目都不可避免的会有问题存在；任何一个问题都可能摧毁整个计划，使项目不堪重击而失败。如果这些问题不能够被明确查出，并在良好的基础上不能提前解决，那么结果只会往更坏的方向发展。
◆缺乏资源：“这个项目需要五名开发人员，但是我们只有四名。没关系，我们会处理好的。”听起来熟悉吗？如果是，那么就要清楚这样是行不通的——一个需要五名成员的项目，如果少了一位，并不能如期完成。另外一种类似情况是一个项目在开始之时有着合适的成员数量，但在项目过程中，一些成员被“分派”去参加其他的项目（通常这是因为某些高层领导认为他们在资源分配上比项目经理懂得更多）。
◆基础设备不完善或遭破坏：一些项目的延误常常是因为对于一个项目的成功完成必不可少的基础设备——如硬件、软件、工具、文档等——在最需要它们的时候无法得到或不能正常运行。
解决方案（10点建议）
然而，一切并非只剩黯淡和无望。以下的措施将会缓和这些问题并保证项目按照计划运行和如期完成。
◆详细分析要求：仔细理解与项目有关的各个方面，具体到最细小的要点。对于模糊不清的方面要提出问题直至清楚理解。最后，雇佣专业人员归类整理业务要求，操作细节和设计要求。小心需求的渐变；一不小心，它便会摧毁您所做的一切努力。如果有必要，要大胆地缩小项目规模或避免添加计划外的新方案，因为这必定需要更高要求的时间整合。
◆合理配置可利用资源：按照要求配置可利用资源，确保足够的人员来完成工作。在项目运行启动之前确保项目顺利执行的各种基础设施——硬件、软件、人力资源、工具、文本信息等——都已到位。
◆进行培训和知识迁移：如果有培训，培训也该算作是项目时限内的一部分。不要把培训当作员工工作时间以外的任务，而应该把其列入项目计划和预算之内。
◆识别风险：确认潜在风险和准备突发事件预案以备不时之需。制定后备计划以备在突发情况和人力方案失败之时如期完成；这种“B计划”方案是在项目未按计划成功进行情况下的支持性系统。
◆估算与分配：给每位组员分派角色和任务，确保每项任务具有明确的负责人。运用项目管理工具和甘特图表记录每位成员的任务以及每项任务开始和完成的日期。如果在任务责任分派制这一环节上失败会导致责任重叠、精力无谓重复、时间浪费和产品质量低下。
◆工作任务模块化：把每项主要工作任务划分为几项子任务，直至每项工作都是一个完整的个体，与其他工作互相独立。以逻辑顺序整理排列，然后以发生先后为序开始执行最细小的一项工作任务。
◆避免过多会议：策划关于项目状态的讨论会，或在以需要为基础的前提下即刻点明问题所在。冗长的、无休止的、没有明确议程、明确结果的会议只是浪费时间。
◆做好记录：记录项目的成功与失败。这一点很重要；这会成为其他项目中相应工作任务的历史参考信息。使用项目纪录板以图表的形式在更高层次综观项目，更好地衡量项目进程。在每一步重大转折时对项目进行检查鉴定，并依此更新项目纪录板。
◆认识全天候发展模式：如果有一种全天候发展模式（一种在全球范围内持续不断进行的工程作业环境），确保在不同部门团队成员间和跨国团队成员间明确沟通，避免误会。定期做好协调工作以避免不必要问题的出现。
◆逐步上报问题：当问题出现时，要第一时间报告管理层，并尽可能多地制定解决方案。在事态严重到无法补救以前，要尝试各种弥补办法便是您最后需要做的一件事。
必须清楚，按期成功地完成项目关键在于前期计划和合理的时间，资源管理。采纳以上建议，您的项目将会如期完成，并达到目标。祝您好运！
来自百度知道的建议：
如果你是学生，或者如果你有充足的时间。我建议你仔细的掌握下面的知识。我的建议是针对那些希望在IT技术上有所成就的初学者。同时我还列出了一些书目，这些书应该都还可以在书店买到。说实在的，我在读其他人的文章时最大的心愿就是希望作者列出一个书单。
大学英语——不要觉得好笑。我极力推荐这门课程是因为没有专业文档的阅读能力是不可想象的。中文的翻译往往在猴年马月才会出来，而现在的许多出版社干脆就直接把E文印刷上去。学习的方法是强迫自己看原版的教材，开始会看不懂，用多了自然熟练。吃得苦下得狠心绝对是任何行业都需要的品质。
计算机体系结构和汇编语言——关于体系结构的书遍地都是，而且也大同小异，倒是汇编有一本非常好的书。《80x86汇编语言程序设计教程》（清华大学出版社，黑色封面，杨季文著）。你需要着重学习386后保护模式的程序设计。否则你在学习现代操作系统底层的一些东西的时候会觉得是在看天书。
计算机操作系统原理——我们的开发总是在特定的操作系统上进行，如果不是，只有一种可能：你在自己实现一个操作系统。无论如何，操作系统原理是必读的。这就象我们为一个芯片制作外围设备时，芯片基本的工作时序是必需了解的。这一类书也很多，我没有发现哪一本书非常出众。只是觉得在看完了这些书后如果有空就应该看看《Inside
Windows 2000》(微软出版社，我看的是E文版的，中文的书名想必是Windows 2000 技术内幕之类吧)。
数据结构和算法——这门课程能够决定一个人程序设计水平的高低，是一门核心课程。我首选的是清华版的（朱战立，刘天时）。很多人喜欢买C#版的，但我觉得没有必要。C#的语法让算法实现过程变得复杂多了，而且许多老师喜欢用模块这一东西让算法变得更复杂。倒是在学完了C版的书以后再来浏览一下C#的版的书是最好的。
软件工程——这门课程是越到后来就越发现它的重要，虽然刚开始看时就象看马哲一样不知所云。我的建议是看《实用软件工程》（黄色，清华）。不要花太多的时间去记条条框框，看不懂就跳过去。在每次自己完成了一个软件设计任务（不管是练习还是工作）以后再来回顾回顾，每次都会有收获。
Windows 程序设计——《北京大学出版社，Petzold著》我建议任何企图设计Windows
程序的人在学习VC以前仔细的学完它。而且前面的那本《Inside Windows 2000》也最好放到这本书的后面读。
在这本书中，没有C++，没有GUI，没有控件。有的就是如何用原始的C语言来完成Windows
程序设计。在学完了它以后，你才会发现VC其实是很容易学的。千万不要在没有看完这本书以前提前学习VC，你最好碰都不要碰。我知道的许多名校甚至都已经用它作为教材进行授课。可见其重要。
上面的几门课程我认为是必学的重要课程（如果你想做Windows 程序员）。
对于其它的课程有这样简单的选择方法：如果你是计算机系的，请学好你所有的专业基础课。如果不是，请参照计算机系的课程表。如果你发现自己看一本书时无法看下去了，请翻到书的最后，看看它的参考文献，找到它们并学习它们，再回头看这本书。如果一本书的书名中带有“原理”两个字，你一定不要去记忆它其中的细节，你应该以一天至少50页的速度掌握其要领。尽可能多的在计算机上实践一种理论或者算法。
你还可以在CSDN上阅读到许多书评。这些书评能够帮助你决定读什么样的书。
开发者的心声
转自：http://dreamhead.blogbus.com/logs/2004/11/487388.html
这是一个很让人费解的标题，通常来说，程序员都是开发者。没错，对于我们的用户而言，我们是开发者，因此，对他们而言，我们拥有着无尽的魔力，可以创造出另外一个世界，而他们只能在我们圈出的土地上活动。不过，你是否想过这样的问题，在我们为别人指出一条明路的同时，自己也正在别人的鼓掌之中起舞。
作为程序员，我们经常会做一些框架的用户。想必Java程序员们对于servlet并不陌生，很长一段时间内，我一直把它当作一个普通的API，需要的时候能找到有哪些方法足矣。近来在考虑系统结构的设计，实现了一个简单的生命周期框架，其中有一个生命周期事件监听的机制。所谓监听不过是Observer模式的一种实现，也就是发生特定事件之后，调用监听器通知它们发生了些什么。信手翻起手边的《Java与模式》，《Servlet技术中的模式》一章一下子吸引了我。虽然以前也曾经看过这章，但站在用户的角度，我只是想了解有些什么，而从未考虑过这些东西为什么这样设计，当我成为一个开发者，却发现了那是一个别有洞天的世界，Servlet技术中的一些概念一下子涌上心头，细细品味，原来它与心中构想的框架有着许多相通之处：各种Listener（ServletContextListener、ServletContextAttributeListener、HttpSessionListener、HttpSessionAttributeListener）提供的就是我要设计的监听机制，而Filter则与我构想中Interceptor机制异曲同工（JBoss的灵活就是由Interceptor达成的），Servlet在我的设计中对应了最核心的Service。我在思考框架设计的时候，灵活性是一个很重要的因素，与Servlet的印证，让我重新认识了这个熟悉的陌生人。好东西就在身边，只是自己有眼不识泰山罢了。对于框架而言，其设计者是这场游戏中最快乐的人，除了会得到开发过程中的乐趣之外，为别人制订规则的乐趣也是超乎想象的。
框架设计者在得到属于自己的快乐同时，他们还要遵守语言设计者制订的规则。举个简单的例子，我们知道C++语言在C原有的值（value）、指针（pointer）基础之上又增加了一种引用（reference）。C语言已经用事实证明了自己的无所不能，值和指针已经足够完成所有的需求，而引用有不像类（class）、模板（template）之类的概念能够提供另一种抽象，那它的意义何在呢？我的答案是它不过是一种语法上的便利而已。在编译器实现的过程中，引用会以指针的形式表现出来，而在代码中展现出来的时候，它与普通的值丝毫不差。作为函数的客户端，代码编写时不再像以前指针那样需要额外的使用‘&’，这样代码看上去会干净许多，而效率上有不会有丝毫的损失。正是看中了这种代码上的干净，Java干脆去掉了指针，而丰富了引用的概念（可以置空、可以改写等等）。设计者体会到各种乐趣之后，给我们的只是一个设计的结果，不明就里的我们大多数情况下只能糊涂的遵循，而无法分享其中的乐趣。
再来举一个例子，C++中有拷贝构造函数的概念，其实在Java中我们也会有用一个对象构造另一个对象的情况，但Java人却从不提及这个概念，这是为什么呢？原因在于C++中存在的pass
by value。虽然在优秀的编程风格时，我们会尽量使用pass by reference，但pass by
value依然不可避免，比如构造一个有理数类的乘法运算，我们只能以pass by value的方式将函数中构造出来用以存放乘积的临时变量传递到函数外部。pass
by
value就必须存在一个拷贝构造的过程，我们不可能直接将一块内存直接复制到另一边，因为如果类定义中存动态分配内存的部分（也就是指针），代码就会存在问题。关于这个问题，《Effective
C++》有详细的讲解。为什么Java中不存在这个问题呢？因为Java中来回传递的都是引用，不涉及拷贝构造的过程。那C++中就不能像Java一样吗？抱歉，不能。前面说的pass
by
value不可避免的一个重要原因在于你不能把局部变量传出来，因为局部变量的内存会在函数执行完之后销毁，我们会因此体会dangling的现象。如果是动态分配的呢？在函数中new出一个对象传出去可不是一个很好的行为，那样我们至少要在文档中多费一些口舌来说明这块内存由谁释放。Java中为什么没有这样的问题，因为Java的内存是由GC负责。现在我们可以看出，GC决不止是内存管理这么简单，它的影响甚远得很。
开发者和用户所能体会到的乐趣是不同。有许多人会认为软件开发了无生趣，很重要的一个原因在于他们只是规则的遵守者，而制订者对这场游戏则是乐此不疲。现在许多软件开发的书籍可以告诉你“HOW”，却很少说“WHY”。比如许多源码剖析的书，它会告诉你这段代码如何完成了功能，这种书看完之后，我们至多能够照猫画虎描出一个简单的例子，如果让我们自己来做，却往往不知道如何下手。因为我们只看到了结果，而没有其中的过程未能展现出来，而这个过程往往才是精华所在。
似乎制订规则是一件很遥远的事情，其实作为自己软件的开发者，我们又何尝不是规则的制订者。尝试站在规则制订的角度理解一些问题，既可以学习规则制订的法则，也能提升自己对规则的认识，这样我们才能在这场游戏中更加游刃有余。