Keeping code simple: moving fast by avoiding over-engineering

44 点作者 mmphosis超过 1 年前

10 条评论

smokel超过 1 年前

I agree with the sentiment in the article, but I don't think there is much actionable advice to be taken from it.Understanding what "simple" and "clean" is, requires years of experience. A junior might get caught up in DRY or test-driven principles which do more harm than good.There are tons of blog posts out there that suggest that something is clean and simple, when it not so obviously is not. Take the entire frontend fiasco with HTML, CSS, and JavaScript. How can one go for the simplest architecture in that morass of historically accumulated complexity?

评论 #39292600 未加载

fumeux_fume超过 1 年前

I could be off here, but in my experience developing machine learning solutions, requirements come down from management and PMs. As a developer, I certainly love the idea of not over-engineering a solution, but if the boss wants a feature that requires complexity, there isn't a whole lot I can do. However, I read a lot of code for a living and it never ceases to amaze me how many developers immediately start building complex Python classes before understanding or creating a design for what they're doing.

proc0超过 1 年前

> Over-engineering is an attempt to predict the future, while quality-engineering is maximizing extensibility.That's not really over-engineering, but rather building incorrect abstractions or building at the wrong abstraction level.In other words, it becomes over-engineering because a lot of effort is spent on an incorrect abstraction that is not general or flexible enough. That said, if you don't have time for a proper abstraction, then it is better to do as suggested and keep things as simple as possible, however that also has its downsides because it often leads to re-doing the work once you find out about more requirements.Good abstractions don't require predicting the future, they require "covering" the feature space in such a way that small changes to the "moving parts" will drastically change the behavior of the feature. So it's about creating a solution that is flexible and also powerful, with the trade-off being the transparency of the implementation, which might be difficult for junior engineers and/or managers to understand.I think when done right, you spend a little more time upfront designing but end up with a resilient, flexible, and powerful solution that can pivot quickly for the customer. Unfortunately, and also understandably, this is not a favorable approach in many companies because it is hard to manage and estimate properly.

Zababa超过 1 年前

> Over-engineering is an attempt to predict the future, while quality-engineering is maximizing extensibility.The article is written as if extensibility is switching databases, but I've also encountered cases where extensibility is adding features, and all the indirection due to abstractions around databases, configuration, caching, view layer, etc makes it harder to extend.There's also the classic failure mode of "designing an interface but using only one implementation", which can lead to its friend "the read-and-write interface is leaky and we can't switch data stores!".And since we're on this, we may also talk about the "every service in this company uses MySQL and Spring Boot but for this small one I chose to use SQLite and Go and now we are in Hell".

评论 #39300938 未加载

chacham15超过 1 年前

The main problem that I see in my years of experience is: "how well does what I design hold up to ACTUAL product design changes?"Everything else comes second to that including this authors version of "build extensible systems around dependencies, this allows you to shift dependencies without shifting internal logic." That idea is good as long as you dont end up rebuilding an entire framework out of that extensible system, otherwise you shouldve used an existing one. If you have an extensible system, but dont use it, thats a lot of complexity that increases the maintenance burden.All of these tradeoffs make sense in their appropriate circumstances, but those circumstances largely rely on predicting the future of the product IMO.

jurschreuder超过 1 年前

SQLite and Containerize is like 20 minutes to do.Saving as raw json seems more like over-engineering to me because you'll basically end up building a custom database from scratch if it grows.

评论 #39295360 未加载

leetrout超过 1 年前

This is like a "water is wet" post for me. Maybe it is because I have been doing this so long... maybe for another reason. But people need to hear it.The important part is buried at the bottom and I'll re-summarize in less words:Start with high code quality standards [with proficient, experienced devs] delivering the minimal amount of functionality to ship.Then rinse and repeat.With experience comes a developed taste for the general work of software development and a better discernment for where to draw the lines. How to decouple and how to recognize when the decoupling is wrong and refactor. And how to refactor appropriately without making up fear based excuses.If you are interested in more checkout "A Philosophy of Software Design" by Ousterhout, "Righting Software" by Löwy and "Mythical Man Month" by Brooks.

mediumsmart超过 1 年前

A simple to-do app would be great even if it came with hundreds of thousands of lines of complicated code.

coolThingsFirst超过 1 年前

What does virtualizing the list if it gets too long refer to?

nerdponx超过 1 年前

The article is confused and self-contradictory. It advises:<pre><code> 1. Punt on complexity 2. Plan for changing requirements </code></pre> Planning for changing requirements often introduces more complexity than not planning. That's the essence of the much-loved YAGNI and WET principles.The article seems to imply that using a frontend web framework, SQLite, and an ORM both introduce complexity and fail to accommodate changing requirements, and that this was the result of the programmer's inability to complete their project both within deadline and up to high standard.I'm not aware of any world in which this is true. Web frameworks, SQLite, and ORMs are flexible tools that encapsulate a lot of complexity. Their entire purpose is to make apps less complicated, by allowing you to reuse existing functionality, abstractions, and interfaces that the app dev does not need to develop, test, and maintain.> You start typing faster, but you also start skipping clean coding patterns. Your functions become more coupled, you directly call external libraries all over, and you skip writing any unit tests. Along the way you also cut and modify scope all over the place, hacking your initial spec to pieces.The article author then says:> I firmly believe writing clean code is just as fast as writing messy code - though it may take more experience and wisdom. Quality software is soft - easy to remold. Let’s take another look at our to-do list from earlier, but implement it a little more cleanly this time, and make it more malleable.But that's clearly not the case. Otherwise the developer in the story wouldn't have felt the need to cut corners on clean code in order to get a working product delivered on time!> initially implement the entire datastore as a JSON blob written to disk.That's clean? That's punting on complexity? Is that really the reason that the developer didn't meet their deadline? Have fun with all the DIY tooling and testing around that system.Yay, we anticipated one particular direction of growth. Now just as you're finishing migrating the entire storage backend to the JSON blob thing, the same PM shows up and tells you that the UX team is pissed off at how slow sorting and filtering got in the new version. Can you make it as fast as the old one? Oops, you blew it.Meanwhile if you had just stuck with the ORM, you could have migrated your storage backend from SQLite to MySQL and kept the rest of the app more or less identical.> You’ve just saved yourself a day of fiddling with a database and reading docs on an ORM someone else built.That's just nonsense. Don't pick new-to-you tools for short-turnaround projects. If you must do so, then you have either have unrealistic deadlines or are unqualified for your particular job.You could of course forego the ORM and write raw SQL strings. Does that solve anything here? No. Does it somehow make your code cleaner? No. Does it make the process of writing clean code faster? No. Does it make the author happy? Apparently, but that's not relevant at my job.The reason that writing clean code is (sometimes) slower is that writing clean code requires planning. People have this weird idea that planning is not agile and agile is not planning, so people don't plan out their code. A similar topic came up in a thread the other day about Dijkstra, but it bears repeating here. Your design process does not end once you've chosen your tools and drawn a couple of arrows on a cocktail napkin. Do you have at least a rough idea of what interface boundaries will be needed? What is your testing strategy? Do you even know what the important invariants of your system are, or which pieces of functionality might need to be tested? Do you need to implement any "algorithms" that can be implemented as pure functions? How do you intend to represent the data? Does that representation work well with your chosen storage backend, or will you need to do some kind of transformation between the database and the app? Etc.All that stuff is a whole lot more important than fussing over whether you've spent too much time reading library documentation. You can write just as much of a spaghetti platter mess with or without 3rd-party libraries.The article is not providing any useful advice for avoiding the spaghetti platter. It only asserts that a tangled linguine platter is better than a tangled spaghetti platter.