这是一个创建于 1724 天前的主题，其中的信息可能已经有所发展或是发生改变。
本人毕业后写了 3 年的 API，近期入职一家公司要自己写后台系统的前端（ vue ）感受颇深，总结一下就一个字：爽！
老子想怎么定义接口就怎么定义， 日期格式想怎么定就怎么定， list 想[]就[]，想 null 就 null，null 值想传就传，不想传就不传，再也不用迁就各种端，呸，真爽！
第 1 条附言 · 2019-08-01 16:58:18 +08:00
哈哈，只是源于上份工作对客户端的各种迁就（各种不合理，不规范）的一个吐槽，讲道理还是要规范写代码的，一时的爽换来的是什么大家还是都懂的
现在开发这个系统两周，后端 3 天就写完了，剩下的时间都在调 CSS 和研究 vue 各种组件，爽并难受着。
现在开发这个系统两周，后端 3 天就写完了，剩下的时间都在调 CSS 和研究 vue 各种组件，爽并难受着。
 |
1
xxx749 2019-07-31 18:53:02 +08:00  2
然后拿一份工资干两个人的活
|
 |
2
stormynight 2019-07-31 18:54:36 +08:00 7
然后发现大部分时间在调 css
|
 |
3
leafre 2019-07-31 18:54:55 +08:00
就一个字：爽！
|
 |
4
kkkkkrua 2019-07-31 18:56:48 +08:00 via iPhone
。。。还是规范点好，不然后来人会骂娘的
|
 |
5
CEBBCAT 2019-07-31 19:00:05 +08:00
没有软件工程这根弦是不是有点危险？
|
 |
6
hillwall 2019-07-31 19:00:34 +08:00
@stormynight 太真实了，蛤蛤
|
 |
7
EminemW 2019-07-31 19:00:58 +08:00 via iPhone
然后把时间都放在前端上了，过一阵子觉得索然无味
|
 |
8
OSF2E 2019-07-31 19:07:20 +08:00
说白了，还是个先点菜（先写前端）还是先炒菜（在前端接口需求未确定的时候假装知道前端要什么样的 API ）的问题。
|
 |
10
ntop 2019-07-31 21:19:42 +08:00
哈哈哈，这么写一段时间就会进入到首鼠两端的境界，发现自己既不会搞后端接口也不知道该怎么写前端代码~~
|
|
12
ntop 2019-07-31 21:36:14 +08:00
@SleXion 我之前就是这么随意之后搞的自己不会写 API 了，现在 API 严格按照 RESTful 的标准来。写后端的时候不考虑前端，写前端的时候只看 API 实际上效率上是提升了
|
 |
13
KuroNekoFan 2019-07-31 21:40:18 +08:00 via iPhone
css 就那么令人不堪吗，比如，ui 上需要一个矩形然后两边突出的 shape <口>带描边，可以不用贴图用纯 css+html 做到吗？ materialui 的 ripple 效果可以给出一个简单的实现吗？其实 css 也是很有趣的
|
 |
14
luo1215 2019-07-31 21:55:44 +08:00
现在就是都在写，挺蛋疼，2/3 的时间都花费在前端上面
|
 |
15
lozzow 2019-08-01 00:11:45 +08:00 via iPhone
然后你会发现自己开始写的都是💩，看到想骂自己
|
 |
17
chenhonzhou 2019-08-01 01:16:03 +08:00 via iPhone
小弟有幸接盘过这种代码，我只能说，******
（还是要稍微规范点，文档时一定要的！） |
 |
18
beastk 2019-08-01 01:36:08 +08:00 via iPhone
表示经常在 js php python go 之间切换，时不时 ide 就报错，很是忧伤。
|
 |
19
leafiy 2019-08-01 01:39:17 +08:00 via Android
迫于后端离职又没钱，本 pm 只得临时接手后端。
不得不说，真鸡儿爽，都得听我的！ |
|
20
OSF2E 2019-08-01 01:50:09 +08:00
@ntop 只要有靠谱的产品功能设计文档、数据模型设计文档以及 UI 设计稿，前后端完全可以以这些东西为协作规范先各做各的，具体点说，前端需要哪些接口以及接口返回哪些字段，后端不可能事先知道。就好比顾客去餐馆吃饭，炒菜的师傅不可能事先知道客户具体点那几个菜，只能先让顾客点菜， [菜单] 就是“顾客”与“厨师”两个角色的在“点餐 -> 炒菜”这个流程中的协作规范，假若“厨师”为了方便省事儿提前把菜炒好了放在那里等顾客来点，这生意怕是做不下去了。
|
 |
21
12tall 2019-08-01 08:35:57 +08:00
后面维护的时候呢
|
 |
22
darknoll 2019-08-01 09:18:49 +08:00
我这 gui 用 python
核心业务用 C++ 后端接口用 go 前端用 react 我一人全干了，结果啥都会啥都不行。 |
 |
23
hyy1995 2019-08-01 09:20:12 +08:00
让后端人员去兼职前端，这也只能说明你这个公司不规范，没章法，项目乱七八糟。。。而且拿的还是一份工资。等后期维护的时候，事情就多了
|
 |
24
abcbuzhiming 2019-08-01 10:03:38 +08:00
@KuroNekoFan CSS 的最大问题在于它最开始首先是个排版系统，而不是 UI 系统，但是现在的 web 开发 80%以上的 CSS 开发是在做 UI 系统。排版和 UI 考虑的方向是不同的，而且排版系统本身是极其复杂的，你看看 TeX 和 Word 这两个最知名的排版系统有多复杂，其实 CSS 的复杂度也没低到哪里去。用 CSS 这么复杂的排版系统去做 UI，本质上就是在用牛刀杀鸡，过高的复杂度让用户大部分时间在和系统本身的复杂度作战，而没法专注业务，这就是为啥大部分编程出身的人员都搞不定 CSS 的原因。而前端程序员中觉得 CSS 没什么的开发者，绝大部分其实也没搞懂 CSS 的全貌，只是它们比较适应目前 CSS 的这种“这里改改那里试试，就行了”这种开发方式
|
 |
25
86091566 2019-08-01 10:32:54 +08:00
然后就发现没办法甩锅了
|
 |
27
fredshao 2019-08-01 13:55:42 +08:00
就是干，爽 [哭笑]
|
|
28
KuroNekoFan 2019-08-01 17:00:40 +08:00
@abcbuzhiming 你说 html 原本是个排版系统倒好，说 css 是排版系统我是不认可的。css 本身的出现就是为纯粹的 ui 服务的，只不过文字的展示必然涉及到一部分排版的知识而已。
|
 |
29
aug7 2019-08-01 17:00:53 +08:00
接私活搞全栈爽...上班搞全栈 = 全干(不爽)
|
|
30
abcbuzhiming 2019-08-01 20:49:31 +08:00
@KuroNekoFan css 最初就是为了更好的排版而诞生的，css 诞生的年代，Web 领域根本就没有 UI 这个概念，那时的 UI 还是属于原生程序专属玩具，那时的人连想都没想过 Web 居然有一天能干人机交互界面的事情。怎么可能为 UI 去设计 CSS。
这导致第一版 CSS 里有大量的概念都源自传统印刷业，比如 margin 要叠加，比如那该死的 float。也就是最近几年 Web UI 变的越来越重要，所以加入了大量为 UI 准备的新特性，比如 flex |
 |
31
W1angMh 2019-08-02 15:18:30 +08:00
@stormynight 真实的不行
|
Select Language