结合自己写代码的一些经验,提炼几点思考。

31 天前
 Amose2024
1. 有些时候并不需要追求高可复用,特别是有很多自定义行为的时候,需要传入多个参数来到自定义目的。这个时候,追求复用容易造成后续维护不便。

2. 避免追求“一步到位”。当自己的项目很可能没有多少用户的时候,切忌上来就搞分布式高并发集群部署。多数项目生命可能也就几个月,没必要一开始就推高成本。在使用框架的时候,也要考虑用户基数,并不是队列就一定要用百万吞吐的 Kafka 。

3. 避免盲目追求项目性能。C++比 Java 快,Java 比 Python 快,这没有问题,但并不是因为要追求快,项目就必须用 C++。绝大多数情况下,项目的访问速度到不了要拼语言速度的程度,其它的诸如硬件配置,网络带宽才是影响性能的大头。

4. Web 开发并不只有 Java Spring 一家。项目快速出原型并推向市场试错,如果心里只有 Java 就太重太慢了。不妨考虑一下 Ruby on Rails, NextJs 等能够快速出产品的方案。某种程度上 PHP 就是最好的语言,Wordpress 就是能更快建站。能快速满足需求,比耗时长久的大而全要好得多。

5. 避免追求广度,缺乏深度。并不需要了解大多数的语言和大多数的框架,很多东西其实是相通的,能够深度掌握某一个的意义更大。

6. 项目部署能用云服务商的方案就用它的方案,不要自己折腾,犯不着一到部署就要自己买个云服务器,整个 EC2 ,然后发现性能监控,日志服务,安全策略等都要自己搞,费时费力还做不好。

7. 理解需求后再动手写代码,可以显著提升后续维护的舒适度。

8. 保持乐观开放的心态,学会合作很重要。一个人造不出 Google ,团队有时虽然沟通成本高,但也确实有集体智慧。

9. 是否会看文档是判别程序员水平的最重要依据之一,但不是接手一个新东西就要花费 10 天半个月去看完它所有文档,考虑一下网上 30 分钟入门视频先上手又何妨。

10.碎片时间很重要。现在已经很难有大块的时间让你去研究某个技术了,利用好碎片时间,专注某一个题目,日积月累效果惊人。相反,东一下西一下,最后什么也捞不到。

11. 很多时候开发机不需要那么强的性能。一个长续航的轻薄本解决问题的时候,不需要花冤枉钱追求 128G 内存,4090 显卡。

声明:个人原创,转载请注明出处。
2971 次点击
所在节点    程序员
23 条回复
speedmancs
31 天前
- 过早优化是罪恶之源

- 单元测试很重要,还有 code review
wmui
31 天前
我以前特别喜欢优化代码,看到乱的就想改,后来我这毛病改了,因为导致代码乱的是变态的需求
murmur
31 天前
现在除非是我一眼就能看到复用的代码我才会抽出来,AI 加持下还是复制粘贴爽
murmur
31 天前
Spring 这个是因为国内大量 to b to g 的项目需要用,不是 java = web ,是因为没有企业开发,互联网那点市场早萎缩了,根本不需要什么 web 程序员,都去做小程序 app 了,以前是 h5 pc 几套页面,现在给你个下载页面都是抬举你
guanhui07
31 天前
@wmui 写完面条代码的当事人不优化重构 可读性才是原罪,比如 if 嵌套,方法提炼,用卫语句,变量名提炼都写代码的基础操作 很多人
harryWebb
31 天前
现在是能简化需求尽量把需求简化掉

需求结构越简单,代码越不容易出错,后续修复起来也容易
GradyJ
31 天前
学习了
AlexHsu
31 天前
现在这个年头一定要分清自己项目和公司项目的区别 不要过分去重构和封装公司项目 公司项目文档这个东西也是得过且过就行 不管是什么级别的程序员一定不要从公司的角度去考虑技术 一定要从个人角度考虑 听懂掌声
反倒是自己的开源项目要下点功夫 那毕竟是体现个人能力的最直接体现方式 面试这个东西已经苍白无力了
systemGuest
31 天前
“上来就搞分布式高并发集群部署” 这是很多小公司的通病,他们一般是招了大厂背景的人,或者听了“大厂”的朋友话,不结合实际情况,用户量都没有就一股脑去模仿架构,如果他们是这种情况你可千万别去讲道理,他们会认为你不专业,人家大厂就是这么干的你还 BBB ,会更加坚信这是对的。
linxl
31 天前
单测+一个函数就干一件事。curd boy 表示能碰到这样的就很满意了。
supermama
31 天前
不要过早优化!当然可以比你现在业务需要的基础上领先个 30%,也已经足够了。
tool2dx
31 天前
现在偷懒取巧欠下的技术债,在未来的某一天,早晚要让你还出来的。
hellojukay
31 天前
说的很好
horizon
31 天前
第一点很重要,多少人写的垃圾代码都是因为追求复用
其实毛用没有
flmn
31 天前
变态的需求是避免不了的,所以我们在设计代码架构的时候,要把干净东西和脏东西分开存放,不要混在一起,你中有我,我中有你。

那块是个屎堆,对,我知道,但是我把屎都堆在一起了……
fov6363
31 天前
过早优化、过度设计是万恶之源。

忘了从哪本书看到的三枪理论,先简单粗暴实现,如果有问题就改,如果同一个地方有问题超过 3 次,就可以考虑重构了,否则怎么快怎么来
ixx
31 天前
第 4 点 应该说要结合个人/团队整体看,找到自己最熟悉的技术栈,如果对 java 最熟悉,重一点也比学习一门新技术靠谱。
第 7 点 其实就是根据需求写技术设计文档,然后再开发,文档写完需求基本就透了。
darkengine
31 天前
@tool2dx “取舍”是个很艺术的东西,舍多了后期还债还得要哭,取多了项目周期受影响。
vfs
31 天前
尽可能用你能想到的最最最简单的技术解决方案
xuxian4321
31 天前
基本没错

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1092934

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX