作为开发人员,你需要做的更少,考虑的更多,学会优雅的拒绝

2024-05-29 20:38

本文主要是介绍作为开发人员,你需要做的更少,考虑的更多,学会优雅的拒绝,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

No, no, no, no, and no. And no.

A big NO. Clear as that.

All you have to do is to bring those two letters together and say the word.

Now, let’s say it together. NOOOOOOO!

Good start.

But wait a minute. Say NO to what and when?

Well, this is the important point where most of the programmers (even seniors) get easily confused.

As a programmer, writing code is the biggest part of your job. In your programming lifetime, you will have to deal with different kinds of code requests. Each request will force you to make difficult decisions. That all is OKAY. Nothing wrong with that. This is what everyone expects from you, as a programmer: Writing code. However, here is a question: Should you write all the code that is requested from you?

This question brings us to the most important skill a programmer can learn:

Knowing when not to code is possibly the most important skill a programmer can learn. — The Art Of Readable Code

I couldn’t agree more. Why is that?

Programming is the art of solving a problem. So naturally, programmers are problem solvers. As programmers, when we have a new problem in front of us ready to be solved or any other reason that needs from us to write code lines, we get excited.

And that is okay because we are programmers. We love writing code.

However, getting too excited about writing code makes us blind. It causes us to ignore some important facts that can cause bigger problems we will have to deal with in the future.

So, what are those important facts that we tend to ignore?

Every line of code you write is:

  • code that has to be read and understood by other programmers
  • code that has to be tested and debugged
  • code that will increase defects in your software
  • code that probably will introduce new bugs in the future

As Rich Skrenta wrote, code is our enemy:

Code is bad. It rots. It requires periodic maintenance. It has bugs that need to be found. New features mean the old code has to be adapted.

The more code you have, the more places there are for bugs to hide. The longer checkouts or compiles take. The longer it takes a new employee to make sense of your system. If you have to refactor there’s more stuff to move around.

Furthermore, more code often means less flexibility and functionality. This is counter-intuitive, but a lot of times a simple, elegant solution is faster and more general than the plodding mess of code produced by a programmer of lesser talent.

Code is produced by engineers. To make more code requires more engineers. Engineers have n² communication costs, and all that code they add to the system, while expanding its capability, also increases a whole basket of costs.

It’s so true, isn’t it? The programmers who inspire you with their productivity and coding mentality are those who know when to say no and when not to code. The software that is easy to maintain, that lasts long and keeps helping their users is the one that doesn’t contain any unnecessary code lines.

The best code is no code at all, and the most effective programmer is the one who knows when not to code.

How can you know when not to code?

It’s natural to get excited when you’re working on a project and think about all the cool features you’d love to implement. But programmers tend to overestimate how many features their project needs. Many features go unfinished or unused or simply make the application overcomplicated. You should know what is essential for your project to avoid making this mistake.

Understanding the purpose of your software and its core definition is the first step to know when not to code.

Let me give you an example. Let’s say you have software that has only one purpose: managing emails. And for that purpose, sending and receiving emails are two essential features to your project. You can’t expect that software to manage your to-do list as well, can you?

So you should say NO to any possible feature requests that are irrelevant to this definition. This is the moment you can be exactly sure that you know when not to write code.

Never expand your software’s purpose.

Once you know what is essential for your project, you will be conscious next time when you evaluate possible code requests. You will exactly know your requirements to write code. Which feature should be implemented? Which code is worth to write? You will question everything because you will know exactly how unnecessary code can kill your project.

Knowing when not to code keeps your codebase small.
The Art Of Readable Code

There are only two or three source files when you start your project. All looks so simple. It takes just a few seconds to compile and run the code. You know where to find exactly what you’re looking for.

Then, as the project grows, more and more source files fill your directory. Each code file contains hundreds of code lines. To organize them all, you will need multiple directories soon. Remembering which functions call other functions is more difficult, and tracking bugs requires a bit more work. Managing your project becomes difficult, and you need more programmers to help. Communication overheads increase as the number of programmers increases. You get slower and slower.

In the end, the project becomes huge. Adding new features is painful. Even making small changes takes hours. Fixing present bugs always introduces new bugs. You start missing deadlines.

Now, life is a struggle for you. Why?

Because you didn’t know when not to code, you said YES to every possible feature request. You were blind. Coding something new caused you to ignore essential facts.

It’s like a horror movie, right?

This is what will happen if you keep saying YES to everything. Know exactly when not to code. Eliminate all unnecessary code from your project. This will make your life easier and make your software last longer.

One of my most productive days was throwing away 1000 lines of code. — Ken Thompson

I know that knowing when not to code is so hard. Even for senior programmers. Perhaps what I wrote in this article is hard to understand for junior programmers, and that is okay and understandable.

I know you have just started your programming journey and you want to write code. You are so excited about that. This is good. Never lose this excitement but also never ignore the important facts. We learned them by making our own mistakes. You will make mistakes as well, and you will learn from them as well. But at least you can be more conscious if you can learn from our experience.

Keep coding but know when to say no to coding.

Originally published at http://huseyinpolatyuruk.com.

这篇关于作为开发人员,你需要做的更少,考虑的更多,学会优雅的拒绝的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1014588

相关文章

Spring Boot中JSON数值溢出问题从报错到优雅解决办法

《SpringBoot中JSON数值溢出问题从报错到优雅解决办法》:本文主要介绍SpringBoot中JSON数值溢出问题从报错到优雅的解决办法,通过修改字段类型为Long、添加全局异常处理和... 目录一、问题背景:为什么我的接口突然报错了?二、为什么会发生这个错误?1. Java 数据类型的“容量”限制

Java实现优雅日期处理的方案详解

《Java实现优雅日期处理的方案详解》在我们的日常工作中,需要经常处理各种格式,各种类似的的日期或者时间,下面我们就来看看如何使用java处理这样的日期问题吧,感兴趣的小伙伴可以跟随小编一起学习一下... 目录前言一、日期的坑1.1 日期格式化陷阱1.2 时区转换二、优雅方案的进阶之路2.1 线程安全重构2

使用Python实现一个优雅的异步定时器

《使用Python实现一个优雅的异步定时器》在Python中实现定时器功能是一个常见需求,尤其是在需要周期性执行任务的场景下,本文给大家介绍了基于asyncio和threading模块,可扩展的异步定... 目录需求背景代码1. 单例事件循环的实现2. 事件循环的运行与关闭3. 定时器核心逻辑4. 启动与停

浅析Java中如何优雅地处理null值

《浅析Java中如何优雅地处理null值》这篇文章主要为大家详细介绍了如何结合Lambda表达式和Optional,让Java更优雅地处理null值,感兴趣的小伙伴可以跟随小编一起学习一下... 目录场景 1:不为 null 则执行场景 2:不为 null 则返回,为 null 则返回特定值或抛出异常场景

SpringBoot利用@Validated注解优雅实现参数校验

《SpringBoot利用@Validated注解优雅实现参数校验》在开发Web应用时,用户输入的合法性校验是保障系统稳定性的基础,​SpringBoot的@Validated注解提供了一种更优雅的解... 目录​一、为什么需要参数校验二、Validated 的核心用法​1. 基础校验2. php分组校验3

Java8需要知道的4个函数式接口简单教程

《Java8需要知道的4个函数式接口简单教程》:本文主要介绍Java8中引入的函数式接口,包括Consumer、Supplier、Predicate和Function,以及它们的用法和特点,文中... 目录什么是函数是接口?Consumer接口定义核心特点注意事项常见用法1.基本用法2.结合andThen链

轻松掌握python的dataclass让你的代码更简洁优雅

《轻松掌握python的dataclass让你的代码更简洁优雅》本文总结了几个我在使用Python的dataclass时常用的技巧,dataclass装饰器可以帮助我们简化数据类的定义过程,包括设置默... 目录1. 传统的类定义方式2. dataclass装饰器定义类2.1. 默认值2.2. 隐藏敏感信息

Go信号处理如何优雅地关闭你的应用

《Go信号处理如何优雅地关闭你的应用》Go中的优雅关闭机制使得在应用程序接收到终止信号时,能够进行平滑的资源清理,通过使用context来管理goroutine的生命周期,结合signal... 目录1. 什么是信号处理?2. 如何优雅地关闭 Go 应用?3. 代码实现3.1 基本的信号捕获和优雅关闭3.2

C#如何优雅地取消进程的执行之Cancellation详解

《C#如何优雅地取消进程的执行之Cancellation详解》本文介绍了.NET框架中的取消协作模型,包括CancellationToken的使用、取消请求的发送和接收、以及如何处理取消事件... 目录概述与取消线程相关的类型代码举例操作取消vs对象取消监听并响应取消请求轮询监听通过回调注册进行监听使用Wa

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定