我们是一家位于成都市高新区的中型软件公司(上市公司子公司),主要研发面向 B 端的产品。现在公司需要研发一款低代码开发平台,诚聘资深全栈开发工程师。
30–50K / 月,另有项目奖励。
请将简历发送到 enBta2t4QGdtYWlsLmNvbQo=
,标题注明“应聘资深全栈开发工程师 - 姓名”。
加分项:
1
ShaoYuanNuo 47 天前
现在也在搞低代码,做的真烦
|
2
polobug 47 天前
低代码要堆人。。然后实际上客户还会有各种二开,要给很大修改权限
|
3
qxhnks OP ![]() @polobug 这个已经考虑到了,低代码平台要成功我觉得要注意以下三点:
1. 一是要明确系统的功能边界,不要贪大求全,越是希望什么都能做最后越是什么都做不好,成功的低代码平台往往是集中解决某一类特别垂直的问题,越是通用的低代码平台往往最后发展都不太好; 2. 二是系统的可扩展性要在一开始设计的时候就要充分考虑到,例如钉钉宜搭“连接器”的概念,使得其可以与钉钉平台上数量庞大的第三方应用打通,具有无穷多的扩展性和应用场景; 3. 三是要避免做成一个面向程序员的平台(即生成代码),因为很难解决手工修改代码后与模型的同步问题,并且专业的程序员往往会嫌弃低代码平台的灵活性不足,无法发挥程序员的优势。所以我们的低代码平台主要面向具有少量的编程基础和数据库操作能力的软件实施人员以及企业的信息科 IT 运维人员。 |
5
biubiuGolang 46 天前
尤其是大客户二开 有一个算一个难搞...
|
6
tangzx88 46 天前
结合个人开发低代码的经验,好用的低代码通常都会确定一些使用场景,如果只是针对具有少量的编程基础和数据库操作能力的人,那他们的业务就不能太复杂;否则还是要提供一些 api 进行操作,或者提供插件入口;数据模型要有很高的配置能力,前端组件也要根据数据模型自动匹配,避免再次手动处理。
|
8
qxhnks OP ![]() @tangzx88
是的,低代码平台很难用来去实现企业的核心务。 我们的低代码平台主要包含自定义表单、流程审批、工作流自动化、BI 大屏、报表制作等功能,平台的使用群体主要是软件实施人员或企业的 IT 运维人员。 简单来说我们对标的是钉钉宜搭,但是 B 端市场是一个很分散的市场,并不存在赢家通吃的情况,所以其实我们与钉钉宜搭并不直接竞争,我们有我们的客户群和市场前景。 |
![]() |
9
chengdonghui 46 天前
搞这东西真的没啥用,低代码平台够多了,没听说用的好的
|
![]() |
14
chicbian 45 天前 ![]() 现在就在做低代码平台,Java+vue3(ts),整个架构体系都是我带头重构+优化。这东西,我以前也感觉鸡肋,但是从市场反应来说,还不错。
|
![]() |
15
pangdundun996 45 天前 ![]() @qxhnks #13 我们现在的低代码平台就是 go 做的,感觉还行
|
![]() |
18
bojue 45 天前
@chengdonghui Mendix 算行业标杆了可以体验下,这两年的 NocoBase ,Retool 这些还不错
|
19
qxhnks OP 对低代码平台的价值还有疑虑的朋友可以看看这个钉钉宜搭的视频讲座 https://www.yuque.com/yida/video/su17oo 和 https://www.yuque.com/yida/video/iboqyh
|
![]() |
21
pinktu 45 天前
这种支持 Lua 代码生成的低代码可以不 https://github.com/dgzhuya/wink-vue-admin
|
22
VictorChang 44 天前
你好,你们接受猎头合作吗?我这边有很多人才积累
|
![]() |
23
particlec 43 天前
感觉对低代码思路很清晰,但是国外很多平台得到了巨额投资没有做起来,国内也是,感觉很难
|
![]() |
24
echoless 43 天前
跟各位大佬学习了 感谢
|
25
qxhnks OP ![]() @particlec
B 端市场跟 C 端市场很不一样,需要丰富的行业经验积累以及深入的耕耘,指望像互联网公司那样一口吃成胖子是不现实的。换个角度说 C 端互联网公司虽然发展得快,但遇到问题后可能死得也快(由于激烈的竞争和烧钱补贴消费者),B 端市场则相对平稳得多。 另外,借鉴 Peter Thiel 创业讲座《 Competetion is for Losers 》中关于 capturing value 的理论,一个人去成熟的大公司打工虽然可以领到一份不错的薪水,但你的收入占公司只收入是一个极小的百分比,而中小型公司的整体收入虽然比不上大公司,但是由于你对于团队的重要性,你的个人收入(工资+股份)完全可能会大于在大公司打工的收入,而且你还因为在一个精干的团队中工作而获得了宝贵的经验和成长,何乐而不为呢? |
![]() |
26
echoless 43 天前
@qxhnks #25 在国内很难, 在国外小公司能够小而美也是少数 . 当然我看你们的薪水在成都已经很好了. 希望国内有更多 toB 的公司能赚到钱.
我观察过 erp 领域 国内 toB 的公司一个比一个亏的多, 国外同行则过的还可以. |
27
biubiuGolang 43 天前
国外的客单价要比国内多,但要求也更高
|
28
qxhnks OP ![]() @echoless 国内做大而全的 ERP 或 MIS 软件的厂商挣钱都比较困难,利润率微薄,原因可以参考这篇文章 https://www.oschina.net/news/296135 反而是一些小而美的公司以及垂直类、工具类的软件的公司比较挣钱,例如帆软,etc
|
29
happy32199 42 天前 via Android
@chicbian 做的是 erp mes 这类的低代码吗
|
30
happy32199 42 天前 via Android
@qxhnks b 端私企一样卷,竞争对手直接去我们客户那去翘,给个实施费就免费换系统
|
31
aqw012 41 天前
@qxhnks #8 我们部门就是做低代码的,你说的功能我们都有,并且在这些方面也有一些积累了。目前实施的客户也有不少了。但是离盈利还有些距离。这玩意人少了会很难做效果,人多了投入就会很大,我司在低代码上烧了不少钱(上亿),唉,今年现在也撑不住在裁员了
|
![]() |
33
richardwong 40 天前
低代码这种东西,真的有人用?
|
34
qxhnks OP @richardwong 真的有,参看我前面的回复
|
35
horizon 40 天前
学到了,op 要不要拉一个交流群,hah
|
37
69partner 37 天前 ![]() 同样我司我也正在负责做低代码平台,公司方向同样是 b 端。低代码目前我认为是能够可行的发展下去的。真真切切的会降低实施人员的门槛。
|
38
guangfa 32 天前 via iPhone ![]() 做了 5 年低代码平台的核心开发,大公司,2B&2G 方向,后面基本成了做项目的底座,团队内部熟悉之后做项目又快又爽。但是最后还是因为财务问题,整体解散。
|
![]() |
39
dyq917 32 天前
低代码前端水平要求比较高,全搞只能全搞不好
|
42
understanded 31 天前 via Android
能远程不?
|
43
qxhnks OP @understanded 不好意思,不支持远程
|
![]() |
44
xzg1993 30 天前 ![]() 我们也是 4000 块钱买了套低代码平台,做的功能还不错,已经在实际项目中使用了。
|
46
goodspb 24 天前
* 读过 Patterns of Enterprise Application Architecture (PoEAA)
这个有点 6 😁 又学到了 |
47
happy32199 24 天前 via Android
@xzg1993 请问买的哪家的啊?
|
![]() |
48
aleimu 17 天前
这样的工作和薪资在成都应该算是很高了吧,放 boss 上能被投爆
|
49
qxhnks OP ![]() @aleimu 简历确实被投爆了,但其实符合要求的人很少,我们对候选人的要求还是很高的,希望候选人一定要基础扎实,各种知识技能融会贯通,而不是言必称高性能、高并发、高可用、微服务,这样的候选往往问得稍微深一点,问一些本质性的东西就答不上来了,感觉国内很多开发者的技能树点歪了。
我理解,在这样一个浮躁的社会,大家都想学点“值钱”的技能,都想有一技傍身,都希望去下家拿个大 offer ,但是希望大家基础一定要打牢,基础不牢地动山摇,勿在浮沙筑高台。编程语言、面向对象设计原则和设计模式、数据结构与算法、操作系统、数据库和计算机网络这几项一定要掌握好,还有英语的重要性强调一万遍也不为过。同时也要理论联系实际,不要纸上谈兵,可以没事造点小轮子,然后跟业界领先的同类产品做比较,从而获得提高。调 API 写应用写 CRUD 跟封装一个好轮子需要的能力相比至少差两个档次。 另外,不要脱离场景谈技术,最近几年大家有一股盲目追求微服务的风潮,实际上大部分场景用单体就可以了,运维、部署、监控还更简单。并发不够了先适当垂直扩展一下,要是还不行的话,单体也可以横向扩展,单体不代表就一定是单机部署,也可以多实例配合负载均衡。只在实在有必要的时候再考虑微服务,而且不管是单体还是微服务都要先把模块划分和依赖管理搞顺了,这样在需要切分微服务的时候也就顺其自然了。如果下决心搞微服务了那配套的工具和基础设施一定要跟上,DevOps 、自动化测试都要搞起来(自动化测试的重要性强调一万遍都不为过),否则最后很可能变成“分布式单体”( Distributed Monolith )或“分布式大泥球”( Distributed Big Ball of Mud )或“分布式屎山”(我发明的词),四不像。最近几年连微服务的原始布道者 Martin Fowler 和 Sam Newman 也开始在反思微服务,也在告诫大家要冷静,要慎用微服务,要先单体,必要时再一个服务一个服务地切分出去。当然有的情况是架构师或技术管理者希望故意把事情“搞大”、“搞复杂”,想要争取更多的资源分配和曝光度,来获得职场晋升,那就不是技术问题了,不在本文讨论之列。 今天有感而发,班门弄斧了,希望大家不吝赐教,欢迎大家批评、斧正。 |