胖五加油!作为程序员,该如何去挽救一个失败的项目?

  • 时间:
  • 浏览:0
  • 来源:uu直播快3平台_UU快3直播官方

3.在低基数、低频率的搜索上写优化算法,算法和业务逻辑搅在同去,这麼分开为另4个层面

11.太大有作者不必开源工具包,喜欢买车人搞一套,有炫技嫌疑,实际上搞得很烂

9.混杂的代码风格,花括号行尾、换行也有 ,缩进用tab、2空格、4空格、8空格,紧凑风格和松散风格也有

7.不写注释、不写文档

20.页面还是jsp,jsp里写了极少量的业务逻辑,甚至通过httpclient去抓别的项目,抓回来内容嵌在当前页面里

19.到处也有 HashMap,而不必java bean;另4个HttpServletRequest调了五六层妙招;买车人手工拼json字符串;拼email的html body,不必模板

16.大片的被注掉的代码留在项目里,到处也有 ,太大废弃的类和废弃的配置文件这麼删掉

22.代码重复度很高,一段逻辑,到处克隆技术粘贴

你是什么项目,是该公司交易系统的核心,每周相当于 4次发布,迭代时延很高。

往底下加逻辑异常困难、很容易出疑问,开发和QA都心力交瘁,新逻辑也有 hack进去的,会加重代码腐烂。

4.业务配置文件过于简化,过度设计,真是 是事件模式解析

15.pom依赖关系一团糟,各种重复引包、重复依赖,httpclient竟然多达另4个版本

23.数据库表设计很烂,意味着不好查(比如用逗号分隔的串),较老得表甚至毫无注释(生产环境)

各位在写tcp连接时可能生活涵盖遇到过失败吗?您是如何看完失败的?

我坚信这麼几买车人这麼遇到过失败,当然我是属于多数。遇到失败了,才知道疑问出在哪了,你看完了失败,就证明你在向胜利招手。

有遇到过项目不符合要求而推倒重来的吗?

你是什么还真没遇到过

作为tcp连接员,该如何去挽救另4个失败的项目?

最近到另4个新公司,接手另4个很烂的项目,发现太大疑问:

8.log4j和logbak混用,各占一半

1.一半的bean用spring管理,另一半的bean买车人new可能用单例模式,spring的包扫描配错了,但两年时间经常这麼改过来

2.到处也有 静态类、静态妙招,这麼扩展

18.该打日志的地方这麼打,意味着太大工单成了无头案,太大地方,又重复打日志,啰里啰嗦

14.对spring、spring mvc了解和利用严重发生问题,框架支持得很好的功能,不可不能否买车人写

17.每个作者都喜欢买车人搞一套,发生问题共识,本人 为战,各种约定、各玩各的

24.整个团队都这麼代码质量追求,习惯了烂代码

12.分包分得一团糟,既想按照功能分,又想按照业务分,这麼把握好,稀里糊涂的

21.到处也有 main妙招,不必单元测试

6.800行的大jsp、大类、800行的大妙招、多达17个参数的妙招,喜欢写万能函数

13.妙招、变量命名词不达意,经常在getXXX、isXXX的妙招里改传入参数,但又反回值,从命名就能看出作者词汇量狭窄、思维局限

如何摆脱你是什么困境?

当然先撇开政治正确性的疑问,太大 从技术深度来探讨下可行性!就如太大回答中说到的,解决那我 的项目时要足够的耐心,摆正买车人的态度是极为重要的。好了,鸡汤说完,具体为什么会么会在么在操作呢? 从底下的描述看,你是什么是另4个典型的 monolithic system。其混乱程度估计不亚于我手头哪些超过10多年的超级老系统的中的代码。补丁上打补丁是常见的事情。特性哪些的也有 其次的,假如有一天能运行,太大哪些也有 靠边的。调试哪些的也有 无从做起,完也有 一团乱麻的代码。第一步 理清楚运行代码逻辑。可能系统无法Debug,这麼就暂且Debug。可能系统无法Debug,这麼就暂且Debug。可能系统无法Debug,这麼就暂且Debug。开发过程中,Debug是也有 时要的?暂且一定,可能也有 所有的语言和IDE也有提供很强大Debug功能,太大不可不能否很弱的Debug,太大甚至都这麼。这麼哪些语言是如何保证代码否是写对呢?其中另4个辅助手段太大 输出非常完善Log信息。一段可不时要代替Debug的Log应该涵盖以下太大基本的内容:1.某段逻辑代码的输入参数值2.关键性底下变量的值3.逻辑代码的输出参数值4.第三方库调用事先 的输入参数值,比如SQL说说,第三方函数的输入值5.第三方库调用事先 的输出参数值6.输出Log所在的类名,函数名,有条件的可不时要输出行数7.距离上三根Log输出的时间差 (太大 前三根Log信息输出事先 ,过了有几条毫秒的运行时间)8.tcp连接ID9.客户端调用IP10.服务器tcp连接版本号11.Exception信息其完全程度是有个标准的,太大 可不时要根据哪些信息做现场还原为准。可可不时要够还原现场了,就足够了,或者就根据还原现场缺少累积去加上。稍微解释下1-5是输出值的,你是什么是用来检查逻辑否是正常运行的。6 是用来代码定位7 用来性能调优8 是预防多tcp连接模式下Log信息混杂在同去无法分离9 是用来和客户端联调10 是用来快速迭代的事先 区分Log版本11 是用来保存运行中的各种Exception太大 系统是多客户端调用的,这麼日志输出的文件,可不时要每个客户端IP另4个文件夹,分开保存。那我 一次调用逻辑就会发生另4个文件里。不必辛苦的从另4个大日志里把某个IP的信息单独分离出来。那我 的Log信息除了代替Debug之外,可不时要保留一切运行信息,对于太大买车人Debug这麼发现的Bug的追踪是非常有用的。比如题主你是什么混乱的系统,就可不时要从日志系统结束改造。首先有个好处是修改日志系统,不必影响运行逻辑,不必把系统改坏掉。引入另4个新的日志接口,可不时要包装你买车人喜欢的Log框架,可能买车人编写的日志。统一好日志接口事先 ,可不时要在买车人写到的代码中加入新的日志,可能时要分析代码中随时加入以及修改旧的日志接口代码。那我 慢慢的搞上个把个月,基本上太大常见的运行逻辑也有理的很清楚了。在你是什么基础上,来解决太大简单的重构活动,应该不成疑问了。【说实话,我现在做开发,可能很习惯用Log代替Debug了,不先写好另4个完善的Log系统,也有 会写代码了。。。。】--------------关于Log疑问的评论疑问补充答案-----------Log系统代码没几行的,我代码中核心的累积不可不能否几十行,算上配置代码,以及内外部调用的wrapper代码,总共后来多 百来行。主要还是另4个设计思路的疑问。如何下发最多信息以及不影响整体性能。设计思路在底下可能说的很清楚了。--------------15年8月31日更新--------------最近事多,慢慢补基本上一份逻辑简化,可能定义混乱可能太大从代码深度无法探清运行逻辑的,通过运行日志是理清楚其运行逻辑的。假如有一天重写的代码的运行逻辑和旧系统的运行逻辑是一致的,这麼这两累积的代码是可不时要完全互相替代的。或者在大幅度重构事先 ,太难做的一件事情太大 删除代码第二步,删代码和改注释删除代码和修改注释,也是一种简化系统代码,同去和增加Log代码一样,不必影响那我 的逻辑。作为tcp连接员,有不少的代码很辛苦的写出来事先 ,会可能各种意味着被弃用。于是哪些代码太大 成了鸡肋了。 弃之可惜,食之无味。一方面是辛苦写出来的,可能删除掉,你说歌词 下次买车人不见得要能完全的再写一次一样的逻辑。或者的确当前又用不上。于是先注释掉,留待后用那我 的想法是自然会再次老出的。我买车人也有 那我 的想法,也经常想留下太大废弃的代码留待将来可能复用累积。或者实际上,你是什么切并这麼卵用。废弃代码重新启用的可能在同另4个项目中基本是可能的。这麼为什么会么会在么在心安理得的删除呢? 当然是源代码管理了,不可不能否是个Git可能Svn在,就可不时要凶狠的删除掉了。“万一有用,找下旧版本的代码就好”,那我 的自我心理安慰就很容易了,下手也就更狠了。注释累积也是这麼,老代码的注释,可能发生问题维护,经常是注释和代码逻辑再次老出不一致的情形。那我 的注释,要么删除,要么改掉。有源代码管理,随便删除废代码,随便改注释。出了疑问,代码滚回去【Rollback】就好了。

有这麼创业失败而东山再起的?来分享一下经验!

还这麼创业,分享不了

10.太大作者喜欢用反射调代码,没妙招用ide跟踪

若要重构,可能要同去维护另4个版本,或者重构风险很大,一旦出事,将影响TL的前途。

5.买车人写了个Dao,买车人手动管理事务,到处拼sql,六七十个 字段的表,每个操作都重复拼

开发平均薪资估计12k,真是 写出那我 的代码。