Лучший способ разбить подавляющий код на управляемые куски?


13

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

Я очень хорошо справился с рефакторингом из-за моей слабости. И я всегда стараюсь разложить мои объекты на более мелкие, более управляемые. Эта слабость также, вероятно, побудила меня уделять слишком много внимания правильному проектированию вещей.

Я знаю, что если я смогу разбить свои проблемы на более мелкие, я смогу справиться без проблем. Одна из стратегий, которая приходит на ум, - это разработка через тестирование. Что еще я могу сделать?


2
«Я всегда стараюсь разложить свои объекты на более мелкие, более управляемые» и «Я знаю, что если я смогу разбить свои проблемы на более мелкие, я смогу их решить плавно», то ваш вопрос будет немного риторическим.
Морган Херлокер

2
Читайте Рефакторинг (Фаулер) и Шаблоны проектирования (GoF) . Этот вопрос действительно задает вопрос «Как мне структурировать код?» и если вы спрашиваете об этом, вам предстоит долгий путь; не полагайтесь на одну ветку вопросов и ответов, чтобы дать вам хотя бы половину.
Ааронаут

Ответы:


13

перестань думать о коде

начать думать о слоях, функциях, модулях, сервисах и других высокоуровневых абстракциях

вы перегружены, потому что вы думаете на слишком низком уровне


9

Сделать комплекс простым - легко ; подождите, думаю, что все наоборот.

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

Поскольку вы не указали это в своих вопросах, я бы предложил:

Фокус на функциональной сплоченности посредством:

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

Если вы найдете его в результатах поиска на первой странице, вы найдете два замечательных ресурса:

  • « Принцип единой ответственности » Роберта К. Мартина (февраль 2002 г.). Этот принцип обсуждает необходимость размещения вещей, которые по разным причинам изменяются, в разных классах.
  • « Закон Керли: делай одно » Джеффа Этвуда (март 2007 г.): принцип единой ответственности гласит, что у класса должна быть одна и только одна причина для изменения.

Что такое сплоченность в информатике?

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

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

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

Если у вас есть какие-либо вопросы, дайте мне знать.


1

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


1

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


0

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

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


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

1
+1 @ Mouth of a Cow: согласен, как и Питер Норвиг , директор по исследованиям Google, который является «отличным» программистом: научи себя программированию за десять лет
промахи

1
@blunders - хорошая статья. Это маленький грязный секрет, который маркетологи не хотят нам рассказывать (кроме, конечно, Sega). Практика, практика, практика. Предположительно это работает и для японцев alljapaneseallthetime.com/blog

У меня был сотрудник, который пришел к выводу, что некоторые разработчики «слепы в дизайне» и не могут проектировать большие, аккуратные управляемые системы. Если вы слепой дизайн, вам ничего не поможет. Книга GOF Design Patterns может помочь программисту, который никогда не видел хорошего дизайна, но написал много кода.
Тим Виллискрофт

0

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

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

Многие программисты, на мой взгляд, не понимают этого, и я не знаю ни одной книги, в которой это было бы понятно.

Еще одна вещь, которая, безусловно, помогает, это TDD, которая позволяет вам понять, «как» вы будете использовать класс на практике, и во многих случаях может спасти день, потому что он показывает возможные проблемы / ограничения в начале дня.

Наконец, еще одна ОЧЕНЬ важная вещь, которую я бы искал, если бы я был вами, это шаблоны проектирования. Шаблоны проектирования - это то, как люди умнее вас или меня решают задачи программирования. Идея, лежащая в основе шаблонов, угадайте, что ?, заключается в том, что они не должны использоваться в качестве кулинарных книг, рецептов, которые вы просто подбрасываете, но вдумчиво и в первую очередь понимаете сферу применения.

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

Хорошая библиотека шаблонов дизайна, созданная с учетом ваших потребностей, окажется бесценной. Давайте посмотрим на очень простой пример, чтобы поместить вещи в контекст:

представьте, что у вас есть форма, в которой при нажатии кнопки другие формы должны обновляться. Это типичная схема «наблюдателя». У вас есть субъект и несколько наблюдателей, которые регистрируют себя вместе с субъектом. Зачем вам нужно реализовать интерфейс? Вы можете просто добавить методы или, что еще лучше, использовать интерфейс для наблюдателей и общий список для предмета. Теперь вы получили лучшее из обоих миров: независимость для наблюдателей и никаких сумасшедших вещей на эту тему.

Надеюсь, это имеет смысл для вас!

Andrea


Между прочим, просто чтобы прояснить: я не защищаю дикие классы, растущие как гремлины, а просто немного более практичный смысл :)
Андреа Раймонди

0

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

Несколько простых шагов, которые помогли мне

  • Используйте анализатор сходства (например, Simian), чтобы найти повторяющиеся блоки кода в базе кода. Много повторяющегося кода означает меньше абстракции.
  • Контролируйте размер классов и методов, большие классы и методы означают, что немногие сервисы или контролеры становятся богами.
  • Сделайте модульные / интеграционные тесты обязательными, дает вам уверенность в рефакторинге, а также действует как спецификация.
  • Раз в две недели ретроспективно выясняйте, отражаются ли используемые ими технические / бизнес-термины / доменные термины в именах классов. Это помогает понять и получить имена для первоклассных коллекций, а не представлять их как простые наборы и списки. Некоторые абстракции, о которых мы никогда не думали, также всплывают, когда мы садимся с деловыми людьми.

это то, что я тоже защищаю. Я думаю, что между абстракцией и специализацией должен быть баланс: слишком много специализации так же плохо, как и слишком много абстракции.
Андреа Раймонди
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.