Наскільки "простий" - це справжнє рішення KISS? [зачинено]

Зізнаюсь : у мене є проблема "тримати це просто і коротко" більшу частину часу, тому що намагання зробити це відповідно до прочитаних книг, моделей дизайну, які я чув і т. Д. Викликає в мене такий ентузіазм - захоплення відчуття того, що я на вірному шляху до ймовірної досконалості.

З іншого боку, так, це додає мені додаткового навантаження з точки зору виконання термінів іноді ...

Але кожен раз, коли я кажу собі: "Наступного разу будь просто, ти дурний!" Мені здається, що тихо важко зробити це "простим", коли настане наступний раз, тому що він починає відчувати себе дивно ... і незручно після точки.

Тоді я починаю судити про своє розуміння "простого" ...

Чи означає SIMPLE занадто короткий, що працює, але важко підтримувати та розширювати?

Чи ПРОСТО означає порушення багатьох принципів OOP?

Чи ПРОСТО означає обман?

Чи ПРОСТО означає просто дотримання термінів без жодних домовленостей? тощо.

Власне, що це?

Питання : Чи можете ви написати точне визначення ПРОСТО в термінах принципу KISS? -якщо є.

Дякую!

Давайте вивчимо французький KISS:

La удосконалення є відвідувачами, не пасти лорск'іл плюс риен j ajouter, mais lorsqu'il n'y плюс rien à пенсіонер. - Антуан де Сент-Екзюпері

Що перекладається на:

Досконалість досягається не тоді, коли більше нічого не можна додати, а коли не залишається нічого, щоб забрати. - Антуан де Сент-Екзюпері

Сценарій

Потрібно вирізати і прищипувати.

Рішення A: Не KISS

Рішення B: KISS

Що стосується точного визначення: важко визначити абсолютну шкалу для вимірювання простоти. Переважно тому, що справжня простота виключає справжнє розуміння існуючої проблеми, і це рідко можливо досягти. Але скажімо, що рішення A і B ілюструють різницю між рішеннями, що мають тенденцію до надмірно ускладнення і простоти відповідно.

"Зробіть речі максимально простими, але не простішими" -Ейнштейн

Збереження коду максимально просто, але не простіше, залежить від проблеми, яка вирішується. Поки проблема, яка вирішується, як правило, змінюється, так і KISS.

Існує баланс між надвиробничою технікою (о, людина, це виглядає як чудове місце, щоб показати свої навички дизайну!) Та недостатньою інженерією (якби тільки я використовував фабрику, у мене не було б цього з’єднання, яке змусило мене зробити 20 зміни коду ...). Мета - ремонтопридатність.

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

Чи означає SIMPLE занадто короткий, що працює, але важко підтримувати та розширювати?

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

Чи ПРОСТО означає порушення багатьох принципів OOP?

Ні. Більшість принципів OOP розроблені для того, щоб зберегти чистіший та організованіший код, що, врешті-решт, простіше.

Чи ПРОСТО означає обман?

Ні. Писати важко, щоб підтримувати код і хаки під виглядом дотримання строків.

Чи ПРОСТО означає просто дотримання термінів без жодних домовленостей? тощо.

Ні. Терміни та простота вашого коду - це два окремих питання. Написання простого коду не потребує часу більше часу для написання (хоча це поширена помилка).

Це дуже складно пояснити, оскільки просте не означає те саме для всіх.

Приклад. Деякі розробники вважають, що ?:це просто, але інші вважають, що ifтвердження є кращим. Коли його знизиться до цього рівня, ви не можете порадувати всіх.

Взагалі прості засоби без складності . Щоб зрозуміти простоту, нам потрібно зрозуміти складність.

Існує два типи складності:

Суттєва складність стосується ситуації, коли всі розумні рішення проблеми повинні бути складними (і, можливо, заплутаними), оскільки "прості" рішення не могли б адекватно вирішити проблему. - Вікіпедія

Випадкова складність - це складність, яка виникає в комп'ютерних програмах або в процесі їх розвитку (комп'ютерне програмування), що не є суттєвим для вирішуваної проблеми. - Вікіпедія

Ви можете перевірити істотну складність за допомогою наступних питань:

Це рішення просте? Чи можу я пояснити це своєму одноліткові за проміжок часу за пару хвилин, і вони отримають його? Чи є більш просте рішення проблеми? Якщо так, то чи є компроміси між складним рішенням порівняно з простим? Чи можемо ми жити з тими вигідними? Наприклад, багато програмістів роблять помилку мікро-оптимізації всього, і їх рішення (і код також) стає надмірно складним.

Перевірка випадкової складності:

Чи простий код? Якщо я повернусь до нього через три місяці, скільки часу знадобиться мені, щоб побудувати контекст у моєму мозку, щоб я зміг внести зміни, які мені потрібно внести? Чи все в моєму вихідному коді має чітке призначення, і воно ефективно передає цю мету мені та іншим розробникам ? Наскільки важко перевірити свій код? Зазвичай, чим складніший ваш код, тим складніше його одиничне тестування, тому я зазвичай використовую це як міру складності. Зазвичай ви хочете невеликих, добре названих та зосереджених занять та методів. Моделі дизайну зазвичай допомагають вам і цього досягти.

Якщо ви виявите, що хочете використовувати шаблон дизайну лише тому, що ви тільки що читали про нього, це, ймовірно, введе в собі випадкові складності. Якщо ви виявите, що хочете щось вкласти, тому що ви думаєте "його розумним", це, ймовірно, введе в себе випадковість.

Я сподіваюся, що це допомагає і не забувайте: Просте не означає ЛЕГКО .

Я завжди відчував, що принципи, які стоять за X11 ( http://en.wikipedia.org/wiki/X_Window_System#Principles ), варто було б дотримуватися. Мені не завжди вдається досягти цієї мети.

Зокрема, мені постійно нагадувати про себе ... "Не додайте нових функціональних можливостей, якщо ви не знаєте якогось реального додатка, який цього вимагатиме". Та "Якщо ви зможете отримати 90 відсотків бажаного ефекту за 10 відсотків роботи, скористайтеся більш простим рішенням ".

Питання: Чи можете ви написати точне визначення ПРОСТО в термінах принципу KISS? -якщо є.

Немає.

Просте - у цьому конкретному контексті є прямо протилежним до складного. Просте не обов'язково означає: Кожна дурно налаштована людина повинна це розуміти - але ви повинні переконатися, що ви могли це зрозуміти, навіть якщо ви самі цього не написали.

Складності можна було б досягти важкими посиланнями - позбудьтесь цих! Багато файлів / класів пов'язані один з одним - ніяк! І складний код (що означає: ланцюгові петлі, декілька шарів ITE тощо) - ніхто не хоче цього читати.

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

Звичайно ... останні кілька речень спрацювали б так: У класах є доступність для визначення приватних функцій, просто використовуйте цю можливість, щоб розділити функції на 50 вкладишів, щоб це було набагато читабельніше (не забувайте хороших імен, тому не потрібно так коментувати).

АЛЕ: Набагато простіше (!) Прочитати все, якщо є повний стоп, який показує: я закінчив думку, продовжимо з наступною.

Ось що я б визначив як простий.