最佳实践 - 设计编码之前 [英] Best Practices - Design before coding

问题描述

我很好奇你怎么让人觉得？ （我的意思是一种思维方式）有关图书馆的设计架构，系统，框架等启动前对其进行编码。

I'm curious How do you people think ? (I mean a way of thinking) about design architecture of your Libraries, Systems, Frameworks, etc. before start coding it.

最近，我发现我的自我感觉疼痛，我做了什么，切实我想一切从头开始，每次..

I recently find my self feeling pain in what I've done, and practically every time I want to start everything from scratch..

我做设计之前，在纸上画一些计划和想象它将如何工作的，但也许我做了错误的方式？

I do design before, painting some schemes on the paper and imagine how it will work, but maybe I do it in a wrong way ?

例如你如何决定哪些接口，你需要，或如何一切都将在一个最好的方式进行连接？

For example how do you decide what Interfaces you will need, or how everything will be connected in a best way ?

（我有一天前有一个问题，我的朋友问我什么，我前一段时间做了一个库，并且而不是让他只有一个文件，我只好给他约3-4文件，这是因为他们以某种方式连接..但不是那个合适的人，我认为:)所以这是我的设计错误。）

(I had a problem some day ago, my friend asked me a library what I've done some time ago, and instead of giving him just one file, I had to give him about 3-4 files, and that's because they're connected in some way.. but not in the right one I think :) so it was my mistake in design..)

推荐答案

我通常做的问题域对纸/白板足够的分析，以获得问题领域的一个好足够的了解开始写code。我在纸上画很少实现或类图。我发现，以达到更好的设计的关键技术是不是太执着于你写的code。如果我不喜欢它，我删除，重命名，移动，直到它的前presses一个足够好的解决什么，我试图解决围绕它洗。听起来很简单？一点也不！但具有良好的编码工具，竟写code是不是主要工作。写一些，重构，删除，再写......

I usually do enough analysis of the problem domain on paper/white board to get a good enough understanding of the problem domain to start writing code. I rarely draw implementation or class diagrams on paper. A key technique I've found to achieve better design is to not get too attached to the code you write. If I don't like it, I delete, rename, move and shuffle it around until it expresses a good enough solution to what I'm trying to solve. Sounds easy? Not at all! But with good "coding" tools, actually writing the code is not the major effort. Write some, refactor, delete, write again...

良好的设计几乎从未开出不错。 它演化为好。接受这使得它更容易在小步骤工作，没有感到沮丧，为什么设计是不是完美。为了让此过程顺利进行，你必须虽然posses良好的设计技巧。问题的关键是，即使是优秀的设计师没有得到正确的第一次。

Good design almost never start out good. It evolves to good. Accepting this makes it easier to work in small steps without getting frustrated why the design isn't "perfect". In order for this process to work you have to posses good design skills though. The point being, even excellent designers don't get it right the first time.

很多时候，我以为我的理解问题域，当我开始，但我没有。然后，我回到白板，跟某人或问题域读了，如果我知道我不明白它不够好。然后，我回到code。

Many times, I thought I understood the problem domain when I started, but I didn't. I then go back to the white board, talk to someone or read up on the problem domain if I realize I don't understand it well enough. I then go back to the code.

这是一个非常反复的过程。

It is a very iterative processes.

一个有趣的问题与程序员是怎么想的，是他们如何开发他们的思维方式打交道时问。就个人而言，我的思维方式已经发展了很多年，但有几个事件对我开发软件的方式产生深远的影响。其中最重要的已经设计的人谁是专家设计的软件。没有什么影响了我更多的不是与伟大的设计师花费迭代。有，而且还做的另一项活动，影响我的思考方式会回去看看软件我写了一段时间回来。

An interesting question to ask when dealing with how programmers think, is how they developed their way of thinking. Personally, my way of thinking has evolved over the years, but a few events have had profound influence on the way I develop software. The most important among them have been to design software with people who are expert designers. Nothing has influenced me more than spending iterations with great designers. Another event that has, and still do, affect the way I think is going back and look at software I wrote some time back.

这篇关于最佳实践 - 设计编码之前的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！