Наиболее эффективный способ решения открытых проблем в программировании

Question

Я программирую на C ++. Иногда есть 1000 способов сделать что-то, и в зависимости от вдохновения / энергии и т. Д. На данный момент я могу выбрать «правильный» или нет, и потратить 10 минут или три дня, чтобы решить проблему, найти решение или сделать задание для босса.

Когда вы программируете, как вы справляетесь с этими «открытыми» ситуациями? Используй свою интуицию? Предпочитаете много планировать раньше?

Большое спасибо

Answer 1

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

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

Теперь проверьте, достаточно ли чист код. Большую часть времени это не так. В этом случае выполняйте рефакторинг до тех пор, пока он не станет чистым.

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

Хорошо, я должен признать, это по крайней мере, как я пытаюсь написать свой код.

Выбор решения с помощью тестируемости в качестве побочного эффекта предпочитает хорошо разработанные решения.

Answer 2

Постарайтесь максимально увеличить объем работы, не выполненной.

Для открытой проблемы я просто создаю минимальный код, который отражает мою известную на данный момент информацию.

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

Answer 3

заставить его работать; сделать это правильно; сделать это просто.

Или уточнить:

1. Создайте простейшую вещь, которая может иметь отношение к решению.
2. Уточните, чтобы оно соответствовало требованиям. Разрабатывать и накапливать юнит-тесты; когда все тесты запущены, ваш проект завершен.
3. Нет, подожди! Это не будет сделано до тех пор, пока код не станет настолько простым, что у него явно не будет ошибок Если код настолько сложен, что в нем нет явных ошибок, вы не верны своему ремеслу.

Answer 4

Я бы:

1. Напишите модульный тест, который проверяет ожидаемое решение проблемы
2. Реализация первого алгоритма, который приходит на ум
3. Рефакторинг и повтор

Это особенно хорошо работает для проблемы, которую вы атакуете впервые. Если вы обеспокоены тем, что ваш босс скажет «остановитесь» после пункта 2, просто сделайте несколько итераций, прежде чем говорить с ним / ней ...

Answer 5

Хммм, я предпочитаю отвечать не простым текстом, а сегментом кода .Net;)
Я думаю, что для C ++ Dev легко понять следующее:

SolutionRefining()
{
    result= Requirements.Brianstorming(Current_Experience_Knowledge);
    if(!result.Equals("Its Time To Design and Code"))//Assuming analysis is already done!
    {
        do
        {
            this.TakeRest_Break_HaveFun();//Multi-Processes OS ;)
            result = QuickResearchSession(searchEngine Google, softwareCommunity StackOverflow, inHouseGuru Anonymous);
        }
        while(!result.Equals("Its Time To Design and Code"));
    }
    else
    {
        while(Testing().MajorBugs >= 1 && !Coding().Finished)
            Develop().Review_UnitTesting().Commit();//artificial .NET! Don't try it in VS 2010.

        SubmitProject().GetMoney().GetLaid();
        WakeUp().GoToWork().BeReadyForNewFeaturesAttack();
    }


    MeanWhile (!Solution.Equals("Standard & Best Practice")) //MeanWhile can be found in .NET Framework 11.7301 Beta RC.45

    {
                    //this method shall always invoked during the developer journey in the Software Life Cycle.
        Study("Design Patterns").Understand().UnderstandMore().Apply();
        UpdateTheToolKit();
        SearchFor("Standard & Best Practice").Consume();
    }

    finally("Write your own A-Z framework").GetRetired();
}

Answer 6

Тестируемость - это отличная вещь.

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

В духе DDD это будет означатьПрактически естественное описание вашей задачи переведено на язык программирования.

Answer 7

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

Затем, через шесть месяцев, я реорганизую его, чтобы применить лучший шаблон, который кто-то другой использовал в аналогичной ситуации.

Затем, через двенадцать месяцев, я излагаю все эти чертовы вещи и заменяю их пятью строками кода.