Как нарисовать тигра всего за 3 линии?

Question

Фон :

Однажды учитель рисования поставил мне задачу нарисовать тигра, используя только 3 линии. Идея в том, что я изучаю тигра и изучаю 3 линии, чтобы люди могли понять, что это тигр.

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

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

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

Вопрос

Существует ли установленный процесс удаления сложности в программных системах - своего рода шаблон процесса сокращения, который будет применен к проблеме?

Answer 1

Проверьте книгу Рефакторинг Мартина Фаулера и его http://www.refactoring.com/ веб-сайт.

Роберт С. Мартин Чистый код - еще один хороший ресурс для уменьшения сложности кода.

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

Answer 2

Ознакомьтесь с книгой Анти-паттерны для хорошо написанной книги на тему перехода от плохого (или неадекватного) дизайна к лучшему Он предоставляет способы восстановления от целого ряда проблем, обычно встречающихся в программных системах. Затем я бы добавил поддержку рекомендации Кристофера о Рефакторинг в качестве важного второго шага.

Answer 3

Оформить заказ, Эффективно работать с устаревшим кодом

Темы включают в себя

• Понимание механизма изменения программного обеспечения: добавление функций, исправление ошибок, улучшение дизайна, оптимизация производительности
• Загрузка устаревшего кода в тестовый комплект
• Написание тестов, защищающих вас от новых проблем
• Методы, которые можно использовать с любым языком или платформой - с примерами на Java, C ++, C и C #
• Точная идентификация того, где необходимо внести изменения в код
• Как справиться с устаревшими системами, которые не являются объектно-ориентированными
• Обработка приложений, которые не имеют какой-либо структуры

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

Answer 4

Несмотря на интеллектуальную стимуляцию, концепция удаления деталей не очень хорошо (по крайней мере, как есть) для программ. Причина в том, что чертеж переоценивается человеком с его способностью принимать нечеткие входные данные, в результате чего программа переоценивается процессором, который очень плохо "заполняет пробелы". Другая, более тонкая причина заключается в том, что программы передают пространственно-временной рассказ, тогда как рисунок по существу является пространственным.

Следовательно, с программным обеспечением гораздо меньше места для аппроксимации и прямого удаления отдельных частей кода. Тем не менее, рефакторинг - это ключевое слово для работы, которое иногда применимо даже для самых неудобных унаследованных компонентов. Эта дисциплина, однако, является частью искусства, а не наукой, и в ней не так много «быстрых трюков», о которых я знаю.

Редактировать : Однако никто не является совершенно беспомощным против устаревшего кода. Посмотрите, например, отличные ссылки на книги, приведенные в ответах Алекса Бараноски и Кристофера Джонсона. Эти книги предоставляют много полезных приемов, но в целом я по-прежнему силен в своем утверждении, что рефакторинг нетривиального унаследованного кода - это итеративный процесс, требующий как искусства, так и науки (а также терпения, безжалостности и мягкости ;-)).

Answer 5

Это загруженный вопрос: -)

Во-первых, как мы измеряем «сложность»? Без какой-либо метрики, решаемой априори, может быть трудно оправдать какой-либо «редукционный» проект.

Во-вторых, выбор полностью за вами? Если мы можем взять пример, предположим, что в некоторой кодовой базе молоток «наследования» используется для решения любой другой проблемы. Хотя использование наследования является совершенно правильным для некоторых случаев, оно может быть не правильным для всех случаев. Что ты в таких случаях?

В-третьих, можно ли доказать, что поведение / функциональность программы не изменились из-за рефакторинга? (Это становится более сложным, когда код является частью продукта доставки.)

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

Наконец, по моему скромному мнению, я думаю, что любой такой проект по рефакторингу - это скорее проблема людей, чем технологий. Все программисты хотят писать хороший код, но восприятие хорошего и плохого очень субъективно и варьируется у разных членов одной команды. Я бы предложил создать для проекта «соглашение о разработке» (что-то вроде C ++ Coding Standards ). Если вы можете достичь этого, вы в основном сделали. Оставшаяся часть изменяет части кода, которые не соответствуют соглашению о разработке . (Я знаю, это очень легко сказать, но очень трудно сделать. С наилучшими пожеланиями.)