Как справиться со случайной сложностью в программных проектах

74

Когда Мюррея Гелл-Манна спросили, как Ричарду Фейнману удалось решить так много сложных проблем, Гелл-Манн ответил, что у Фейнмана есть алгоритм:

  1. Запишите проблему.
  2. Думай очень усердно.
  3. Запишите решение.

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

Так является ли алгоритм Фейнмана единственным способом управления случайной сложностью, или существуют ли реальные методы, которые инженеры-программисты могут последовательно применять для устранения случайной сложности?

davidk01
источник
32
Я не удивлюсь, если сам процесс записи проблемы (и ее конкретизации, чтобы вы могли адекватно объяснить ее кому-то еще) помог вам найти решение.
Рори Хантер
@RoryHunter - Согласен. А часть записи проблемы и обмена ею с кем-то означает, что вы признаете, что у вас еще нет решения.
JeffO
38
@RoryHunter: это. Почти еженедельно я сталкиваюсь с проблемой, которую не могу решить, пишу кому-нибудь письмо, чтобы объяснить. Затем поймите, что я не рассматриваю, решите проблему и удалите письмо. Я также написал около десятка вопросов на этом сайте, которые так и не были отправлены.
PDR
Самая фундаментальная вещь, которую я узнал, - не просить разработчика решить проблему, которая находится в пределах их досягаемости. В то время как эти проблемы волнуют, они также вовлекают разработчика в незнакомые места, что приводит к значительному росту «на лету». Некоторые инструменты, такие как спиральная разработка, хороши для того, чтобы подготовить группы разработчиков к решению небольшой проблемы, прежде чем превратить ее в окончательное решение
Cort Ammon
2
@CortAmmon Не значит быть злым, но это звучит довольно глупо. 99% того, что знают разработчики, узнали в какой-то момент благодаря так называемому «росту на лету». Требуется хороший решатель проблем, чтобы стать хорошим программистом. Решение проблем - это то, к чему мы изначально стремимся. Если ваши разработчики не растут, они, вероятно, делают много скучной повторяющейся работы. Тип работы, который сделает любого достаточно талантливого разработчика несчастным и подавленным. И ... «Спиральная разработка» - это не что иное, как переосмысление базовой концепции итеративной разработки с вехами водопада.
Эван Плейс,

Ответы:

104

Когда вы видите хороший ход, ищите лучший.
Эмануэль Ласкер, 27-летний чемпион мира по шахматам

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

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

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

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

Карл Билефельдт
источник
1
Ааа, но вы, кажется, смогли написать четкий ответ на этот вопрос с первой попытки. (И при этом очень убедительный.) Может быть, вы просто замаскированный Фейнман.
kmote
1
ТЛ; др; рефакторинг, не бойся.
ocodo
1
+1 за охват несовершенства. Человек, это то, о чем все говорят , но мало кто. Я пытаюсь перестроить свой мозг, чтобы думать о себе как об алгоритме машинного обучения, где ошибки на самом деле хороши, и учить тому, как совершенствоваться. Прекрасный способ выразить это с вашей "черновой" метафорой.
Хуан Карлос Кото
46

«Навыку архитектуры программного обеспечения нельзя научить» - распространенная ошибка.

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

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

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

Килиан Фот
источник
11
Мне очень нравится твое последнее предложение. Я уверен, что многому научился на своей первой работе, потому что был там достаточно долго, чтобы мои ошибки могли меня догнать. Это ценный опыт.
MetaFight
26
«Хорошее суждение приходит из опыта. Опыт приходит из плохого суждения». - Мулла Насрудин
Йонас Кёлкер
9
Я не понимаю, как вы можете утверждать, что неспособность преподавать архитектуру программного обеспечения - заблуждение, но продолжаю говорить, что повторная практика, обучение на опыте и ошибки (в сочетании с неким врожденным талантом) - единственный способ научиться этому. , Мое определение чему-то, чему можно научить, - это то, что вам не нужно интенсивно практиковать, чтобы получить, но вы можете научиться, наблюдая, слушая и читая. Я согласен со всем в этом ответе, кроме первой строки, так как он явно противоречит остальным.
Томас Оуэнс
4
Дело в том, что многие люди утверждают, что многие абсолютно ни при каких обстоятельствах не могут научиться быть хорошими архитекторами (будь то в аудитории или в промышленности), потому что они «не получили того, что нужно». Это то, что я считаю обычным, но ложным.
Килиан Фот
5
@Thomas: Возвращаясь к аналогии с публичными выступлениями. Неважно, сколько книг вы прочитали, сколько часов вы потратили на изучение этой темы или сколько учителей пытаются научить вас хорошо выступать на публичных выступлениях, вы не сможете добиться успеха, если не будете делать это путем повторной практики, обучения на опыте и делать ошибки. Вы никогда не убедите меня в том, что кто-то может освоить навык, просто наблюдая, слушая и читая. То же самое касается большинства любых навыков, включая архитектуру программного обеспечения. Я на самом деле не могу придумать какой-либо навык из какой-либо субстанции, который вы можете изучить, просто наблюдая, слушая и читая.
Данк
22

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

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

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

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

Этот вопрос от Workplace является актуальным, и ИМХО было бы интересно прочитать в этом контексте.

superM
источник
3
Какое замечательное описание того, как думают эксперты. Это действительно не волшебство, просто трудно сформулировать все дискретные и логические шаги.
MetaFight
+1 Очень похоже на модель
Робби Ди
Это все равно, что сказать, что не «волшебно», как «элитные» атлеты могут делать то, что они делают, это просто вопрос, что они способны естественным образом выполнять дискретные и логичные шаги, необходимые для выполнения на самых высоких уровнях. Так что, если бы только эти спортсмены могли сформулировать эти дискретные и логичные шаги для нас, то мы все могли бы стать элитными спортсменами. Концепция того, что мы все можем быть элитными спортсменами, независимо от того, какой уровень знаний мы получаем, настолько же нелепа, насколько мы все можем быть экспертами в любом навыке, который мы пытаемся освоить, независимо от способностей в этой области навыков.
Данк
1
@Dunk, Волшебство было бы тогда, когда эти "элитные" атлеты могли выполнять то же самое без каких-либо тренировок вообще. Основная идея в том, что нет серебряной пули. Независимо от того, насколько талантливый человек, опыт не может быть получен, просто изучая некоторые "дискретные и логические шаги". Кстати, согласно той же книге, только 1-5% людей являются экспертами.
СуперМ
@Super: Я бы поставил под сомнение любую книгу / исследование, которое сделало такое нелепое утверждение, поскольку только 1-5% людей являются экспертами. Поговорим о том, как вытащить число из их # & # & $ #. Эксперты на что? Могу поспорить, что есть гораздо более высокий процент людей, которые являются экспертами в дыхании, ходьбе, еде. Кто решает, что такое уровень эксперта? Претензия, подобная 1-5%, дискредитирует любые дальнейшие претензии и анализ таких авторов.
Данк
4

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

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

На самом деле алгоритм Фейнмана в некоторой степени применим, но это не означает, что «мыслить по-настоящему» означает только магию, которую нельзя кодифицировать.

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

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

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

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

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

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

Сказав все это, ключевым моментом для меня является автоматизированное тестирование . Если вам этого достаточно, ваша система находится под контролем. Если нет. , ,

Кит
источник
Не могли бы вы объяснить, как автоматизированное тестирование позволяет различать случайные и существенные сложности?
ryscl
1
@RyanSmith. Короче говоря, нет. На самом деле, я не думаю, что есть какой-то конкретный способ (кроме «усердно думать»), чтобы различать их. Но вопрос в том, чтобы "управлять" этим. Если вы рассматриваете требования, дизайн, контрольные примеры как часть архитектуры системы, то отсутствие автоматических тестов само по себе является случайной сложностью, поэтому добавление автоматического тестирования, если его не хватает, помогает решить его и сделать то, что там более управляемым . Но определенно это не решает все это.
Кит
3

« Все должно быть сделано как можно проще, но не проще »,
- приписывают Альберту Эйнштейну

Позвольте мне набросать мой личный алгоритм для решения случайных сложностей.

  1. Напишите историю пользователя или вариант использования. Отзыв с владельцем продукта.
  2. Напишите интеграционный тест, который не пройден, потому что функция отсутствует. Проверьте с QA, или ведущим инженером, если есть такая вещь в вашей команде.
  3. Напишите модульные тесты для некоторых классов, которые могут пройти интеграционный тест.
  4. Напишите минимальную реализацию для тех классов, которые проходят модульные тесты.
  5. Просмотрите юнит-тесты и реализацию с другим разработчиком. Перейти к шагу 3.

Вся магия дизайна будет на шаге 3: как вы настраиваете эти классы? Это тот же вопрос, что и: как вы себе представляете, что у вас есть решение вашей проблемы, прежде чем у вас есть решение вашей проблемы?

Примечательно, что воображение, что у вас есть решение, кажется одной из главных рекомендаций людей, которые пишут о решении проблем («Абсельсон и Суссман,« Желаемое мышление »,« Структура и интерпретация компьютерных программ » и« Работа в обратном направлении »в книге Поли« Как Решить это )

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

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

logc
источник
2

Случайный Сложность

Первоначальный вопрос (перефразированный) был:

Как архитекторы управляют случайными сложностями в программных проектах?

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

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

Как избежать ненужной сложности

Исходя из основной части вопроса, я бы перефразировал это так:

Как архитекторы управляют сложностью программных проектов?

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

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

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

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

Построение решения

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

Вернуться к конкретным заключительным вопросам:

Конкретные методы для укрощения случайных сложностей можно найти в следующих источниках.

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

Аарон Холл
источник
Что вы подразумеваете под "гештальт"? Я обнаружил, что это очень похоже на «парадигму» - обычно неправильно используется или используется для придания академической атмосферы.
0

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

В какой-то момент Кент Бекс сказал о себе: «Я не отличный программист; я просто хороший программист с хорошими привычками».

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

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

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

Теперь многие программисты даже не знают всех знаний, необходимых для написания чистого кода. Молодые программисты склонны отказываться от знаний об алгоритмах и структурах данных, а большинство старых программистов склонны забывать это Или большие обозначения O и анализ сложности. Старые программисты склонны отклонять шаблоны или запахи кода - или даже не знают, что они существуют. Большинство программистов любого поколения, даже если они знают о шаблонах, никогда не помнят точное, когда использовать и части драйверов. Немногие программисты любого поколения постоянно оценивают свой код на соответствие принципам SOLID. Многие программисты смешивают все возможные уровни абстракции повсюду. Пока я не знаю ни одного коллеги-программиста, который бы постоянно оценивал его код по отношению к запахам, описанным Фаулером в его книге по рефакторингу. Хотя в некоторых проектах используется какой-либо инструмент метрик, наиболее часто используемая метрика - это сложность того или иного типа, тогда как две другие метрики - связность и сплоченность - в значительной степени игнорируются, даже если они очень важны для чистого кода. Другим аспектом, который почти все игнорируют, является когнитивная нагрузка. Немногие программисты рассматривают юнит-тесты как документацию, и еще меньше знают, что трудно писать или называть юнит-тесты еще одной вонью кода, которая обычно указывает на плохой факторинг. Крошечное меньшинство знает о мантре управляемой доменом конструкции, чтобы держать модель кода и модель бизнес-домена как можно ближе друг к другу, поскольку несоответствия неизбежно создают проблемы в будущем. Все это необходимо учитывать постоянно, если вы хотите, чтобы ваш код был чистым. И многое другое, что я не могу вспомнить прямо сейчас. наиболее используемая метрика - это сложность того или иного рода, в то время как две другие метрики - связность и сплоченность - в значительной степени игнорируются, даже если они очень важны для чистого кода. Другим аспектом, который почти все игнорируют, является когнитивная нагрузка. Немногие программисты рассматривают юнит-тесты как документацию, и еще меньше знают, что трудно писать или называть юнит-тесты еще одной вонью кода, которая обычно указывает на плохой факторинг. Крошечное меньшинство знает о мантре управляемой доменом конструкции, чтобы держать модель кода и модель бизнес-домена как можно ближе друг к другу, поскольку несоответствия неизбежно создают проблемы в будущем. Все это необходимо учитывать постоянно, если вы хотите, чтобы ваш код был чистым. И многое другое, что я не могу вспомнить прямо сейчас. наиболее используемая метрика - это сложность того или иного рода, в то время как две другие метрики - связность и сплоченность - в значительной степени игнорируются, даже если они очень важны для чистого кода. Другим аспектом, который почти все игнорируют, является когнитивная нагрузка. Немногие программисты рассматривают юнит-тесты как документацию, и еще меньше знают, что трудно писать или называть юнит-тесты еще одной вонью кода, которая обычно указывает на плохой факторинг. Крошечное меньшинство знает о мантре управляемой доменом конструкции, чтобы держать модель кода и модель бизнес-домена как можно ближе друг к другу, поскольку несоответствия неизбежно создают проблемы в будущем. Все это необходимо учитывать постоянно, если вы хотите, чтобы ваш код был чистым. И многое другое, что я не могу вспомнить прямо сейчас. в то время как две другие метрики - связь и сплоченность - в значительной степени игнорируются, даже если они очень важны для чистого кода. Другим аспектом, который почти все игнорируют, является когнитивная нагрузка. Немногие программисты рассматривают юнит-тесты как документацию, и еще меньше знают, что трудно писать или называть юнит-тесты еще одной вонью кода, которая обычно указывает на плохой факторинг. Крошечное меньшинство знает о мантре управляемой доменом конструкции, чтобы держать модель кода и модель бизнес-домена как можно ближе друг к другу, поскольку несоответствия неизбежно создают проблемы в будущем. Все это необходимо учитывать постоянно, если вы хотите, чтобы ваш код был чистым. И многое другое, что я не могу вспомнить прямо сейчас. в то время как две другие метрики - связь и сплоченность - в значительной степени игнорируются, даже если они очень важны для чистого кода. Другим аспектом, который почти все игнорируют, является когнитивная нагрузка. Немногие программисты рассматривают юнит-тесты как документацию, и еще меньше знают, что трудно писать или называть юнит-тесты еще одной вонью кода, которая обычно указывает на плохой факторинг. Крошечное меньшинство знает о мантре управляемой доменом конструкции, чтобы держать модель кода и модель бизнес-домена как можно ближе друг к другу, поскольку несоответствия неизбежно создают проблемы в будущем. Все это необходимо учитывать постоянно, если вы хотите, чтобы ваш код был чистым. И многое другое, что я не могу вспомнить прямо сейчас. Другим аспектом, который почти все игнорируют, является когнитивная нагрузка. Немногие программисты рассматривают юнит-тесты как документацию, и еще меньше знают, что трудно писать или называть юнит-тесты еще одной вонью кода, которая обычно указывает на плохой факторинг. Крошечное меньшинство знает о мантре управляемой доменом конструкции, чтобы держать модель кода и модель бизнес-домена как можно ближе друг к другу, поскольку несоответствия неизбежно создают проблемы в будущем. Все это необходимо учитывать постоянно, если вы хотите, чтобы ваш код был чистым. И многое другое, что я не могу вспомнить прямо сейчас. Другим аспектом, который почти все игнорируют, является когнитивная нагрузка. Немногие программисты рассматривают юнит-тесты как документацию, и еще меньше знают, что трудно писать или называть юнит-тесты еще одной вонью кода, которая обычно указывает на плохой факторинг. Крошечное меньшинство знает о мантре управляемой доменом конструкции, чтобы держать модель кода и модель бизнес-домена как можно ближе друг к другу, поскольку несоответствия неизбежно создают проблемы в будущем. Все это необходимо учитывать постоянно, если вы хотите, чтобы ваш код был чистым. И многое другое, что я не могу вспомнить прямо сейчас. s мантра, чтобы держать модель кода и модель бизнес-домена как можно ближе друг к другу, так как расхождения неизбежно создадут проблемы в будущем. Все это необходимо учитывать постоянно, если вы хотите, чтобы ваш код был чистым. И многое другое, что я не могу вспомнить прямо сейчас. s мантра, чтобы держать модель кода и модель бизнес-домена как можно ближе друг к другу, так как расхождения неизбежно создадут проблемы в будущем. Все это необходимо учитывать постоянно, если вы хотите, чтобы ваш код был чистым. И многое другое, что я не могу вспомнить прямо сейчас.

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

user625488
источник