程序员

个人年度述职报告(程序员)

风格不统一 提交于 2020-02-04 01:30:10
个人年度述职报告(程序员) 要求 内容 (内容做了部分改动,有关公司和个人信息等部分已修改或者删除,原文大概5000字,主要在工作内容上,个人可结合自己的工作做填充) 2019年度述职报告 自从加入某某某以来,至今过了差不多7个月的时间,在这7个月内,不光有工作经验上 的积累、知识的丰富,让我更有感触的是暴露了很多问题与不足,更好的认识了自己, 下面我将从各个方面总结一下本年度的工作情况。 首先说一下作为个人对工作的总结 来到公司前的画像与目标 刚来到公司的时候,处于一种不熟悉公司用的技术架构体系(以前用的学的技术还是比 较老的),不熟悉公司业务,对代码质量的重视程度也不高,对程序性能没要求,表达 能力不行的状态。当时的目标主要主要有:首先熟悉公司业务和技术架构体系,业余时 间学习一些自己不了解的新技术,读一些技术书籍,当时总结了一些java方面的较好的 书单,打算有时间看一下(如《深入理解JAVA虚拟机》、《Java核心技术-卷I 第十版》 等),还有就是当时感觉设计模式很有趣,打算了解、熟悉23种设计模式(并会使用常用 的几种,如工厂模式、代理模式、装饰者模式等),还有其他一些生活上的小目标。 个人作为一名员工的年度工作体验与感想 作为个人在某某某工作的这段时间里,带给了我很多感想,有的只是片刻的感慨,有的 却能结合着日常中听闻形成更深刻的认知。因为公司目前处于创业阶段

操作系统的发展史

断了今生、忘了曾经 提交于 2020-02-03 17:57:51
操作系统的发展史 一、手工操作——穿孔卡片 1946年第一台计算机诞生--20世纪50年代中期,计算机工作还在采用手工操作方式。此时还没有操作系统的概念。 程序员将对应于程序和数据的已穿孔的纸带(或卡片)装入输入机,然后启动输入机把程序和数据输入计算机内存,接着通过控制台开关启动程序针对数据运行;计算完毕,打印机输出计算结果;用户取走结果并卸下纸带(或卡片)后,才让下一个用户上机。 手工操作方式两个特点: 用户独占全机。不会出现因资源已被其他用户占用而等待的现象,但资源的利用率低。 CPU 等待手工操作。CPU的利用不充分。 20世纪50年代后期,出现 人机矛盾 。:手工操作的慢速度和计算机的高速度之间形成了尖锐矛盾,手工操作方式已严重损害了系统资源的利用率(使资源利用率降为百分之几,甚至更低),不能容忍。唯一的解决办法:只有摆脱人的手工操作,实现作业的自动过渡。这样就出现了成 批处理 。 二、批处理——磁带存储 批处理系统:加载在计算机上的一个 系统软件 ,在它的控制下,计算机能够自动地、成批地处理一个或多个用户的作业(这作业包括程序、数据和命令)。 2.1 联机批处理系统 主机与输入机之间增加一个存储设备——磁带,在运行于主机上的监督程序的自动控制下,计算机可自动完成:成批地把输入机上的用户作业读入磁带,依次把磁带上的用户作业读入主机内存并执行并把计算结果向输出机输出

编程经验

随声附和 提交于 2020-02-03 01:13:13
   1. 估算解决问题所需要的时间。 不要怕,承认吧!我曾见过一些程序员为了解决一个特殊问题而坐在显示器前面8小时。为自己定一个时间限制吧,1小时、30分钟或甚至15分钟。如果在这期间你不能解决问题,那就去寻求帮助,或到网上找答案,而不是尝试去做“超级堆码员”。    2. 编程语言是一种语言,只是一种语言。 随着时光推移,只要你理解了一种语言的原理,你会发现各种语言之间的相似之处。你所选择的语言,你应该觉得“舒服”,并且能够写出有效(而且简洁)的代码。最重要的,让语言去适应项目,反之亦然。    3. 不要过于注重程序的“设计模式”。 有时候,写一个简单的算法,要比引入某种模式更容易。在多数情况下,程序代码应是简单易懂,甚至清洁工也能看懂。    4. 经常备份代码。 在我年轻时,我就有过因硬盘故障而丢了大量代码的经历,这经历很恐怖的。只要你一次没有备份,就应当像有着严格的期限,客户明天就需要。此时就该源码/版本控制软件大显身手了。    5. 承认自己并不是最顶尖的程序员-知不足。 我常想,我对编程了解已足够多,但是总有其他人比你优秀。正所谓,“一山总比一山高”。所以,向他们看齐吧!    6. 学习再学习。 正如第5点所说,我经常会在手里拿一本计算机或编程相关的杂志或书(不信,可以问我的朋友)。诚然,总有很多你不知道的技术,你可以从中学习以保持不落后

编程经验

穿精又带淫゛_ 提交于 2020-02-03 01:12:09
所谓高手,就是说他在模仿的过程中不断比较自己写的东西和框架本身的差异,不断发现问题,想尽办法解决问题,思考得越多,你碰到的问题就会越多,这是一个正向循环,最终你的技术能力就会螺旋式的上升;而低手只会被动的等待问题,一旦问题自己觉得解决得差不多就放下了,这样自然就不会产生更多的问题,最终技术能力就始终停留在那个菜鸟阶段 1. 估算解决问题所需要的时间。不要怕,承认吧!我曾见过一些程序员为了解决一个特殊问题而坐在显示器前面8小时。为自己定一个时间限制吧,1小时、30分钟或甚至15分钟。如果在这期间你不能解决问题,那就去寻求帮助,或到网上找答案,而不是尝试去做“超级堆码员”。   2. 编程语言是一种语言,只是一种语言。随着时光推移,只要你理解了一种语言的原理,你会发现各种语言之间的相似之处 。你所选择的语言,你应该觉得“舒服”,并且能够写出有效(而且简洁)的代码。最重要的,让语言去适应项目,反之亦然。   3. 不要过于注重程序的“设计模式”。有时候,写一个简单的算法,要比引入某种模式更容易。在多数情况下,程序代码应是简单易懂,甚至清洁工也能看懂。   4. 经常备份代码。在我年轻时,我就有过因硬盘故障而丢了大量代码的经历,这经历很恐怖的。只要你一次没有备份,就应当像有着严格的期限,客户明天就需要。此时就该源码/版本控制软件大显身手了。   5. 承认自己并不是最顶尖的程序员 -

程序员也可以懂一点期望值管理

余生颓废 提交于 2020-02-02 09:51:02
刚开始做程序员的时候,主要的心思都放在代码上,没有太关注和其他人之间的相处,更没有考虑过期望值和管理期望值的事情。直到我后来开始做技术管理,有一次听老板跟我讲:“管理,最重要的就是管理期望值”,我才开始关注有关期望值的问题,慢慢才发现生活中“期望值”无所不在,只是很多时候没有意识到罢了。 比如上学的时候,某次考试,平时都是考60分左右的学渣考了80分,而平时都考90分的学霸也是考了80分,一般老师就会大大表扬一下学渣,捎带着提醒学霸要注意努力。 工作中,团队中新进来两个水平差不多的程序员A和B,A开始卖力表现,同事们都觉得不错;B默默无闻,同事们都没啥特别印象。一段时间过后,同事和领导对A的期望值会越来越高,最后有几次A满足不了较高的期望,这时候反而会获得一些负面评价;B平时大家对他期望不高,偶尔在项目中有很好表现,反而会得到很好的评价。 微软的Windows XP操作系统,是一代经典,相应的大家对XP之后的操作系统期望很高,后面的Vista一直跳票,最终发布后骂声一片,就在大家已经对微软很失望的时候,相应的期望值也降低了很多,Vista之后的Windows 7,虽然比起Vista没有非常多的提升,但是获得了非常多的好评。 仔细观察,会发现日常生活中这样的例子还有很多。发现问题是容易的,但是如何去解决和善于利用才是关键。 了解期望值 要管理期望值,第一步就是要了解期望值

60 个让程序员崩溃的瞬间,哈哈哈鹅鹅鹅鹅鹅鹅........

喜欢而已 提交于 2020-02-02 00:49:47
阅读本文大概需要 2.3333 分钟。 前方高能,每一个程序员看完,你不笑死个人,你来找我,我自己看了好几遍,反正笑的停不下来,太特么有才了。 (本人看了16、23、46.....笑晕了hhhhhhhhhhhhhhhhh...) 1. 公司实习生找 Bug 2. 在调试时,将断点设置在错误的位置 3. 当我有一个很棒的调试想法时 4. 偶然间看到自己多年前写的代码 5. 当我第一次启动我的单元测试时 6. 数据库的 Delete 语句忘了使用限定词 where... 7. 明明是个小 bug,但就是死活修不好...... 8. 当我尝试调整生产数据库中的一些东西时 9. 好像真的没人发现我产品里的 bug...... 10. 下班前我还有一项任务没有完成 11. 产品还没测试直接投入生产时 12. 调试过多线程的都会懂! 13. 当我以为已捕获了所有可能的异常...的时候 14. 当我试图清理几行所谓的旧代码的时候 15. 当有人让我帮他调试代码时 16. 当程序员第一次向老板演示项目时 17. 结对编程,需要再了解一下吗? 18. 当你看到你几个月没碰过的代码 19. 接到产品经理电话的我睡意全无! 20. 测试的时候一切 ok,真正上线的时候…… 21. 作为一个程序员,拷问灵魂的时刻到了! 22. 当年学 C 语言的过程 23. 当前端程序员想改后台代码时,后台程序员的样子

转:昨天去参加adobe AIR发布会

烈酒焚心 提交于 2020-02-01 08:34:54
昨天去参加adobe AIR发布会 2008-03-05 12:23 12547人阅读 评论 (33) 收藏 举报 adobe air sliverlight wpf 微软 互联网 首先申明:我不是adobe雇佣的枪手,我也从不认识adobe的人。我只是一名被C/S和B/S长期困扰希望寻找一套解决方案的人。 昨天去参加了adobe AIR 发布会 adobe是业界著名的客户端展现工具和展现设计工具 提供商。 展现工具:PDF、FLASH。展现设计工具:photoshop、Dreamwaver、FLASH。 很多人都疑问AIR有什么用。昨天在会场也有同学提出了这个问题。既然有了AJAX 纯的JS的客户端表现组件包,如最近刚获得金牛奖的ZK组件包,那为何要有AIR? 我给大家解释解释。大家都能看到现在的趋势:互联网软件在向客户端融合,客户端在向互联网融合。 互联网企业发源于WEB世界,那么它要延伸互联网,必须要基于现在自己的优势和根。JS技术,这种根植于网络世界的技术就是最理想的选择。使用惯了WEB应用软件的用户,对于本地安装一个软件,本地软件那样的操作习惯就感到很奇怪。 而对于习惯了使用本地软件的用户,现在开始有了互联网跨出局域网的业务需求了,怎么办?一种办法当然是给他们另外开发一套B/S企业管理软件,但他们怎么使用都不顺手。 于是AIR产生。让他们能满足互联网处理

昨天去参加adobe AIR发布会

牧云@^-^@ 提交于 2020-02-01 08:34:22
首先申明:我不是adobe雇佣的枪手,我也从不认识adobe的人。我只是一名被C/S和B/S长期困扰希望寻找一套解决方案的人。 昨天去参加了adobe AIR 发布会 adobe是业界著名的客户端展现工具和展现设计工具 提供商。 展现工具:PDF、FLASH。展现设计工具:photoshop、Dreamwaver、FLASH。 很多人都疑问AIR有什么用。昨天在会场也有同学提出了这个问题。既然有了AJAX 纯的JS的客户端表现组件包,如最近刚获得金牛奖的ZK组件包,那为何要有AIR? 我给大家解释解释。大家都能看到现在的趋势:互联网软件在向客户端融合,客户端在向互联网融合。 互联网企业发源于WEB世界,那么它要延伸互联网,必须要基于现在自己的优势和根。JS技术,这种根植于网络世界的技术就是最理想的选择。使用惯了WEB应用软件的用户,对于本地安装一个软件,本地软件那样的操作习惯就感到很奇怪。 而对于习惯了使用本地软件的用户,现在开始有了互联网跨出局域网的业务需求了,怎么办?一种办法当然是给他们另外开发一套B/S企业管理软件,但他们怎么使用都不顺手。 于是AIR产生。让他们能满足互联网处理,又能像本地软件一样操作。 又有客官问了,听过微软也推出了一种客户端跨互联网处理的技术,叫WPF和WCF。微软是客户端的霸主,而且微软的开发工具也是一流的,adobe既不熟悉开发工具这行当

程序员生存定律--目录

时光毁灭记忆、已成空白 提交于 2020-02-01 01:07:52
程序员生存定律这书的目录在这里: 程序员生存定律--目录 喜欢从头瞄的,可以移步。 ---------------------------------------------------------------------------------------------- 支撑职场的基本规则是交换,交换的两端分别是你可创造的价值与你的职场位置(包含收入)。交换就像任督二脉间的通道一样,越是通畅,人生也就越顺风顺水;堵得越死,人也就越寸步难行。 这点要刻在脑子里,一旦要忘记了,就赶紧打自己两个耳光。忘了这点的人一旦被炒,就会很委屈的发“不要拿公司当家”这类感慨。 那什么是交换? 在一般人眼里,交换就是你有个东西我要,我有个东西你要,大家互通有无这样一个过程。但在学者眼里,事情却要更复杂一点。何新先生在《反主流经济学》中,对交换进行了深度剖析,他说: 社会交换成立之第一前提,就是人类之有欲求与需要,而靠自身不能满足。    因此,事物是否具有使用价值,决定于其能否满足人类之某种欲求与需要。所以,事物之内在属性形成其使用价值。 私有制,占有,占有权利,是社会交换得以发生之第二前提。    人有需求之物,而先为他人已据有者,若欲取之,只有二途:或强取(掠夺、战争、索要),或巧取——后者即交换。 随机之交换,导致对交换品的偶然随机定价,故成交之价格有极大随意性。   而常态之交换