精华内容
参与话题
问答
  • 软件开发项目管理经验总结

    万次阅读 多人点赞 2019-04-16 17:26:46
    这是我从事软件外包工作以来的项目管理经验的总结,编写文章的目的是为了回顾和总结自己的一些想法,如果其中有不足的地方大家可以一起讨论交流。 项目经理的职责 关于项目经理的工作职责有很多种说法,我自己是...

              这是我从事软件外包工作以来的项目管理经验的总结,编写文章的目的是为了回顾和总结自己的一些想法,如果其中有不足的地方大家可以一起讨论交流。

    项目经理的职责

         关于项目经理的工作职责有很多种说法,我自己是这样理解的作为一名项目经理第一目标就是

    合理利用公司资源组织设计、开发、测试等各种资源完成项目的高质量交付,并保证项目的盈利。

    这是衡量一个项目失败或者成功的唯一指标,当然有些项目是有战略意义的一开始就没打算盈利这样的项目就不能单纯的用成本来计算了。

       这里有几个小点我想说明一下,1、合理利用公司资源,无论公司大小资源总是有限的,公司不可能把所有的好的资源优质的资源都放到自己的项目组中,总是高高低低的人凑在一起,作为项目经理要能在资源和事情的总量,难度之间找到一个匹配的值。项目拿到手上,我们最少几个人能把这个事情做好要判断清楚。人多了浪费了成本,人少了事情做不完。

    2、利用各种资源,有些资源是需要自己去争取的,当我们发现项目出了问题,但是公司给的资源又不足的时候,项目经理就要想方设法的去获取这些资源,而不是坐等公司来给我们解决问题,很多人都看过一个电视叫《亮剑》主角是李云龙,他就是一个很会自己找资源的人,当时的中央是给不了他们什么装备的,但是鬼子又要打怎么办?自己去鬼子哪里抢,去总部死皮赖脸要。正是因为他这样想尽办法为自己找资源,最后他那个团是富得流油的,打仗更是所向披靡。我们带项目也是这样,资源不够的时候要自己去找,只要你为了项目好总会从公司甚至是客户那里拉到支持。

    3、高质量,盈利。一个项目盈利是一个方面,但是质量确实一个更长远的方面,项目过于赶工,降低要求最后伤害了客户也伤害自己,所以项目的质量和盈利必须要兼顾,要找到一个客户能够接受的质量区间,但是不建议过于苛求,因为没有bug的软件是不存在的。

       虽然站在公司的角度项目是否盈利是重要的指标,但是在我看来项目经理也有其他的一些重要的责任,作为项目经理上要对得起公司下要对得起跟着自己做事情的兄弟,所以 “让跟着自己做事情的人得到成长和锻炼” 也是项目经理的责任。也只有让和自己做事情的兄弟们觉得有收获别人才会愿意跟着你干,团队才会有执行力。当然如何让自己的团队觉得有收获也是有很多技巧的。比如给与团队成员技术指导,合理的安培开发计划在每一个迭代完成后给大家总结,及时给与激励等。后面我们的具体工作方法中都有体现。

      

     

    项目经理应该具备的基本技能

    具有2~3个以上的项目经验

    熟悉JavaEE技术体系

    熟悉敏捷开发流程

    具有与客户沟通需求的能力

    逻辑思维清晰能够理解复杂的业务需求并

    具有管理团队的能力或者潜力

    具有设计较复杂系统的能力

    具有成本意识,交付意识理解外包项目的盈利模式

    具有较强的抗压能力

    具有责任心能够担当在所有人后退的时候要能迎难而上

    学会利用各种有利资源帮助自己完成项目

    开发团队组建

    1. 开发团队不能全部是新人,新人对公司框架以及开发模式不熟悉组织效率较低
    2. 开发团队必须有一人可以全身心投入在项目中,而且这个人知道整个项目的需求,这个人可以是项目经理也可以是项目的主要程序员
    3. 团队要及时沟通,如果发现团队中的成员不爱沟通项目经理要在早会中提出来,告知沟通的重要性,并且通过组织团建,或者茶话会给大家交流的时间,吐槽多了自然也会爱沟通一些
    4. 项目经理不但要管理团队的开发,而且要管理团队成员的心态,要保持团队成员每一个人都是积极主动的,不合适的人及时淘汰,留在团队中只会写bug给团队带来技术债务拖慢整个团队进度。木桶效应,效率最低的人会影响团队的进度。
    5. 团队的执行力一定要强,项目经理一定要反反复复的督促开发测试不厌其烦的跟进他们的进度,任何拖延的人都是对项目极大的威胁,如果项目经理视而不见,对细节问题置之不理,其最后的结果就是做了一个豆腐渣工程,这样的案例我们已经经历了太多,务必重视
    6. 特别留意团队中开发习惯不好的人
      比如有的人喜欢写死id或者用户方便自己调试,但是写完代码只有又不删除,导致后期排查问题时间拖长,看似小问题实际是工作方式不对。遇到这种情况项目经理坚决对其进行罚款。把坏习惯扼杀在摇篮中。
    7. 如果团队中存在人员缺口或者人员不合适的及时和主管反馈进行调整

    项目需求管理

    1. 和客户组建需求讨论群,拉上测试、主程、商务、老板以及相关的人员
    2. 讨论需求一定要带上测试,确保测试对需求和项目经理是一样清楚的
    3. 不明确的或者模糊的需求讨论完后如果对方是企业客户一定要发邮件和对方确,如是个人客户就需要用微信和对方确认确认的聊天记录截图发在钉钉群里留存。
      微信确认话术模板:
         xx总,您好,经过今天的需求讨论我们确认xx功能的需求,功能是这样的 xxxxxx 您看是对的吗?
      邮件确认话术模板:
         尊敬的XX您好,
            经过今天的需求讨论我们确认xx功能的需求,功能是这样的 xxxxxx ,如果没有疑问我们就按照这样设计开发了?如果有补充请在2个工作日内回复我们谢谢。
      祝好!
             XX公司   项目经理:XXX
                                                     2019-01-06
       
    4. 如果客户提出新的需求,首先要判断这个需求是否是报价单中涵盖的,情况一、如果是报价单中需求的补充则接受,并补充到需求文档中。
      情况二、如果不是需求文档中涵盖的,就要区分这个需求如果不做会不会影响客户的主流程,如果会就要看付出的代价有多大,原则上累计需求变动在3个工作日(包括测试代价)我们是可以答应客户的。但是也要告知客户我们是要付出很多成本才能完成你这个新增的需求。如果不做也不会影响客户系统的流程,那么就要尽量的推掉。
      如果既是影响主流程又是超过3天工作日的就要联系商务和客户进行报价洽谈,并告知客户因为做了这个功能会导致项目后延,看对方能不能接受。原则上项目的改动最好能推到验收付款后去完善。
    5. 如果需求出现大的变化,项目经理无法把控的一定要上报,但是也别一点点事情就上报,能自己处理的自己处理。上级往往对具体需求也不是很清楚
    6. 项目要求按照项目需求标准模板编写,如果项目比较简单那么就在原型上标注说明,但是也要有主流程的说明文档,以及分支流程的说明文档,而且原型标注要足够详细
    7. 安排UI进行设计,UI图要上传到Mockplus中并添加跳转点击,psd图传到蓝湖,方便前端人员查看尺寸
    8. 在需求梳理阶段要注意一个问题,对方是否具有成熟的需求思考,以及思路,如果有成熟的需求那我们只要理解就好,如果对方需求比较模糊那么就要求我们来做引导,既要让需求满足客户的使用场景又要保证我们能够在规定的时间开发出来,而且设计一定要合理。产品经理对业务设计不合理会导致需求变动多。
    9. 不要漏掉任何需求不明确的地方,因为需求不明确会导致后期的需求膨胀,而且会导致程序员不知道怎么开发,转而按照自己的思路胡乱猜测,从而写出很多bug。

    项目资料管理

    共享目录

    项目启动时在共享文件中创建项目目录,并告知相关的开发人员,共享目录中包含项目的所有文档,包括需求说明书、原型设计、UI设计、测试用例、等等。所有需要用到的资料都应该放在共享目录中

     

    敏捷开发流程管理

     

    1. 制定开发计划,研发计划每周一,周三更新一次,更新后发在群里通知所有人,公司会从项目经理的开发计划是否及时更新以及计划是否落实到位来考核项目经理的工作
    2. 项目启动会议   组织商务,测试,开发以及一位技术主管到场进行项目需求评审。 项目启动会议需要编写项目启动会议文档,文档在标准文件中有模板。
    3. 需求讲解  (准备好项目原型+重要流程的流程图说明或者需求说明书)项目启动会议开完后休息5~10分钟,休息之后开始进行需求的讲解,需求如果比较多一定要分次讲解。因为一次讲的太多也不容易消化。可以选一迭代的功能进行讲解,第二迭代的功能在第一迭代快结束的前2到3天进行讲解。但是要注意如果第一迭代的功能如果影响第二迭代,在做表设计的时候要考虑到。
    4. 任务拆分  拆分任务录入极客平台,可以多个人一起拆分。项目经理判断任务拆分的是否合理
    5. 故事点数  前端后端的故事点数标准不一样,所以前后端的点数要分开计算,计算奖金的时候比例也要分开计算。
    6. 分配任务,分配任务记录在极客平台的任务管理中,并配置好故事点数,故事点数将会是后期计算项目奖金的重要指标故事点数越多奖金越多。分配任务时一定要确保开发人员明确知道任务的要求和交付标准bug的产生90%来自开发对任务的要求不明确,所以在分配任务时可以在和开发讲解一遍需求,不要嫌烦,这比起到后期熬夜加班改bug来说舒服太多了。
    7. 数据库设计 数据库的设计可以由项目经理统一设计,统一使用代码生成器生成代码。数据库设计一定要过评审,项目经理设计的数据库由主管或者java负责人评审,程序员设计的数据库由项目经理评审,评审过后才能生成代码和数据库脚本。
      注意:我们只所以在代码生成器中生成建表语句是因为我们不想把建表权限给到开发人员,而是由开发人员提供数据库sql项目经理审核SQL后项目经理执行或者项目经理发给指定的人去执行,审核的时候要注意
      建表语句中是否有注释,
      字段长度是否符合要求
      字段命名是否符合数据库规范
      是否满足业务需求
      我们在审核数据库sql的时候也是了解开发对于需求的掌握长度,如果发现开发的sql不对那就可以反推出开发可能并不理解这个需求,这时项目经理应该重新给开发讲解一下需求,然后让开发修改sql,这样就保证了开发对需求的理解也保证了数据库的正确性。开发如果要建表或者修改字段就必须提供对应的sql给项目经理。这也锻炼了开发的sql熟练程度。
    8. sql管理  生成的sql放在项目中统一保存,项目中有一个db文件夹是用来存放sql的,建表语句放在init文件中,文件名中的01,02,03代表执行sql的顺序,增量sql放在increment中,比如初始化的数据字典值的insert语句,配置信息等都通过sql插入数据库,且sql保存在项目中,这样在部署新环境的时候就可以直接执行项目中的sql就可以初始化数据库了。而不需要同步开发与测试库,导致开发的脏数据进入新的环境
    9. 设计文档 对于复杂的功能要求开发编写设计文档,设计文档的模板在公司标准化文件中,开发编写完设计文档后,项目经理需要进行评审,评审通过开发才开始编程。
    10. 讲解设计方案  设计文档不是必须的但是每一个功能项目经理都要过设计方案,或者直接提供设计思路给开发,避免到后期出现对系统不可控的局面,项目经理对实现方案不清楚对项目质量就没有信心。编程之前要做到以下三点
      需求明确
          有bug的地方往往是需求不明朗或者需求复杂的地方面对这样的需求sm一定要引起重视确保自己和组员能够正确理解需求后才开始编程
      方案合理
          程序的设计方案一定要和sm一起讨论,确定一个合理的方案,而不是任由组员自己设计
      理解一致
         对于上面2个方面,上面要确保和组员的理解达成一致避免发生乌龙事件
    11. 移交测试

    开发自测后,提交代码到测试环境,测试环境发版后,通知测试测试,通知的格式如下,开发可以在表格中填好信息,截图发给测试,如果项目组使用了看板贴了纸质卡片,也可以用纸质卡片移交

    测试拿到开发的移交申请后自己安排测试时间,在24小时内定要反馈测试结果

    开发移交故事卡片有几个好处
    1、测试清楚知道哪些功能是可以测试的,
    2、如果要移交故事卡片去测试,则要求我们在拆分故事的时候一个故事是可以独立测试的,而敏捷开发的要求也是故事独立可测

    如果开发的是接口功能那么测卡片由前端开发人员提交。接口开发完成后要录入到极客平台的接口系统中。接口录入时,一定要分模块,禁止所有接口录在一个模块中。后台接口录入完成后要及时通知做前端的同事,尽快联调,只有联调完成,功能才算是完。

    1. 单元测试   在系统没完成之前,测试不是不能介入,而是只能做单个的单元测试,或者几个小单元的集成测试。这是非常有必要的,因为很多不成熟的开发对自己的代码都过于有“信心”导致很多细节问题没注意即使是一个功能也能写出很多问题。单元测试可以帮助避免这些问题,从而降低集成测试的难度。
    2. 集成测试  一个迭代一般是一个完成的流程或者功能,所以在一个迭代结束后测试应该进行本迭代的集成测试工作,每个迭代都应该出一个测试报告 测试报告标准待测试给出
    3. 项目经理测试  在项目的进行过程中项目经理要竟可能多的参与测试工作,不要沉迷于编码,项目经理沉迷于编码对项目的质量风险是非常高的。项目经理是最了解需求的人,而下面的程序员对需求理解总会存在一定长度与的偏差,所以一定要通过项目经理的测试来纠正错误的需求理解。
    4. 客户迭代功能演示  一个迭代结束后务必找客户进行实际的测试一下,不要求能验收功能,但是一定要给客户演示一下,这可以避免需求出现很大的偏差,如果客户提出意见及时改正。
    5. 评审会  评审会是在每一个迭代结束后组织的一个茶话会,项目经理购买一点零食、瓜子,项目组成员座在一起对本次迭代进行回顾和总结,每个成员要总结以下几个问题

    这个项目遇到的最大困难

    怎么解决的

    学到了什么

    对后期的工作又那些启发

    项目经理要做好会议笔记,在会后把有用的总结整理后发在群里,并对下个迭代提出要求。这些问题在开评审会的前一天要发给项目组成员让他们准备一下。

    1. 项目进度汇报    每周五进行一次项目进度汇报发送给主管

     

    开发环境搭建

    1. 在git上创建一个空仓库,把开发组的组员加入到git中,在极客平台创建项目把成员拉入到项目中并分配好职务
    2. 在框架版本库中拉取最新的版本,把代码上传到新建的空仓库,注意删除框架版本中的git信息
    3. 创建2个数据库一个开发一个测试,创建4个数据库账号,其中2个只有增删改查权限,另外两个具有修改数据库表结构的权限
    1. -- 创建数据库
    2. CREATE DATABASE db_databaseName DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
    3. -- 授予数据库所有权限
    4. GRANT ALL PRIVILEGES ON db_databaseName.* TO 'db_dev_user_data'@'%' IDENTIFIED BY 'db_dev_user_data' WITH GRANT OPTION;
    5. -- 创建开发者数据库权限
    6. grant usage on db_databaseName.* to 'db_dev_user_scop'@'%' IDENTIFIED BY 'db_dev_user_scop';
    7. -- 赋予增删改查权限
    8. GRANT EXECUTE,select,update,delete,insert on db_databaseName.* to 'db_dev_user_scop';
    9.  

     

    1. 分开测试环境与开发环境 一般5万以上的项目要求分开测试环境与开发环境,如果因为域名或者其他配置文件导致只能配置到同一个域名下,那么也要尽量分开测试数据库和开发数据库,只有在外部环境实在不能分开测试与开发时才把测试环境和开发环境放在一起。
    2. 在测试服务器上部署一个开发应用,和一个测试应用,并配置好jenkins
    3. 把配置好的域名信息,jenkins信息,tomcat配置信息,日志配置信息,文件上传配置信息发在钉钉群里
    4. 修改登录界面的欢迎语,以及登录成功后的欢迎语,改成客户系统名称
    1. 分开测试环境与开发环境 一般5万以上的项目要求分开测试环境与开发环境,如果因为域名或者其他配置文件导致只能配置到同一个域名下,那么也要尽量分开测试数据库和开发数据库,只有在外部环境实在不能分开测试与开发时才把测试环境和开发环境放在一起。
    2. 在测试服务器上部署一个开发应用,和一个测试应用,并配置好jenkins
    3. 把配置好的域名信息,jenkins信息,tomcat配置信息,日志配置信息,文件上传配置信息发在钉钉群里
    4. 修改登录界面的欢迎语,以及登录成功后的欢迎语,改成客户系统名称

    代码编写要求

    1. 遵循前后台代码规范
    2. 项目中不允许出现多余的代码,代码生成器生成的代码如果没有用到要及时清除
    3. 接口单一原则,一个接口一个方法坚决只允许完成一件事情,如果是同一类任务,需要通过if判断来处理不同的逻辑,那么if判断中的代码一定要抽取出方法而不能全部挤在一个方法中
    4. 禁止硬编码,所有的配置一定要写到配置文件中
    5. 禁止编写复杂sql,除非不得已为之,在实现功能和可读性之间我们更偏向于可读性
    6. 接口传值最小化,前端传值给后台应该尽量少传,后台能自己处理的就自己处理,把业务逻辑尽可能的留在后台
    7. 禁止使用map传参写接口,必须使用统一的AjaxResult类作为参数传递的格式
    8. 接口的录入公共参数不需要录入比如createBy,createTime limint 这些参数不需要录入。
    9. 接口录入要进行分类,不能全部录在一个分类下
    10. 如果处于测试需要要写死用户信息,那么一定要通过拦截器去写,不能再代码中硬编码
    11. 对于暂时无法实现的业务逻辑一定要在代码中加待办的标注 //TODO ,在发版本之前先检查一下所有的TODO标记
    12. 自己开发的功能一定要自己进行测试,测试的时候要尽量使用符合业务要求的数据进行测试,通过后在用非常规的字符进行测试,自己测试完了在移交到测试那边测
    13. 每天下班前要提交当天完成的代码,代码提交的备注尽量写清楚本次提交的目的
    14. 编写查询功能一定要考虑数据库表的记录条数,如果数据量上百万的表要尽量分历史表与作业表
    15. 金额计算要使用专门的类BigDecimal
    16. 及时解决程序员的环境、配置等问题,让其安心开发
    17. bug要及时督促修复不要留到后期集中修复,那样会导致后期要交版本的时候非常紧张

    BUG修复

    1. 测试要把发现的bug提到极客平台上并选择对应的开发人,和功能
    2. 开发收到bug提示后要及时响应解决完bug后,在极客平台把bug设置为解决状态,并选择方案为修复代码

              


    3、测试收到开发解决的bug后进行bug的回归,如果确实解决了则关闭bug

     

     

    每日站会

    开站立会之前一定要和团队约定好站立会的规则,下面给出一个标准的模板

     

    站会的团队规则

    1. 晨会:9:15-9:30
    2. 晚会:17:45
    3. 迟到:发红包5块
    4. 一级BUG:发红包5块
    5. 发包失败:发红包5块
    6. 代码质量差:发红包5块
    7. 开发延期:每延期一天发红包5块

     

    每日晨会讲三个问题:

    1. 昨天做了什么,是否完成
    2. 今天打算做什么
    3. 提出团队或者自己的问题如:
    • 阻碍工作的问题
    • 需要协助的问题
    • 可以改进的问题
    • 代码或者功能有变动需要通知其他人知晓的问题

    晨会的目的是同步信息,发现阻碍项

    项目经理要总结工作情况,鼓励与批评对应的人。

     

     

    每日故事点数

    一个开发每天要完成多少故事点数这个是个问题,

    每日的故事点数=本迭代总点数/( 开发人数 * 迭代天数 )

    确定好故事点数后,每天必须完成既定的故事点数开发,如果产生延期则在看板上标记延期多少点,累计延期3天的点数就开始发红包没延期一天发5块钱

    项目加班审批

    项目加班项目经理可以直接批准,也可以拒绝,加班费用计入项目的总费用,加班费越多项目奖金越少。所以如果非项目本身的要求加班而是开发个人能力问题要加班项目经理可以不批加班申请。

     

    系统测试

    测试用例

    测试拿到需求后要梳理清楚系统中存在多少个流程,每个流程有几个分支流程。每个主流程设计一个测试用例,主流程下的分支流程每个分支流程一个用例。

    测试用例必须找项目经理评审

     

    单元测试

    在系统初期功能比较独立,没有关联,测试在本阶段应该注重功能是否正常,数据是否能够正常的被保存,查询,数据校验是否正确,界面是否布局合理。在后期功能越来越多时进行多个单元的集成测试,集成测试开发是不会再发测试申请的所以要自己安排

     

    测试职责

    1. 全面了解项目的需求,项目经理在和客户讨论需求时测试要在现场。
    2. 测试要审核需求文档,在需求文档中找出逻辑不合理的地方并协助项目经理修改。
    3. 一定要在客户群里,客户反馈的问题测试和项目经理都可以回答
    4. 客户提出的bug客户要负责跟进,督促开发解决,并在客户要求的下一个版本之前回归所有客户提出的bug
    5. 了解开发计划,指定测试计划,确保在交付之前能够完成测试,对开发提出要求何时一定要交付测试,开发是懒惰的测试如果不提出要求,开发一定会在最后一天才把功能开发完成。如果测试不提要求导致没有时间测试责任由测试负责
    6. 所有bug录入极客平台,不厌其烦的督促开发修改bug
    7. 体验不好的界面坚决拒绝,不管开发愿不愿意都要改,对开发的宽容就是对客户的伤害,对客户的伤害就是对公司整体员工的伤害。
    8. 每日填写测试日报,日报发送给项目经理,舒适,姜友瑶

     

    报价注意事项

    1、我们的报价报的应该尽量是公司内部成本价保证能开发完就可以,不要刻意加价加工时。利润的事情商务去考虑

    2、报价要按照一般程序员的开发速度考虑,不能考虑我们本身自己的开发速度,因为项目大部分是基层程序员开发

    3、项目的报价需要考虑需求沟通成本,复杂的业务,在需求沟通,系统设计,UI设计方面都比较耗时这是功能之外的

    4、考虑测试成本

    5、如果需求比较简略,那么要从功能的完整程度去考虑需求上是否有遗漏的功能然后和商务讨论是否要加上

    6、报价前当面找销售去沟通,让销售进行业务背景的讲解,直接看文档没有业务背景会比较懵逼报价不准。

     

     

    展开全文
  • java开发三年,总结一些经历与经验

    万次阅读 多人点赞 2017-01-09 15:06:15
    很多人都说开发三年是程序员第一个门槛,学到了基本的开发技术,熟悉了一些常用的软件。接下来怎么选择,方向很多,是专心做技术,还是做管理,或者是测试、运维、前端,更或者说换一行,回家卖卖红薯。 首先 要...

            不知不觉,毕业三年。

            很多人都说开发三年是程序员第一个门槛,学到了基本的开发技术,熟悉了一些常用的软件。接下来怎么选择,方向很多,是专心做技术,还是做管理,或者是测试、运维、前端,更或者说换一行,回家卖卖红薯。


            首先

            要总结下这三年的经历与学到的东西。

            14年毕业,进入公司后至今未换过工作,大概也算是很少见的了,公司是外包,工资低学不到技术,和我一批入职的100号人基本一个不剩了。我算是运气比较好的吧,被卖到北京,有出差补助,基本是活的了了。刚刚到北京的时候,真是啥都不会的感觉。大学混了四年,学习不好不坏,大概大部分人都一样,实际做程序和基本知识还是有一定的差距。


            第一个项目,做的是涉密的项目,做开发没有互联网,不知道多少人顶不住。自己不会,上网查又太麻烦,那就只能抄了,毕竟刚刚毕业都是些基础的增删改查,上传下载的技术,有例子就能学习,进过悲惨的两个月加班,终于是慢慢稳定了基本的开发工作。项目是接手的,不大不小,开发的时候有5、6个人,后期剩下我和经理还有个小伙伴。印象中,框架应该是SpringMVC+MyBatis,服务器是tomcat6,国家支持国产化的项目,用的是浪潮的服务器,麒麟的系统,达梦的数据库,用的过程中还是有好多的问题,国产还是得提高。刚刚上手的时候,我是第一个人,没人教,悲剧到找不到sql在哪写,真是黑暗啊。然后悲催的做了下数据的上传下载,完全没做过啊。像这样的问题,现在一百度就好了,但刚刚毕业没人带,自己在涉密环境傻兮兮的看,真是暗无天日,当时都准备回家种红薯了。但问题总会解决,经过努力还是熟悉了框架的使用。军队的项目一个表100多个字段,新增做的时候很是蛋疼。然后做过数据传输,和大连东软的做了下集成,新启动一个传输服务器,上下级的IP、mac、名称等属性,转换成一个文本文件,做数据流发送。这样又涉及到发送时以1M的包为大小,包前加头,包后加尾,收到后再处理合包。然后又涉及到了文件的校验,MD5的方法百度。那么接下来呢,数据加密,分为文件的加密和传输的加密。文件加密则是文件上传下载的过程中,对文件像传输一样分包,然后做位移,下载的时候一样做反位移,这样在服务器上落地的文件是无法直接打开的,文件是加密文件。传输加密则是在网络链路上,数据流是加密处理过的,这样,即使有人截包,依然无法得到传输的内容。唉,我想象中的开发的活也就这了,然后。。。自己测试,自己去现场,自己安装环境,自己和客户对接讨论,自己回来修改bug,再去发布新版本,制作安装手册,制作用户手册。貌似整个项目的活基本都做过了。做了的东西不少,学到的东西不少,过了两年现在就只剩下印象了。

            总结:这个项目学到了很多的东西,熟悉了一整个项目的开发、测试的流程。对相关的很多软件有了熟练的操作,包括数据库、服务器、系统、相关网络的搭建。不足的地方是,大部分开发都是在copy别人的代码,知其然不知其所以然,离开了项目自己就基本不会写代码了。


            第二个项目,是政府的项目,用的应该是SSH的,很正常的管理系统,包括正常的OA以及一系列的系统。在基础开发的技术难题不多,大都增删改查。难度在与UKey的集成,统一认证的集成,门户网站的建立,以及一些相关的插件集成。时间有一年左右,包括各种子项目的开发,以及后期常驻现场,用户测试、需求变更、系统维护、bug修改等。

            总结:第二个项目的开发,比第一个好了很多,会自己去实现功能,查询方法,使用api。不足的地方在于,对于一些技术实现,常遇问题没有很条理的整理记录,有些问题会多次查训,没有记住也没有记录。而且,对于框架的使用,仅仅是使用,对整个框架结构的把握及理解不是很透彻。


            第三个项目,是深圳市政府的项目,项目比较大,目标是全市机关单位的无纸化办公系统。可能由于项目经理经验的问题,或者项目前期的一些问题,项目做的不是很顺利,越做东西越多,人员流动很大。功能是一方面,公文、政务、督查,业务逻辑比较复杂,并且各单位需求不同,用统一的流程有些复杂。协调是一方面,整个项目参与方已经超过了10家,作为主导的中软,和各家开发协调很有难度。最重要的,我觉得是项目开始没有一个很好的规划设计,需求的不明确,没有软件设计,项目做起来没有安全感。这个项目在我看来是很有前途的一个项目,但是项目周期太短了,同时进行的东西太多了,导致连续多个月的加班。同时,开发人员的不稳定,能力问题,导致整个项目开发进程不理想。再加上平台是第三方,很多东西都得修改,平台的支持毕竟还是有限制的。平台封装比较高,在可视化界面可以直接操作数据库,写js等,并且语句都存储在数据库中,导致没有办法实现很好的代码版本控制,使得很多问题反复出现。项目现在还在进行中,基本功能的东西已经实现,但接口的东西太多了,套红、签章、正文编辑、文件导入导出、移动办公(pad)、邮件系统、短信通知系统、二维码打印、CA认证、即时通信、数据迁移等等。需要多方支持,觉得进度缓慢,实现困难。

            总结:第三个项目还没做完,给我的最大感觉就是乱,因为人员问题,我是在最忙乱的时候加入的,做了一个月的需求、两个月的测试、一个月的数据迁移,从这就可以看出组织者无法让人员固定在一个岗位,这样很影响工作的效率。身为一个开发人员,该系统框架无法给我安全感,做出来的东西被人改动很多都无法发现,因为svn无法控制数据库的版本。我在这个项目寻找一个上升的方向,在项目组各个小组体验后,对今后的项目管理可能会有很大的提升。项目虽然肯定有无法预料的问题,但应该条理清晰,做好任务分解,人员调配。基本的项目规范,制度都应该在项目开始时定好,需求更是重中之重。项目虽然不能说失败,但从项目中很多的坑,可以学习到很多的经验,在以后的开发工作中,可以避免很多的问题。


            其次

            总结下当前个人遇到的问题。

            个人属于比较纠结的,应该算是有选择恐惧症。现在想的问题很是纠结,看不到未来的方向。


            1、这个行业是否能干下去,是不是应该回家。

            软件这行能做几年,可以一辈子干下去么,对于今后的发展是否合适,自己是不是应该回家,是不是应该去创业等等的问题,纠结着我。


            2、开发是否适合自己一直干下去,这行是否有上升的空间。

            虽然是开发出身,但是知道自己有几斤几两。正常的开发肯定是没有问题的,一些简单的技术问题还是能解决的,但是对于技术的深度,技术的学习,没有很强烈的兴趣,没有追求技术的心,那么意味着在干几年依然还是开发,没有什么前途。那么是不是就的寻找自己的方向,第一个肯定就是项目管理了,经过多年的开发,在开发中有很多的问题让我很不爽,需求的反复变更,项目初始没有规范导致后期难以维护,身为有强迫症的我,简直无法忍受。虽然自己也不一定能做到,但是总想挑战下。第二就是设计了,作为开发,做了两年其实基本没见过啥是设计,基本都是直接拿着需求就开发了,框架的结构是项目定好的,功能的设计基本都是自己搞的,作为科班出身,一直认为设计很重要,并且对于自己的思维有一定的信心。第三就是需求了,与人交流,不仅仅看的是表面的功能,关键看的是他们要实现什么。第四软件测试,经过快两个月,觉得不是很适合我,多次重复的工作对于我来说是坚持不下来的。那么就应该朝着多交流、多总结的方向去努力。


            3、跳槽的问题。

            来这做外包已经快三年了,在这待得比自己公司长的多,关系网基本全在这,公司的各种领导也多次让我跳槽入职,但我一直纠结与在不在北京待、要不要回家、辞职太麻烦的事情,以及北京公司有很多麻烦的事情,外协都可以不用参加,工资方面的差距也大都体现在五险一金上。工作快三年没有跳槽,在周围人中绝对是奇葩,同学大概不少都是我两倍工资了,我还是不知道应该怎么办。而且做了三年的政府、军队管理,跳槽互联网的工作觉得难度很大,继续又觉得没什么前途,纠结中。


            最后

            今后的我,要多总结日常工作中的问题、经验,努力找到自己的定位,多学习努力。虽然不知道乱七八糟写了一堆啥,但是感触还是比较多的,难得,以后要多回忆了。

    展开全文
  • 在一线做了十年的开发,经历了网易、百度、腾讯研究院、MIG 等几个地方,陆续做过 3D 游戏、2D 页游、浏览器、移动端翻译 app 等。 积累了一些感悟。必然有依然幼稚的地方,就当抛砖引玉,聊为笑谈。 一、对于团队而...

    在一线做了十年的开发,经历了网易、百度、腾讯研究院、MIG 等几个地方,陆续做过 3D 游戏、2D 页游、浏览器、移动端翻译 app 等。
    积累了一些感悟。必然有依然幼稚的地方,就当抛砖引玉,聊为笑谈。
    一、对于团队而言,流程太重要了
    行军打仗,你需要一个向导;如果没有向导,你需要一个地图;如果没有地图,至少要学习李广,找一匹识途的老马;如果你连老马也没有,那最好可以三个臭皮匠好好讨论,力图胜过一个诸葛亮;如果三个臭皮匠连好好讨论也做不到,那就是典型的乌合之众了,最好写代码前,点上三炷香,斟上一杯浊酒,先拜拜菩萨,再拜拜谷歌。
    我个人属于性格温和的(程序员大多性格不错),但确实见过少数强势的人,说很多强势的话。在技术上一言而决,一听到任何反对就上升到私人恩怨。这样的风格,到底是刚愎自用,还是胸有成竹,就需要仔细判断了。
    为什么说流程重要呢?实际上,如果团队上有孙悟空存在,去西天取经,大概也不需要什么流程,只要方向就可以了。 但作为普通的战士,应该先虑败。找人算命时,应该先听听不好的地方,好的地方就不用听了,总归是好的,不好的地方一定要听,这样才能规避。
    这就是我的态度:先悲观一点,划清底线,考虑在这个底线上你该怎么做?
    这是我做开发的一个习惯,但这个习惯肯定不适用于买房。
    怎么划清底线呢?就是假想团队中没有孙悟空了,光靠你唐玄奘、猪八戒和沙和尚,应该怎么去取经。
    这个月走什么地方,遇到山怎么走,遇到河怎么过,遇到路上有妖怪劫道,谁去抵挡。遇到路上有少女要搭救,怎么办?这就是流程,是原则。
    我经历过一个流程很混乱的阶段。都是很多年前的事情了,可以拿出来说说,不涉及单个人。
    2011年在百度浏览器团队时遇到几件让人影响深刻的事情。 有一次开会,产品拿出 Google 某个产品的 DEMO,里面有一段很酷炫 3D 效果,要求开发加上,只给2天时间,大家目瞪口呆。后续的开发为了赶节奏,导致非常多的 bug ,又为了修改 bug ,leader 将所有的 bug 按照人员平均分配,导致不同模块间的同学相互修改…实在难以想象。好比让做花卷的厨子,去修改西湖醋鱼的味道。
    最初的现象是:bug下降的慢,延伸 bug 反而增加,每个人都累的半死,代码风格极其杂乱,为了赶工导致的临时方案层出不穷;
    到了中期:人员离职越来也多,代码难以维护,新加的需求与之前的临时方案冲突。
    到了后期:想做一些修复,想调整架构,又要保证正常运行,其难度好比在一架飞行的飞机上拆换零件。
    然后我也急忙离职了…实在看不到成功的可能性。
    后来到了腾讯的团队,感觉流程就规范多了。需求和 bug 有 Tapd 跟踪,产品发布按照节奏,需求提出前会和开发反复讨论可行性,有专门的质量跟踪,有专门的用户反馈,每天知道要做什么,也知道明天要做什么。有产品需求,也有开发需求!这个非常重要。很多团队,都是只有产品需求,开发好像牛一样,耕完地就不管了?
    流程其实没那么复杂,就是各司其责+节奏。我们都是“哆瑞咪发梭拉西多”中的一员,各自有各自的责任,然后组合在一起,按照一个节奏跑起来。把该做的事情与该跑的节奏定好。
    二、不要炫技,老老实实写代码
    网上有一个段子,说有人要用JS实现一个简单的功能,然后朋友给他推荐了几十个库。
    真的有必要吗?具体情况具体分析。
    居家过日子,你只需要一套普通的工具就可以了;如果你是修车的,你需要一套修车的工具;如果你是光头强,你需要一台伐木机。 吃饭用筷子,用刀叉,都可以,但不要用杀猪刀,不要用丈八长矛!,当然也不能用牙签。
    用什么工具,用什么库,问问过来人,多在KM上搜索一下。举个例子:android 上加密,用 SQLChpher就可以了,微信也在用,你当然可以学习;数据库 ORM 思想,用 KM 上推荐的 GreenDAO 就可以了;PC 上 3D 引擎,用OGRE就可以了;小型游戏 DEMO,用 Irrlicht 足够;写 WebGL,用 ThreeJS 足够。
    首先想想:一些大库 hold 的住吗,后续发展如何?这些库对安装包的体积影响有多大?有没有调研过同样的产品在用什么?
    想清楚了再决定用什么,最好是跟随成功项目的脚步。
    三、架构上实用+适用
    很喜欢曾国藩的一句话:结硬寨、打呆仗。
    一字长蛇阵、八门金锁阵,哪个好?iOS 都是单个进程,微信 Android 版本3.5以前是单进程,3.5以后有独立的网络进程; PC 浏览器的进程架构更加复杂,UI 进程、内核进程、Render 进程,而且还有根据页面多少的进程调节模型。
    这些设计都很好,各有各的道理,都适用于当前的产品。所以我的观点是:首先分析当前产品的规模、性质,然后再设计架构。
    在当前阶段达到:开发效率+架构的平衡;并向后展望3个月,或者半年左右,看看架构能不能适应。
    我做腾讯翻译君时,曾反复犹豫要不要模仿微信加入独立的网络进程。后来逆向了有排在第一二位的竞品,最终采用了现在的主功能单进程模型。
    产品规模、人员规模、功能阶段,具体问题具体分析。
    四、既要有攻城之力,也要有熬战之气——BUG
    产品开发完成后,必然有 bug 。其实开发人员在工作过程中,是有一定的直觉或者心理预判的,即:某个功能模块的质量如何。 这里面的质量包括:可维护性、扩展性、算法渲染效率,还有就是bug与崩溃率。
    功能开发完成后,就要开始守城了。
    bug,一部分产生是由于架构带来的,例如比较复杂的架构,会导致复杂的实现细节;
    但还有很大部分bug,其实是基于如下三个原因产生的:
    1 . 对于某个api的不了解,或者对于某个平台,或者 SDK 版本的不了解。 举例而言:android里面非主线程,是不能直接处理UI相关的事情的;JAVA 的内存释放也不是绝对的,相互指向是无法释放的;函数个数是有DEX问题制约的---------------------这些bug的产生,也是开发人员摸索学习的过程,经历过一次就不会再犯了。这是学习广度与熟练度的问题;
    2 . 还有一些bug,是由于粗心大意导致的。例如空指针的问题,野指针的问题。在 C 的开发中,野指针的问题,GDI 句柄的释放问题,这些都是严谨的代码需要避免的; 而又一些工具,或者方法是可以规避这些问题的,例如 android中 的利用@ Nullable 和@ NonNull 加强空指针检测等方法;
    3 . 还有一些bug,是由于“使用情况各异导致的”。例如:偶现在某个模块crash。这里的本质还是因为逻辑的异常边界没有处理好。例如 android 上的 OOM 问题,还有 PC 上 UI 焦点导致的对象释放问题。这些异常情况,一部分靠测试发现,一部分靠用户反馈,还有一部分就靠自己的异常处理。例如Android中的try catch机制,其实就是遇到异常了,你能纠正错误的机会。
    五、自审
    每过一段时间,都要站在高空俯视自己,问问:到底是在承担过去,还是在改变未来。
    如果之前程序代码质量不好,后面修改问题的时间就会比较多。到了开发的中期,得多问问自己,你在不停的改正以前的错误,还是在做新的东西。 如果修改错误的时间多一点,那就要注意自己的代码质量了!
    六、注释
    我很喜欢写注释。有大牛说:代码就是最好的注释。 可惜我还没有达到那个程度。所以,我会把注释写的非常清楚。其一:为了自己以后维护的方便; 其二:为了其他人接手的方便。

    这是我在翻译君项目中写注释的方式。1:对于很复杂的逻辑,务必用12345的顺序依次写清楚;2 :对于函数中的某个参数,需要解释为什么要设置这个参数,尤其是公用工具类里面的函数—说清楚参数的背景含义,可以让其他调用者理解的更加清晰。
    我一般不用英文写。虽然这样看起来格调很低,但胜在大家都能轻松的看懂。写代码不能太傲娇,写注释也不要太傲娇,目的是让你的搭档或者接手者,更轻松的理解,让她/他少加班。
    七、代码结构
    代码结构要清晰。有按照功能划分的,有按照 UI 结构划分的。还有公用工具类,有数据管理,有主逻辑控制。不管用哪种思想,有序的代码结构,可以让每个人感觉很干净。好比日本的收纳整理技巧让很多小资推崇,无非就是干净、整洁、便于管理。
    而且,还有一个重要的好处:代码结构表现出来的其实是——程序的一个模块逻辑思想——让大家工作在不同的区域。
    八、代码风格
    代码风格统一!好比一家人,有叫 Tom 的,有叫安东尼的,还有叫流川枫、石破天、圣杰夫拉斯基,无所适从。理论上,看一个函数,就能从名称上区分哪些是成员变量,哪些是局部变量,哪些是全局静态值。
    除了命名统一外,还有一行代码最大的宽度,函数的连续调用长度等,头文件的包含风格,也最好有一个约定。类的出现时间,创建人名,最好也加上,看起来没用,但到了追踪问题时,就能看出时间线的好处。
    九、安全与逆向
    这是针对Android说的,还有PC插件也需要考虑。Android 上首先要防止被别人逆向,我成功逆向并重新打包过有第一位和第二位的竞品。这似乎有点不可思议,但确实做到了。加固+混淆+代码判断,最好都有。
    安全上,可以看金刚扫描的漏洞,逐一修改就行。公司很多工具很好用的!
    十、开发效率
    开发效率可以用这些方式提升:
    1 . 构建公用工具类,方便大家使用
    2 . 使用开源的一些包,例如 ORM 思想的数据库等
    3 . 可以很快的找到问题。开发中,找 bug 的时间,往往是很多的。我用的方法有3个: 使用 try catch; 拦截所有 crash 到我指定的地方;超多的 Log,Log 有统一的控制开关。
    4 . 借力:数据上报用灯塔,崩溃上报用 bugly,公司 KM 上很多经验,拿过来用。
    十一、安装包体积
    1 . TINY 压缩图片
    2 . 删除无效的资源文件
    十二、UI渲染效率
    UI 是用户的第一感觉;UI 快并稳定,第一感觉就不会差太多;管理好内存,基本管理好了一半 crash;管理好 UI,等于管理了人机交互感受。
    UI 上的开发是:渲染效率与渲染效果的平衡。
    很匆忙的写的,必然有很幼稚的地方,欢迎斧正。
    对Java技术,架构技术感兴趣的同学,欢迎工作1-5年开发程序员加QQ群:645615966一起学习,相互讨论。

    展开全文
  • 开发经验(一)

    2019-05-20 11:02:31
    最近开发一个小系统,遇到了一下点自己没有处理好,在这里记录下来。 第一个就是在设计系统的时候先提供一个业务接口A,在提供一个查询接口B。接口B的功能是查询接口A的执行结果的。开始的设计中当其他系统在调用A...

    最近开发一个小系统,遇到了一下点自己没有处理好,在这里记录下来。

    • 第一个就是在设计系统的时候先提供一个业务接口A,在提供一个查询接口B。接口B的功能是查询接口A的执行结果的。开始的设计中当其他系统在调用A接口的时候会返回我自己平台的流水,然后凭此流水来调用B接口。可是这样会有一个问题,就是我自己平台在在返回信息的时候网络出现异常了,调用方收不到我返回的信息,就没法查询了,只能再调用一次A接口。这样其实不好的。应该让调用方在调用A接口的时候将他们平台的流水上送过来,然后凭调用方平台流水来查询。这样就算出现上面情况也能查询,类似于银联接口、人行接口、政通连连等都是如此。使用第二种情况需要我自己这边判断一下调用方流水重复性,这里会有并发问题,可以通过数据库的唯一性索引处理,让它报错。当然可以用redis或者直接在查询的Java 方法上加锁。
    • 在实体类上有统计字段,比如某一个实体类上有总次数,成功率,平均耗时等字段。这些字段按理说应该是从流水表里查询出来的。但是我当时用的 jpa ,这种查询不好处理,所以我把这些信息定义在了实体中,然后每调一次业务就做一次更新操作,但是这样在一个tomcat线程中数据库操作会比较多比较耗时,然后在代码中用单独一个线程池来处理这样tomcat线程可以立即释放。但是这样处理还有一个问题就是并发的时候多个线程来更新数据库同一条记录。这样的话就只能在Java方法上加同步锁了,因为如果使用数据库事务的隔离级别,我担心查询实体方法也会被阻塞,而查询实体方法是在tomcat线程中的。可就算是这样处理了,在多机的情况下依然会有问题。因为Java加锁只在一个jvm里面有用。
    展开全文
  • java开发三年,总结一些经历与经验

    万次阅读 多人点赞 2018-02-22 04:15:36
    我是一个喜欢总结经验的人,每经过一场面试,我在回来的路上都会仔细回想今天哪些问题可以答的更好,或者哪些问题是自己之前没遇到过的,或者是哪个知识点今天又问了等等。四月中旬的时候,我就在构思要写一篇面经,...
  • 开发经验

    2019-06-18 00:29:35
    1.确保数据的正确。错误的数据会导致很多意想不到的错误。
  • 开发经验(漫谈)

    千次阅读 2016-06-26 07:20:47
    我没有快速学习的能力,我不得不在时间花费上非常谨慎。我希望尽可能地学习到有持久生命力的技能,即不会在几年内就过时的技术。只要占主导地位的计算模型体系不变,我们如今使用的数据结构与算法在未来也会以另外的...
  • 两年Java开发工作经验面试总结

    万次阅读 多人点赞 2017-05-08 23:45:41
    我是一个喜欢总结经验的人,每经过一场面试,我在回来的路上都会仔细回想今天哪些问题可以答的更好,或者哪些问题是自己之前没遇到过的,或者是哪个知识点今天又问了等等。四月中旬的时候,我就在构思要写一篇面经,...
  • 3年JAVA程序员的自评 半道出家的程序员,从不伪造简历,起点低,三年时才16k月薪*14在北京,认为混的比较差。 当然补充一句,不要拿应届生的所谓待遇来比,不是你比不起,而是这么比没意义,应届生接触了四年计算机...
  • VSCODE 打造完美java开发环境

    万次阅读 多人点赞 2018-01-23 11:56:58
    vscode Java 开发环境配置 (此博客已更新, 之前的排版不利于阅读) 使用vscode后,你可能无法忍受 eclipse :) 最后更新时间: 2018-07-01 (博客地址) 系统需安装jdk1.8,配置好环境变量JAVA_HOME 打开vscode,...
  • 4年Java开发经验如何要到30W年薪

    千次阅读 2018-10-31 17:13:38
    半道出家的程序员,从不伪造简历,起点低,三年在北京才16k月薪*14,认为混的比较差。 我没什么远大理想,就是挣20k-30k的税前工资就可以了,不用什么广阔的眼界和思路什么的,就这么简单。 ...
  • java项目开发经验总结,值得收藏!

    千次阅读 多人点赞 2018-09-08 14:46:09
    Java的主要应用领域就是企业级的项目开发!要想从事企业级的项目开发,你必须掌握如下要点: 1、掌握项目开发的基本步骤 2、具备极强的面向对象的分析与设计技巧 3、掌握用例驱动、以架构为核心的主流开发方法 没有...
  • java项目开发经验总结

    万次阅读 多人点赞 2016-09-05 18:02:09
    Java的主要应用领域就是企业级的项目开发!要想从事企业级的项目开发,你必须掌握如下要点: 1、掌握项目开发的基本步骤 2、具备极强的面向对象的分析与设计技巧 3、掌握用例驱动、以架构为核心的主流开发方法 ...
  • 程序员面试失败最常见的五...Java程序员面试失败的原因一:说得太少 程序员不善言辞是IT界的通病,他们所有的语言表情都用代码代替了,平时在办公室也只能听到啪啪啪的键盘声,几乎没有语言上的沟通,可能是职业原因,
  • 6年开发经验女程序员,面试京东Java岗要求薪资28K

    万次阅读 多人点赞 2020-03-28 14:00:05
    写在开头: 上周面试了一位女程序员,上午10::30来我们部门面试,2B哥接待了她.来看看她的简历: 个人简历 ...● 熟悉 redis 、rocketmq、dubbo、zookeeper、netty 、nginx、tomcat、mysql。...
  • 源码分析 分布式 微服务 性能优化 工程化 项目实践
  • 一年多Java开发工作经验面试总结

    千次阅读 多人点赞 2018-12-22 13:53:13
    最近换了家公司,第一次跳槽,其实很早就有这个打算,只不过自己的技术水平不够,不敢随便裸辞,在今年的九月份尝试过面试几家,每经过一场面试,我都会总结今天的面试内容,由于在职期间去参加面试,其实是很不方便...
  • Z平台-开源免费的JAVA快速开发平台

    万次阅读 多人点赞 2019-08-24 19:26:39
    Z平台是开源免费的JAVA快速开发平台,通过Z平台集成开发环境,以零编码、动态配置的方式能够快速开发BS管理系统。同时该平台还可以做为APP、微信、各种小程序等项目的服务端来使用,为前端项目提供数据接口。并且Z...
  • 找工作:java开发三年工作经验

    万次阅读 2013-03-05 11:29:46
    个人基本简历 ...工作经验 三年以上 籍贯: 河北省邯郸市 所学专业: 计算机应用技术 现住地址: 北京 联系电话: 150 1125 1824 QQ
  • 如何获取独立项目开发经验

    千次阅读 热门讨论 2009-07-30 21:37:00
    10月25日读者见面会☆★☆★ 本文是,清华大学出版社《Java程序员,上班那点事儿》作者:钟声——第4章《第4章 换位思考,项目主管的招聘技巧》部分节选。 但是,很多应聘者都没有明白这个独立完成一个项目经验有...
  • java开发要求

    千次阅读 2019-04-06 12:42:42
    Java开发工程师 1-1.5万/月 恒宝股份有限公司查看所有职位 申请职位 职位信息 岗位职责: 1、完成软件系统代码的实现,编写代码注释和开发文档; 2、根据设计文档或需求说明完成代码编写,调试,测试和维护;...
  • java web开发(二) 接口开发

    万次阅读 多人点赞 2016-06-03 16:50:34
    java web开发(一) 环境搭建讲解了如何搭建一个Java Web项目,如果你还没了解,建议先浏览下!今天这篇文章主要讲解的就是接口开发,打算使用比较古老的或者说比较原始方法实现的接口。 一.数据库设计。 假设要做...
  • 蓦然回首,从毕业到现在做后台开发已经十年了,这十年中我获得了很多,技术能力、培训、出国、大公司的经历,还有很多志同道合的朋友。但再仔细一想,这十年码农路上我至少浪费了五年...
  • 10年java经验程序员感叹,面试了二十多家公司的Java开发岗位,面试真的太难了,把面试的java面试题整理出来提供参考! 本人是做java开发的,这是我参加工作几年面试总结所得,现在Java面试对程序员的技术要求普遍都...
  • java开发工程师简历模板

    千次阅读 2019-07-22 15:14:31
    这篇文章还在更新,正在孵化,但是你可以借鉴是这里面的一点点经验…持续更新! 2. 简历的书写 HR筛选简历时,一般来说非常的快,可能你的简历10秒就被看完了。所以,简历要简单干脆 2.1 一份好的技术简历 首先,一...
  • 1.不同系统之间的调用 2.决定线程数量的jvm参数 3.MySQL左右连接,select * 和 select 全部字段的区别,in和exist的区别 4.基本类型和包装类的区别 5.为什么使用kafka 6.内部类的使用,匿名内部类对变量的要求 ...
  • https://www.cnblogs.com/yanfei1819/p/10213673.html
  • 广州一年java开发经验,工资能有多少?
  • JAVA开发微信支付(JSAPI方式)大致流程

    万次阅读 2019-03-07 18:13:45
    参考官方API文档 (先看哈官方文档好有一脸懵逼...官方SDK (相当于工具类,可以方便后面的XML和map转换,以及随机数和一些加密签名的操作,有java和PHP等开发SDK,这里选择java SDK进行下载) https://pay.weixin.qq.com/...
  • 微信小程序开发【前端+后端(java)】

    万次阅读 多人点赞 2018-07-13 22:19:46
    所以现在用这篇博客记录我之前开发的一些经验和一些心得吧。 主要内容 springboot+mybatis构建 小程序项目构建 小程序组件讲解 小程序api调用 后台resetful接口编写 小程序调用后台接口 小...

空空如也

1 2 3 4 5 ... 20
收藏数 2,647,500
精华内容 1,059,000
关键字:

开发经验