Программирование, как и жизнь, состоит из известного и неизвестного. Для любой постановки задачи существуют компоненты, которые необходимо идентифицировать.
Программирование очень похоже на то, как мы решаем задачи в реальной жизни. Одним из навыков, который также помогает программистам, является эффективное делегирование.
Когда я сталкиваюсь с проблемой (программирование или что-то другое), я предлагаю начать с общей идеи, прежде чем приступать к решению, и использовать делегирование для продолжения. Не имея широкого (теперь это может быть субъективного) представления, начинать кодить — грех. Взгляните на цель, которую нужно достичь, без цели код будет тарабарщиной и потребует нескольких итераций.
Как только цель определена, определите известное и неизвестное. Может быть, под известные области попадает бизнес-логика или алгоритм, а может быть, известны входные данные. Может возникнуть неоднозначность в отношении интеграции или того, как изменение повлияет на другие службы.
Имейте четкую стратегию выполнения известного. Здесь должны помочь ваши дизайнерские навыки и ООП, поскольку этот код тоже изменится.
Никакой написанный код не вечен, кому-то в будущем нужно будет внести изменения, сделать свою жизнь проще сегодня, написав понятный код (понятный для людей). Если код не может быть понят машиной, я сомневаюсь, что он увидит свет.
При кодировании следуйте искусству делегирования. Для неизвестных создайте функции или методы, которые позаботятся о делегированной части. Например, предположим, что в настоящее время мы не знаем, где конкретное поле будет находиться в базе данных, создадим функцию, которая должна предоставить это поле, и приступим к решению. Нам придется вернуться, чтобы решить эту проблему, но к тому времени постановка задачи будет индивидуализирована. Заставьте эту функцию выдавать исключение, если вы думаете, что создаете слишком много функций и не забываете заполнять их обратно.
Я предлагаю разбить формулировку проблемы на управляемые части, известные и дополнительные части неизвестных. В больших постановках задач когнитивно сложно понять и предсказать все пути.
Например, допустим, вы работаете над постановкой задачи. Этот оператор имеет бизнес-логику, ему нужно читать данные из какой-то системы и записывать выходные данные в какую-то систему.
Предполагая, что бизнес-логика может быть написана правильно, мы можем делать предположения о входных данных. С помощью адаптера мы можем преобразовать ввод в формат, который понимает бизнес-логика. Это отделяет логику от строгости типа данных ввода, а также делает функции читабельными. Создавая функции, которые выполняют конкретную единицу работы, код становится модульным и управляемым. После того, как это будет сделано, входы могут быть связаны по одному за раз.
Как и в жизни, нет ничего без затрат, и вышеупомянутое делегирование также имеет свою цену. Это может добавить некоторые затраты на рефакторинг, когда могут быть функции, выполняющие работу, которую можно легко абстрагировать, или аналогичные другие подобные затраты.
Как вы программируете, когда сталкиваетесь с постановкой задачи? И да, проблема должна иметь неизвестные области.
