Как сохранить мой код простым? [закрытый]

На тему KISS:

1 Не думайте, что вы должны исправить все крошечные ошибки / функции в вашем основном коде. Иногда лучше просто оставить их документированными и позволить парню, вызывающему ваш код, беспокоиться о том, как их обойти. (В любом случае, есть большая вероятность, что он никогда не вызовет эту конкретную ошибку, поэтому любые проверки были бы пустой тратой обработки. ) Это делает ваш код маленьким, быстрым и простым. Если вы хотите сделать надежную, но раздутую версию, закодируйте ее отдельно от (поверх) библиотечного кода ...

2) Не позволяйте этому парню изменить ваш код! Он может назвать ваш код или расширить ваш код, поэтому, если он уже выполняет свою работу, ему действительно нужно менять ядро? Не позволяйте ему превращать ваш SimpleAndSpeedySearchPage в SuperAdvancedSearchPageWithCowbell, заставляйте его создавать SuperAdvancedSearchPageWithCowbell, расширяя или вызывая ваш код.

Если ваш напарник начинает добавлять вещи по всей вашей маленькой маленькой библиотеке, сделайте рефакторинг самостоятельно. Потяните ваш хороший код в суперкласс и оставьте его только с тем, чтобы его код вызывал ваш.

Резюме: Как только ваш код выполняет свою основную работу, перестаньте работать над ним и сделайте его доступным только для чтения! Если вы хотите добавить "

Как @neodymium указывает на изумление, не позволяют вашим алгоритмам управлять кодом . Чтобы проиллюстрировать, что это на самом деле означает, рассмотрим следующее приспособление для скорби в C #, которое вы написали неделю назад:

public void DoArray(string[] strArr) {
    string s = null;

    for(int i = 0; i < strArr.Length; i++)
    {
        if(strArr[i].Equals("Needle"))
            s = strArr[i];
    }

    if(s != null)
        Console.WriteLine("I've found " + s);
}   

Может потребоваться некоторое время, чтобы узнать, что вы написали, просто взглянув на свой код. Но, в конце концов, вы помните, что этот метод ищет «иглу» в массиве строк. Вы удивляетесь, насколько гениален ваш алгоритм, но беспокоитесь о том, что вам потребовалась минута или две, чтобы понять, что он делал.

Не начинайте прояснять ситуацию, комментируя!

Ваш первый инстинкт может заключаться в том, чтобы пишите комментарии, чтобы помочь своим коллегам по работе, , НО ОСТАНОВИТЕСЬ ПРЯМО ТАМ! Комментарии - это всего лишь извинение . Вместо этого давайте проясним себя в коде… кристально ясно .

Чтобы сделать это, постарайтесь думать так, как будто вы никогда раньше не видели свой собственный код. Вынудите это, сказав себе такие вещи, как: «что это» и «почему это». И тогда мы начнем рефакторинг вещи. Первый простой рефакторинг, который мы можем сделать, это переименовать метод во что-то более подходящее. Как насчет:

public void FindNeedle(string[] strArr) { … }

Что еще мы можем сделать? Мы могли бы:

• Переименовать strArr в нечто более подходящее, например стог сена .
• Измените тип возвращаемого значения на bool и измените метод так, чтобы он вернемся, когда игла будет найдена.
• Переместите часть Console.WriteLine (…) метода вне контекста этого метода, чтобы вызывающий код мог сделать это вместо этого следующим образом: if (FindNeedle (myArray)) WriteFoundNeedle ();
• Использовать foreach вместо для .

Код может закончиться следующим образом (ваш пробег может отличаться ):

public bool HasNeedle(string[] haystack) {
    foreach(string straw in haystack)
    {
        if(straw.Equals("Needle"))
            return true;
    }
    return false;
}

// Is called by the following:
if ( HasNeedle(strArr) )
{
    Console.WriteLine("I've found the needle!");
}

Рефакторинг небольшими шагами

Многое можно сделать, чтобы сделать ваш код более понятным, понятным и читаемым, и это достигается путем рефакторинга вашего кода. Делайте ваши рефакторинги как можно меньшими шагами. Например, перемещение или инкапсуляция логики и присвоение им имен в более логичных и понятных местах. Что-то столь же простое, как длинное и замысловатое выражение if:

if ( strArr[pos - 1].Equals("do") && strArr[pos + 1].Equals("then") )

… может быть преобразовано в нечто более простое, если переместить логическое утверждение в его собственный метод :

if ( CurrentIsSurroundedByDoThen(strArr, pos) )

Существует множество способов рефакторинга. Я предлагаю вам прочитать некоторые из них, Мартин Фаулер написал об этом книгу, но есть также онлайн-каталог с примерами кода и / или диаграммами классов . Выбор того, какой рефакторинг вы должны делать или нет, должен быть решен в предположении, что он сделает ваш код более поддерживаемым , чем раньше.

В приложении

Не забывайте, что ваши рефакторинги просты ] и сделайте это с принципами SOLID .

Также, если вы начнете свой проект с написания модульных тестов правильным способом , то рефакторинг станет чем-то более естественным. Чем больше вы сделаете рефакторинг, тем яснее станет ваш код.

В приложении

Не забывайте, что ваши рефакторинги просты ] и сделайте это с принципами SOLID .

Также, если вы начнете свой проект с написания модульных тестов правильным способом , то рефакторинг станет чем-то более естественным. Чем больше вы сделаете рефакторинг, тем яснее станет ваш код.

В приложении

Не забывайте, что ваши рефакторинги просты ] и сделайте это с принципами SOLID .

Также, если вы начнете свой проект с написания модульных тестов правильным способом , то рефакторинг станет чем-то более естественным. Чем больше вы сделаете рефакторинг, тем яснее станет ваш код.

Как сделать код простым?

Использовать код для реализации правильных алгоритмов.

Не позволяйте вашим алгоритмам писать код.

For me, Test Driven Development makes all the difference. When I write code without a test justifying it, I think of way too many scenarios, worry if the code will work, write tons of extra stuff to make sure that it will work, etc.

When I do TDD, the code comes out very simple because the tests made me write the right code, I wasn't as defensive, and yet I'm confident that it meets all the requirements because the tests pass.

Another thing which I find helps is to inspect the code of open source projects. Many of them have code which is easy for others to understand and modify, so it gives good insight into how to achieve that. One of my favorites in the that regard is JMock.

Рефакторинг часто.

Это единственный надежный способ сделать мой код простым. Иногда вы не можете найти выход из сложности, не начав сначала работать над кодом.

Более или менее проверяемый модуль означает, что он не проверяется модулем. :)

Если вы не можете легко написать тест, не перепрыгивая через большое количество обручей или работы по настройке, то это может показаться проблемой, IMO, и требует рефакторинга.

Я пытаюсь выполнить три принципы: Сделай так, чтобы это работало Сделать это правильно Make it fast.

The first is just to get it working, mostly unit testable. :)

Then I refactor and improve the unit tests, complete them. This is the next step you should go to, as it sounds like you may be ignoring this concept. Also, try to remove any hard-coded values to make it more flexible. Put them in xml files, database or as constants in some common file.

Then, I profile and optimize the bottlenecks.

You may want to look at xetreme programming (XP) and understand the concept of implementing only the features that are needed, not trying to implement what you think is needed. It should simplify the code.

I think that is a common problem. We all try to create elegant code and clean code, and sometimes we end up doing quick and dirty because we are under pressure and time and budgets are not infinite.

I try to follow DRY and KISS. "Don't Repeat Yourself" and "Keep It Simple Stupid". I also follow the "one thing" rule. A method, class, namespace, should only ever do one thing.

To be honest, I've tried doing a project from the test driven development point-of-view, and I found it really hard to get in that mind set, of you Red, Green, Refactor, but it really helped break old habits.

I've been a victim of tight coupling and had to rip things out into their own components, it was brutal and broke the application, but you can get caught up.

This is really a vague question, I agree, community wiki!

p.s. I don't believe something is more or less, it is either is, or it isn't

Я обычно пишу эту цитату в уме.

Бритва Оккама Самое простое (объяснение | решение), как правило, лучшее.

Я бы посоветовал вам опубликовать некоторые из них. вашего кода и попросить критику и комментарии. Вы можете многому научиться у других людей. Попробуй :):

off the top my head: Build time into your schedule to refactor. Make refactoring part of the requirements to ship, not just an after-thought.

This would be based on wanting to deliver a product that is more maintainable, re-usable, and so future developers on it don't freak out and have to hack.

I really think the answer is making refactoring a bigger part of your life, and being disciplined about it. (I need to this as well! Similar problems...I think most of us are in this boat.)

Вы можете часто запускать показатели сложности, решать, каков ваш верхний предел сложности, и реорганизовывать, когда вы превышаете этот предел. Метрики сложности объективны. Они дают вам возможность количественно оценить, насколько сложным является ваше программное обеспечение, и способ измерения прогресса. Может быть, вы бьетесь над кодом, который довольно хорош. Или, может быть, код, который вы считаете простым баллом по метрике сложности.

Я знаю, что эти показатели грубые. Что действительно важно, так это субъективный психологический опыт сложности, а не число сложности МакКейба, и последнее является грубым приближением к первому. С другой стороны, я нашел эти метрики очень полезными.

Добавляйте только то, что необходимо - не рассчитывайте на будущее - реагируйте только на реальные проблемы

Один из самых простых и моих любимых - это ввести объясняющие переменные .

Это:

if ( (platform.toUpperCase().indexOf("MAC") > -1) &&
      (browser.toUpperCase().indexOf("IE") > -1) &&
       wasInitialized() && resize > 0 )
 {
   // do something
 }

Превратится в:

final boolean isMacOs     = platform.toUpperCase().indexOf("MAC") > -1;
final boolean isIEBrowser = browser.toUpperCase().indexOf("IE")  > -1;
final boolean wasResized  = resize > 0;

if (isMacOs && isIEBrowser && wasInitialized() && wasResized)
{
    // do something
}

На ум приходят несколько вещей:

1. Попытайтесь заранее спланировать свою стратегию реализации - возможно, на бумаге или при обсуждении с коллегой, прежде чем погрузиться в реализацию. Скорее всего, уже есть библиотечные функции, доступные для решения частей вашей проблемы.
2. Запишите псевдокод, описывающий шаги вашей реализации.
3. Попробуйте реализовать методы так, чтобы каждый метод имел единственную цель, или связывает воедино другие методы. Должна быть возможность сразу увидеть, что должен делать любой метод. Именно здесь TDD может помочь вам сосредоточиться на небольших методах, которые легче проверить. У более мелких методов также есть определенные имена, поэтому название уже говорит вам о многом. Также несколько простых показателей сложности, как и вопрос из , этот вопрос может помочь вам определить, пытаются ли ваши методы сделать слишком много.
4. Не останавливайтесь, когда ваша реализация работает - попробуйте провести рефакторинг, пока он не станет настолько простым, насколько это возможно. Всегда спрашивайте себя, если бы кто-то другой читал это, понял бы он это?