如何写出难懂但是有必要的代码？

Question

这个问题有些矛盾，请让我解释：
我们公司是外包公司，就是不断的接新项目，不断的做项目，无限做。
我干活比较实在，领导经常让我把一个项目最重最麻烦的干完，干到80%，就把项目交给别人收尾，然后让我干新的项目。

我希望我写的代码有一定的技术壁垒，别人不能轻易接手，让我可以享受项目结尾不咋忙的时间段。而不是我把粗活重活干完了，就给别人了，最重要把，我还跟别人拿一样的钱(doge).

但是这个壁垒绝对不能使多余的，故意加上去的,比如typescript,zustand，对把，这些都是可以提高代码质量的，同时可以提高技术壁垒。

大佬们，还有什么其他的“前端技术”推荐的吗，提高代码质量，还可以不让我像生产队的驴。

Answer 1

还有什么其他的“前端技术”推荐的吗，提高代码质量，还可以不让我像生产队的驴。

你的方向错了，问题的根源是为什么你成了生产队的驴。这需要你和安排你任务的人沟通了，问题根源是这里，听你的口吻你的管理者不太尊重你，那你大可骑驴找马或灵活的消极怠工，你和管理的矛盾应该你们自己解决，不应该波及兄弟同行

既然提到壁垒了，我认为这个壁垒最主要的还是看你负责的模块是干嘛的

比如拖拽、视频这种不常见的功能就不可避免相对于简单的数据呈现要难上不少，经验不足的前端未必能解决这类需求

就算你改变自己的写法为各种复杂的设计模式，由于你不是负责整个项目框架的搭建所以复杂度很难提升

另外，由于你是外包公司，也不可能上规范的软件工程流程，所以不妨还是找问题的根源在哪，别在这些地方上浪费时间，也别去搞所谓忍者代码，真正的好代码是能让初级程序员也能看懂的代码

Answer 2

看一遍忍者代码你就明白了

Answer 3

并不是所有问题都能用技术手段解决，觉的没有得到应有的待遇可以和领导谈，完全没必要搞所谓“难懂却有用的代码”。
另外，做外包的工作模式肯定是和常规有差别的

Answer 4

前端开发通常没有“难题”，只有“繁题”，不断的接新项目，不就意味着你可以定义这个项目的完整走向？

1. 构建工具不使用已有的常见脚手架，webpack？不用；vite不用；rollup不用；自己手撸一个，从模块管理、热更新、css编译等插件都自己搞一套，再订制一些特有的标记，自己工具编译效率高，其他工具还都无法支持的。（这个事儿我干了7、8年了，效果显著。）
2. 加入一些看起来无法确定是不是必要的东西，比如你习惯使用 RxJS，搞起来。
3. typescript 是提高可维护性，降低技术壁垒的。你觉得这玩意儿能提高技术壁垒，只能说明你自己还完全不理解它，当然也就意味着很多人也有一样的问题，你能用好也能成为你自己的技术壁垒。

以上都算是比较“正”的“技术壁垒”，都得“先卷自己，再卷别人”，难度较大，成长也好，我的技术壁垒大多是这么建立的。

Answer 5

上比较新的潮流技术就好了，国内大部分的程序员都不会马上跟进学习，所以你可以带薪学习+业务驱动，其他人接棒也会十分苦恼。
其实我倒是反过来，比较喜欢接受挑战的一些内容，项目主体完成之后，我基本都会写项目文档和关键部分注释，然后把垃圾时间交给其他人来干。

其实只要你能力足够了，工作不怕丢，很可能离职之后薪资待遇还能涨一涨。毕竟“互联网行业涨薪就靠跳槽”这个梗还是有点现实依据的。

另外一个就是不要长时间待在外包公司，虽然可以快速学习一些新得技术并得以应用，但是你会缺失很多持续维护迭代相关的横向知识，还是要小心自己成为新时代纺织工的

Answer 6

大佬们，还有什么其他的“前端技术”推荐的吗，提高代码质量，还可以不让我像生产队的驴。

那就推荐 Angular 吧，天然集成 TS、RxJS、DI 等等，还有专门的风格指南。前期上手肯定会有一定的技术壁垒，但是对于项目本身既提高了代码质量，又可以不用那么累。

Answer 7

待遇方便最好跟领导好好谈谈，别把痛苦带给新同事。我写代码都是尽可能地清晰，一个逻辑一行代码，所有引用都能在当前模块找到来源。如果说一定要让代码不易接手，除非故意乱写代码，比如大量的全局变量、函数、event-bus、全局状态管理等，这些维护起来就很绕，不易看懂