面对很乱的代码,你会慢慢看,慢慢改,还是重写?
回复内容:
是时候祭出这两张图啦!

团队的力量呢?2-3个人或许好找,但是去哪里找50-100个愿意去重写代码的人,并且还能保证质量呢?
更难的是,到哪里找到经理或老板愿意等你半年甚至一年不响应需求,不改bug,而是去重写代码,去用一套新代码完成和老代码一样的功能,甚至可能更多的bug。
抛开程序员的完美主义情怀,理性地看待分析旧代码,问自己几个问题:
是不是继续维护的成本真的比重新开发还要高?
是不是新的团队在设计开发能力上比原有团队上了一个台阶?
是不是有一些硬需求在旧代码上无论如何都无法做到?
是不是没有竞争对手在穷追不舍而不能停止更新维护?
是不是重写能提供些杀手级功能压制竞争对手?
分别对旧代码和新架构做下 SWOT分析,看看优势,劣势,机会,威胁都是什么。
旧代码或许在架构,接口设计,变量命名和缩进风格上不如人意,但是它是可以工作的,可以工作的代码意味着解决了很多问题,而这些问题在新重写的代码里并不会因为代码写得漂亮就自动得到解决,仍然要把前辈们踩的坑再踩一遍。
那么是不是就不能重写代码呢?不是,要等机会,看缘分的。
个人认为,如果我上面问的五个问题至少三个问题的答案是“是”,SWOT分析的结果里至少三项是有利于重写的,那么可以说也许缘分来了。 先看懂,一段很难看的代码可能是编程水平问题,也可能是为了避开某个坑所做的妥协,要有耐心,不懂就不动。
看明白了,再根据现有需求做决定,设计上有问题,不能满足需求,那就重写,不要妥协。需求能满足,没严重bug,就是代码乱,那就不要轻易动它,宁可在外边加个wrapper,把它包起来。 从毕业到现在5年时间,接触公司各种以前的N手代码(无任何什么文档),练就一身阅读代码神功,首先大家不要想着怎么去重写之前人写的代码,有些看起来不是特别美观代码,通常都是各种业务妥协的结果。
重构之前请自己掂量一下时间和自己的能力,没准下一个程序员就想着怎么重构你的代码。
没想到有一篇文章想法和我一样《抵制代码重写》
上上周改了一个500行左右的小代码,C语言,全都塞在一个文件里,一堆全局变量,代码重复一大堆(之前那个人不会用sprintf,一份自己实现的atoi复制了三份),功能互相交织,变量名各种一个字母的昨天,一位老上级邀请我一起吃午餐。当坐在哪里等待上菜时,我们缅怀起早期这个公司的往事。他有一句话让我心里一虚:
啊,你这个判官…我记得当你看到Dan(公司的第一位程序员)写的代码时的样子。你说:“这代码写的真烂,需要重写!”
我恐怕是没有足够的勇气告诉他,我这“代码需要重写”的主张是错误的。不错,我认为这代码写的很乱。但是,据过去历次的经验,我感觉大部分的程序员 看着别人写的程序时都会想:这代码写的真烂。事实上,当一个程序员数年后再看自己写过的程序时也会想:这代码写的真烂。也许他们想的是对的;这代码确实很 烂。
但是,如果你认为代码需要重写,你将犯下一个低级错误。
公司里有一些想当然的看法会让你可能现在不能认识到这点。大量的不成文的想当然的观点可能会让你无法解释清楚。
我喜欢Joel Spolsky说的关于这种事情的话,有些事情你永远不要去做:
我们是程序员。程序员,在他们自己的心里,是建筑师,当他们来到一个地点,第一件想要做的事情就是:把这地方推平,盖上辉煌的建筑。他们对慢慢的修缮没有兴趣:小修小补,改善,培植花草。
有一种不可捉摸的原因让程序员们总是希望丢掉这些代码、重新再写。原因是他们认为老的代码是混乱的。可是,你会观察到一种非常有趣的现象:他们的判断通常是错的。他们之所以会认为老的代码很烂的原因来自于一个重要的、基本的编程定律:
读代码比写代码要难。
这就是为什么代码很难重用的原因。这就是为什么每个团队喜欢用自己不同的函数来做把字符串拆分成数组操作的原因。他们要写自己的方法,这更容易,更有趣,不需要弄清楚老的函数的工作原理。
根据这种定律必然得出这样的一个结论,你现在可以问一问任何一个程序员,问他们对正在写的程序感觉如何。“乱的不能再乱了,”他们会这样告诉你。“我宁愿把它们都删了重新再写。”
当你招募来了一个程序员,如果他想重写看来工作的不错的程序,你要抵制。他也许会说Java过时了,太慢,Ruby on Rails如何的酷。也许他会向你抛了一大堆专业名称术语。不管他如何做,你要三思而行。
你觉得呢?
然后我给拆成了7个分管不同功能的源代码,有的函数直接重写,改变量名,根据全局变量的范围调作用域,最后都改成了static的文件作用域,加访问接口,顺便中途还被傻x编译器坑了一个多小时
然后发现还不如我自己重新写一个 重写或者辞职。。 慢慢改,一块一块慢慢重写,最终整个重写掉了。 重写 一般是立刻重写,然后一堆bug,解决完发现又是一坨需要重写的烂代码,然后突然明白了它为什么一开始这么烂 一般来说是重写。看下输入输出,大概就明白是干嘛的了,人家写了100行,觉得自己90行搞定就不管了,觉得30行能搞定,果断注释掉重写

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

AI Hentai Generator
AI Hentai를 무료로 생성하십시오.

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

뜨거운 주제











Laravel은 직관적 인 플래시 방법을 사용하여 임시 세션 데이터 처리를 단순화합니다. 응용 프로그램에 간단한 메시지, 경고 또는 알림을 표시하는 데 적합합니다. 데이터는 기본적으로 후속 요청에만 지속됩니다. $ 요청-

PHP 클라이언트 URL (CURL) 확장자는 개발자를위한 강력한 도구이며 원격 서버 및 REST API와의 원활한 상호 작용을 가능하게합니다. PHP CURL은 존경받는 다중 프로모토콜 파일 전송 라이브러리 인 Libcurl을 활용하여 효율적인 execu를 용이하게합니다.

Laravel은 간결한 HTTP 응답 시뮬레이션 구문을 제공하여 HTTP 상호 작용 테스트를 단순화합니다. 이 접근법은 테스트 시뮬레이션을보다 직관적으로 만들면서 코드 중복성을 크게 줄입니다. 기본 구현은 다양한 응답 유형 단축키를 제공합니다. Illuminate \ support \ Facades \ http를 사용하십시오. http :: 가짜 ([ 'google.com'=> 'Hello World', 'github.com'=> [ 'foo'=> 'bar'], 'forge.laravel.com'=>

고객의 가장 긴급한 문제에 실시간 인스턴트 솔루션을 제공하고 싶습니까? 라이브 채팅을 통해 고객과 실시간 대화를 나누고 문제를 즉시 해결할 수 있습니다. 그것은 당신이 당신의 관습에 더 빠른 서비스를 제공 할 수 있도록합니다.

기사는 PHP 5.3에 도입 된 PHP의 LSB (Late STATIC BING)에 대해 논의하여 정적 방법의 런타임 해상도가보다 유연한 상속을 요구할 수있게한다. LSB의 실제 응용 프로그램 및 잠재적 성능

PHP 로깅은 웹 애플리케이션을 모니터링하고 디버깅하고 중요한 이벤트, 오류 및 런타임 동작을 캡처하는 데 필수적입니다. 시스템 성능에 대한 귀중한 통찰력을 제공하고 문제를 식별하며 더 빠른 문제 해결을 지원합니다.

Laravel의 서비스 컨테이너 및 서비스 제공 업체는 아키텍처의 기본입니다. 이 기사는 서비스 컨테이너, 세부 정보 서비스 제공 업체 생성, 등록 및 예제와 함께 실질적인 사용을 보여줍니다. 우리는 ove로 시작합니다

이 기사에서는 프레임 워크에 사용자 정의 기능 추가, 아키텍처 이해, 확장 지점 식별 및 통합 및 디버깅을위한 모범 사례에 중점을 둡니다.
