Насколько «простым» является настоящее решение KISS? [закрыто]

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

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

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

Тогда я начинаю судить о своем понимании «простого» ...

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

Означает ли SIMPLE нарушение многих принципов ООП?

Означает ли ПРОСТО мошенничество?

Означает ли ПРОСТО, просто соблюдение сроков без каких-либо сделок? и т.п.

На самом деле, что это?

Вопрос : Можете ли вы написать ТОЧНОЕ определение SIMPLE с точки зрения принципа KISS? -Если там есть.

Благодарность!

Давайте выучим французский поцелуй:

Безупречное и приятное, без преувеличения, без преувеличения. - Антуан де Сент-Экзюпери

Который переводится на:

Совершенство достигается не тогда, когда нечего добавить, а когда нечего отнять. - Антуан де Сент-Экзюпери

сценарий

Вы должны вырезать и ущипнуть.

Решение А: не поцелуй

Решение Б: ПОЦЕЛУЙ

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

«Сделай вещи как можно проще, но не проще» - Эйнштейн

Сохранение кода как можно более простым, но не более простым, зависит от решаемой проблемы. Пока решаемая проблема имеет тенденцию меняться, меняется и KISS.

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

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

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

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

Означает ли SIMPLE нарушение многих принципов ООП?

Нет. Большинство принципов ООП предназначены для поддержания чистоты и организованности кода, что в итоге становится проще.

Означает ли ПРОСТО мошенничество?

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

Означает ли ПРОСТО, просто соблюдение сроков без каких-либо сделок? и т.п.

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

Это очень сложно объяснить, потому что простое не означает, что для всех это одно и то же.

Пример. Некоторые разработчики думают, что ?:это просто, но другие думают, что ifутверждение лучше. Когда до этого уровня, вы не можете угодить всем.

В общем, прост значит без сложности . Чтобы понять простоту, нам нужно понять сложность.

Есть два типа сложности:

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

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

Вы можете проверить существенную сложность с помощью следующих вопросов:

Это решение простое? Могу ли я объяснить это своему пэру в течение пары минут, и они получат это? Есть ли более простое решение проблемы? Если да, есть ли компромиссы между сложным решением и простым? Можем ли мы жить с этими компромиссами? Например, многие программисты ошибаются в микрооптимизации всего, и их решение (и код тоже) становится слишком сложным.

Проверка вашей случайной сложности:

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

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

Надеюсь, это поможет и не забывайте: Простое не значит ЛЕГКО .

Я всегда чувствовал, что принципы X11 ( http://en.wikipedia.org/wiki/X_Window_System#Principles ) заслуживают внимания. Я не всегда достигаю этой цели.

В частности, мне постоянно приходится напоминать себе: «Не добавляйте новые функциональные возможности, если вы не знаете, какое-нибудь реальное приложение, которое потребует его», и «Если вы можете получить 90 процентов желаемого эффекта за 10 процентов работы, используйте более простое решение. "

Вопрос: Можете ли вы написать ТОЧНОЕ определение SIMPLE с точки зрения принципа KISS? -Если там есть.

Нет.

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

Сложность может быть достигнута с помощью твердых ссылок понять - избавиться от них! Многие файлы / классы связаны друг с другом - ни за что! И сложный код (то есть: цепочки циклов, несколько уровней ITE и т. Д.) - никто не хочет читать это.

На мой взгляд: очень легко добавить другую функцию, в классах вы также можете добавить частные функции, чтобы не связываться с интерфейсом. Так почему бы не использовать это преимущество и ограничить ваши функции / процедуры до 50 строк. Может быть, даже меньше. Получить несколько значимых имен. Таким образом, вы делаете большинство комментариев устаревшими. Таким образом, ваши функции легко читаются, легко модифицируются / расширяются.

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

НО: Гораздо проще (!) Прочитать все, если есть точка полной остановки, которая показывает: я закончил мысль, давайте продолжим со следующей.

Вот что я бы назвал простым.