这是一个创建于 1268 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如命名变量讲究，尽量低耦合设计，接口测速，尽可能的优化和压榨性能等等，我之前写业务代码是打算这么做，但又想到这些个代码又不属于自己，优化的再好老板也不会给加工资，想通后所以现在是估期多估 2d ，尽量快速完成开发，至于优化啥的等测试提再说，没提是最好，然后剩下时间全用来写自己的开源项目，好歹 GitHub 上的项目写在简历上面试官可能会看
 |
101
lrzsw2008 2022 年 8 月 18 日
不会太好不会太差，细节上可能会优化，但是大的方向上不会过多改动
|
 |
102
techgogogo 2022 年 8 月 18 日  1
事实上，这个往往不是你能决定的，而是你所处的团队和企业决定的。
- 如果项目时间不赶，项目经理往往会要求认真执行定下的编码规范。 - 如果项目比较赶，往往这个时候是怎么做快出产品就怎么来，而编码规范，单元测试这些往往是最容易砍掉的。 - 如果你身处一个大型外企，这就和第一种情况类似，且就算项目比较赶，也不会牺牲单元测试和编码规范。因为这些企业很清楚这样做将会欠下所谓的「技术债务」，而债务，出来混，迟早是要还的！ |
 |
103
Konys 2022 年 8 月 18 日
开发是开发的时间,优化是优化的时间,不能搞混
|
 |
104
limingxinleo 2022 年 8 月 18 日
是的，我司这边代码质量，从今年开始，要求只比开源代码低一线。
接口级别单测全覆盖 代码风格要求统一 尽量全面的注释 尽可能高的性能优化 有些小伙伴的 PR 可能只有一两行，也会在我的要求下，改好几次。 |
 |
105
Patrycja 2022 年 8 月 18 日
有时间就慢慢迭代上去 没时间的话 有一个能跑就行
|
 |
106
cryboy007 2022 年 8 月 18 日
看交付时间，如果逼得急怎么简单怎么来
|
 |
107
dnsaq 2022 年 8 月 18 日 via iPhone
想要成为一个优秀的人，就要养成优秀的习惯。现实会告诉你没有人逼迫你优秀，你养成什么习惯你就会成为什么样的人。
|
 |
108
Visionhope 2022 年 8 月 18 日
刚开始工作的时候比较完美主义, 设计考虑得比较多, 但也可能是因为缺少经验, 这样就感觉每个开发周期比较劲, 把自己弄得比较累. 现在经验上来了, 一方面开发快了, 一方面也就不那么完美主义了, 比较有些时候这些代码可能真的就是开发一次, 后面就不维护了.
|
 |
109
Helsing 2022 年 8 月 18 日 via iPhone
会，技术方案、Code Review 、MR 齐活，尽量保证质量。
随便写很有可能给自己埋坑，导致花更多工时或加班 |
 |
110
shaojian0702 2022 年 8 月 18 日 via Android
公司开始查代码量，我的代码量远远少于部门内的 cv 大神。分公司，看公司文化吧。
|
 |
111
newmlp 2022 年 8 月 18 日
不会的，啥公司都一样，能跑就行，现在这种情况说不定你的项目明天就没了
|
 |
112
acerest 2022 年 8 月 18 日 1
总体来说，我把自己当手艺人，不是流水线工人，所以一直以来，都在认认真真对待自己的手艺和作品。从结果看，各种意义上都能算得上收益颇丰。
|
 |
113
kingjpa 2022 年 8 月 18 日
不会。
而且会故意延长 上线时间，因为吃过亏， 加班加点赶完，被认为这东西好简单。 |
 |
114
zhuweiyou 2022 年 8 月 18 日
长期维护的项目, 架构更重要一些. 性能啥的 我觉得根本不是瓶颈.
|
 |
116
kkeep 2022 年 8 月 18 日 via Android
会，
|
 |
117
icetea66 2022 年 8 月 18 日
我这两个礼拜天天到 12 点，还想让我尽善尽美？
|
 |
118
chenyu0532 2022 年 8 月 18 日 1
我会写的首先让自己满意。我自己都觉得垃圾的代码我是不会要的
|
 |
119
joApioVVx4M4X6Rf 2022 年 8 月 18 日
我刚开始也是这么想的，好好写，结果发现不仅加班还要延期，后来就看淡了，赶紧写完，被发现了我就改，没人发现就那么着，写完回家学习
|
 |
120
ruoxie 2022 年 8 月 18 日
性能就是能跑就行，但是一定有严格的规范。项目是公司的，开发体验是自己的
|
 |
121
cnbaskloekf 2022 年 8 月 18 日
必须的，对得起那份钱
|
 |
122
zhady009 2022 年 8 月 18 日
还是要尽量写好 后面写习惯了你会发现和呼吸一样
|
 |
123
chuhemiao 2022 年 8 月 19 日
每一次的不细心,都需要未来的无数次细心去弥补.
|
 |
124
james122333 2022 年 8 月 19 日 via Android
会到一定的程度 为了在往后节省大量时间用来摸鱼取得好的生活与工作平衡 除非有限制难以实现否则都想这么做 既有语言框架和上头想法都是其中的影响因素
|
 |
125
shakaraka PRO 2
写出好代码是由内而外的。如果是随时随地写出的东西都是一坨屎，那么你可能要提升自己，而不是出来问别人要不要写好代码。
|
|
126
shakaraka PRO 这个问题本身就很奇怪
|
 |
127
sy20030260 2022 年 8 月 19 日
性能是一方面，代码风格是一方面，这是俩问题啊~
|
|
128
sy20030260 2022 年 8 月 19 日
性能是一方面，代码风格则是另外一方面，这是两个问题啊~
性能问题无所谓，能用就行，大不了先上线再优化；而代码风格方面：代码可读性，变量合理命名，避免重复代码等等...都是实实在在方便自己后续维护啊，对自己有好处的事有啥理由不做呢？ 反而，我遇到的那些写一手烂代码的程序员，大多数并不是不想写好代码，而是没能力把代码写好。或者由于缺乏经验和方法论，写一段风格良好的代码得绞尽脑汁、反复修改，久而久之就放弃了。懒只是个借口罢了~ |
 |
129
wangritian 2022 年 8 月 19 日
看情况，业务代码我会写的随意一些，组件 /中间件就认真写
|
 |
130
shalk 2022 年 8 月 19 日
边写边优化，平时写的好一点，留一点时间也优化一下。都算在计划里。
|
 |
131
interim 2022 年 8 月 19 日
完全却决于工期
|
 |
132
Devilker 2022 年 8 月 19 日
那必须尽善尽美，我都写两份，一份跑，一份写好注释
|
 |
134
aliveyang 2022 年 8 月 19 日
会尽量低耦合设计，性能优化看情况，工期不紧会回头重构，工期紧就算逑
|
 |
135
magicyao 2022 年 8 月 19 日
看工期，有时间就写，没时间就爬，你催我我注释都不写
|
 |
136
deesan 2022 年 8 月 19 日
代码也是艺术
|
 |
137
minglanyu 2022 年 8 月 19 日
尽善尽美很难
前期设计代码的时候，把扩展性考虑进去就很好了 以应对不断变化的需求 |
 |
138
macy 2022 年 8 月 19 日
会，工作中的代码命名语义化，性能必须优化，因为后续维护大概率还是自己，不想给自己挖坑，即使是离职了，也不想被后来人骂，反而有时候自己写项目，代码会有点瑕疵，不会太在意，能满足需求就好。
|
 |
139
darknoll 2022 年 8 月 19 日
绝对不会，随意写，你写的好不是在卷别人？况且自己会啥没必要展示出来，学会深藏不露
|
 |
140
mirrorman 2022 年 8 月 19 日
我有代码洁癖，review/merge 代码的时候基本上每一行都要看一下，写的有歧义除非说服我，否则我不会合并的
|
 |
141
fox0001 2022 年 8 月 19 日 via Android
尽善尽美的 TODO 注释…
|
 |
142
hankai17 2022 年 8 月 19 日
大多是业务代码 螺狮山
|
 |
143
tutuge 2022 年 8 月 19 日
口碑是积累出来的，经验更是，不管是公司的代码还是自己的项目，都当作一件作品认真做，才能一点点提高，才能“下笔如有神”
|
 |
144
ak47007 2022 年 8 月 19 日
有个问题，公司没有牛逼的大佬来规范代码，那我自己怎么才能知道自己的代码写的好呢？
|
 |
145
Suomea 2022 年 8 月 19 日
当一张表数百个字段的时候就全部拼音缩写了，不会讲究命名了~
|
 |
146
nuanshen 2022 年 8 月 19 日
大多是时间不允许啊
|
 |
147
ft7138 2022 年 8 月 19 日
正常排期，时间够的话，会尽力写到最好。
|
 |
148
Amber2011 2022 年 8 月 19 日
时间允许的范围内尽力优化,不然就准备下次维护赶时间而写出来的代码前速速提桶跑路或者怀着无比后悔的心情去重构自己的旧代码.
"一位程序员花一个礼拜匆匆赶出的成果，也许会在未来几十年里折磨无数开发人员" |
 |
149
leexy 2022 年 8 月 19 日
有时间再说,下次一定
|
 |
150
msg7086 2022 年 8 月 19 日 1
我们代码写得不干净的话连 code review 都过不了。长期发被人喷的 PR 没多久就 PIP 送走了。
当然实际上我们这里不太会出现这种可能性，因为代码写不干净的话，连组里的 code interview 都过不了，就算过了我们的 interview ，bar 那边也过不了，所以不需要担心招进来一些写代码稀烂的人。 （除非和印度人一起写代码。） |
 |
151
p1gd0g 2022 年 8 月 19 日
公司需要你尽善尽美吗？
或者说能给公司带来多大好处？ |
 |
152
mrzx 2022 年 8 月 19 日 1
很简单，只问你内心深处，你对得起你自己吗？
|
 |
153
tomieric 2022 年 8 月 19 日
@wangtian2020 能用三元运算符绝不用 if ，switch
|
 |
154
nmap 2022 年 8 月 19 日
如果将来也是自己维护，肯定要用心点，不然现在节省的时间精力将来会加倍弥补！🙏
|
 |
155
JLX 2022 年 8 月 19 日 via Android
今天改，明天上
|
 |
156
aleen42 2022 年 8 月 20 日 via Android
己所不欲，勿施於人
|
 |
157
tramm 2022 年 8 月 20 日
会, 我有强迫症, 会不会完善.
排期紧的话就算了 :P |
 |
158
jdOY 2022 年 8 月 20 日
人和代码，有一个能跑就行
|
|
159
james122333 2022 年 8 月 20 日 via Android
|
|
160
darknoll 2022 年 8 月 20 日
@james122333 别人怎么写我就怎么写呗，也没说故意乱写啊
|
 |
161
KunMinX 2022 年 8 月 22 日 1
之前听过一个概念，叫 “长期公平”，
一名优秀的工程师在接到需求时，能第一时间预估和规避各种潜在的错误，此皆平日训练累积所得，终能复利。 项目是公司的，经验是自己的。 |
 |
162
ivvei 2022 年 8 月 22 日
总体原则是能用就行…… 细节上看成本，有些顺手就做了的那自然也不会故意留着
|
 |
166
offswitch 2022 年 10 月 14 日
@zwdsix 我工作这些年，见过太多你这种，整天开口闭口设计模式呀，什么理念，写了一大堆的设计模式，还觉得自己写的不错，实际上呢，代码写的是真的烂，还要别人去擦屁股，当然他自己还觉得自己做的没问题。
|
Select Language