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

Отже, моє запитання: чи люди, які вважають, що певні методи абстрагування занадто розумні, протистоять розуму як такої , чи є якась інша причина заперечення?

EDIT: Цей комбінатор парсера є прикладом того, що я вважаю б розумним кодом. Я завантажив це і передивився близько півгодини. Потім я переступив через розширення макросів на папері і побачив світло. Тепер, коли я це розумію, здається набагато елегантнішим, ніж комбінатор парного аналізу Хаскелла.

Прості рішення краще для тривалого обслуговування. І не завжди йдеться лише про знайомство з мовою. Складна лінія (або лінії) потребує часу, щоб зрозуміти, навіть якщо ви знавець даної мови. Ви відкриваєте файл і починаєте читати: "нормально, просто, зрозуміло, так, WTF ?!" Ваш мозок зупиняється, і тепер вам доведеться зупинитися і розшифрувати складну лінію. Якщо не було вимірної, конкретної причини для цього впровадження, вона "занадто розумна".

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

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

Принцип KISS

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

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

Брайан Керніган

Дурні ігнорують складність; це страждають прагматики; експерти уникають цього; генії видаляють його. - Алан Перліс

Найкраще рішення - це не завжди найрозумніше рішення. Іноді прості рішення однаково хороші.

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

Щоб цитувати Брайана Керніган:

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

кмітливість - це інструмент; само по собі це не шкідливо. Це стає шкідливим лише в умовах, коли це не потрібно.

"Розумний", коли застосовується до коду, майже завжди є лише евфемізмом для "непотрібних складних".

Читання хорошого, зрозумілого, простого коду досить важке. Читання "розумного" коду - це як би вивчати латинську поезію заново.

Плутанина виникає через те, що «розумний» як атрибут людини має зовсім інше значення. Цей випадок також можна розглядати як приклад того, чому розробляти програмне забезпечення для реальних людей важко: Тому що вони неоднозначні.

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

Більшість людей зосереджуються на кмітливості з аспекту "Код вимагає занадто багато розшифровки, щоб зрозуміти, що він робить", і всі погані речі, які йдуть разом із тим, як

1. Ніхто більше не може це зрозуміти, не кажучи вже про підтримку / налагодження.
2. Людина, яка написала, навіть не знає, що робить.
3. Насправді це може бути не все так блискуче
4. тощо.

Усі добрі моменти, але є ще один негативний аспект кмітливості, і це стара проблема Его. Це спричиняє проблеми в порядку

1. Хтось занадто "розумний", щоб використовувати рішення інших. Навіщо шукати те, що зробили інші люди, коли ви можете придумати свій власний спосіб зняття тієї самої кішки?
2. Хтось, хто думає, що винайшов найкрутіше рішення проблеми, часто відмовляється брати будь-який внесок.
3. Ніхто не дозволить змінювати "свій" код навіть тоді, коли є очевидні проблеми або потрібні дрібниці.
4. Дещо навпаки, вони думають, що вони розумні, і їм потрібно використовувати "найновішу" техніку, щоб довести, наскільки вони розумні, але не в змозі отримати хорошу справу з цим ні в особистих проектах, ні в іншому випадку невиробничим кодом, перш ніж передати його на критичні частини система.

Ми всі іноді винні в занадто великому егої, але коли це стає на шляху команди, це проблема.

Хороший розумний - високе співвідношення між розумними лініями коду та рядками в не розумній альтернативи. 20 рядків коду, які рятують вас від написання 20000 - це надзвичайно добре. Good Clever - це заощадити на роботі.

Bad Clever - низьке співвідношення між рядками написаного коду, написаним проти рядків збереженого коду. Один рядок розумного коду, який рятує вас від написання п'яти рядків коду, - це поганий розум. Поганий розумний - це про "синтаксичну мастурбацію".

Зауважу лише: поганий розумний майже ніколи не називається «поганий розумний»; вона часто буде подорожувати під псевдонімами "красивий", "елегантний", "лаконічний" або "лаконічний".

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

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

tl; dr. Я відчуваю себе розумним, коли під час огляду коду моя рецензентка каже: "ух, це було простіше, ніж я думав, що це буде", на відміну від "wtf - це все".

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

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

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

Іноді я був настільки розумний, що помилявся.

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

Якщо розумний код + кількість коментарів, необхідних для того, щоб зробити його зрозумілим кодом <= простий код, то я кажу про перехід на розумний код. Кожного разу.

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

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

Перефразовуючи:

Будь-яка розумна людина може зробити простий складний, для того, щоб зробити простий, потрібен геній.

Прийняття складної ідеї та спрощення її настільки зрозумілою демонструє розумність конструктора, але прийняття простої ідеї та ускладнення її показує, що конструктор хоче сприйматись як розумний.

Якщо «розумне» рішення важко з'ясувати, його не слід використовувати. Наприклад, якщо через побічні ефекти ви можете зав'язати складний обчислення на один рядок, це розумно. Але якщо хтось інший потребує години, щоб зрозуміти, що у світі ти зробив, це занадто розумно.

На мою думку, кмітливість сама по собі не є проблемою. Зазвичай ми можемо робити плутанину щодо "розумного" (без сарказму) та "проникливого" коду. Я вважаю проблемою той факт, що зазвичай "розумний" (з сарказмом) код містить неявні невидимі вимоги, що ускладнює його налагодження та підтримку протягом часу.

Існує кілька відомих алгоритмів, які розумні. Quicksort - це один, ІМО.

"Розумний" (з сарказмом) код зазвичай робить припущення щодо встановлення змінних та станів системи, які практично відключаються від "розумного" коду (як файли, відкриті раніше, мережеві з'єднання, бази даних тощо ...).

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

"Розумний код" - це будь-який код, над яким програмісту довелося подумати дуже важко або використати якийсь передовий навик, щоб написати його. Проблема в тому, що вона ігнорує необхідність певного "кмітливості", найкраще висловленого Брайаном В. Керніган:

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

Тому що те, що схоже на кмітливість для розробника у вибуху творчості, може просто перетворитись на безлад і просто бути нечитабельним , незбагненним блоком незрозумілих загадок для інших.

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

За винятком, звичайно, якщо є виправдання розумності. І якщо є добра документація, яка додається разом із затуманеною річчю, яку ви тільки що написали. Ви прокоментували цей розумний фрагмент коду, правда? Поясніть, що це задум, чому воно має бути таким, як воно поводиться?

Якщо немає обґрунтування, то, мабуть, це просто передчасна оптимізація, надмірна інженерія або проблема ЯГНІ. Якщо потрібно 15 рівнів непрямості, щоб зробити щось просте, то є хороший шанс потрапити і під попередні категорії. А якщо це не задокументовано, то це просто біда.

Великий код не повинен вимагати, щоб утримувач постійно був на 100%, щоб зрозуміти це. Хороший код розумний. Великий код може бути майже таким же ефективним, але кращим у багатьох інших аспектах. Великий код не повинен вимагати IDE з 15 переглядами, щоб відповідати дизайну вашої програми.

Примітка: ага, я написав кілька речей, які я вважав розумними, але це притягнуло WTF? з - якщо не моїх співавторів - рот мого менеджера. Доводиться дивитись на це з їхньої точки зору.

Я схильний бути розумним , але прагну бути елегантним .

Розробіть код зараз, коли інші не намагатимуться їх уникати пізніше .

Це моє розуміння питання, виходячи з мого досвіду та інших відповідей:

1. Код, який вимагав розумності в написанні, але виходить читабельним і ремонтопридатним, не вважається шкідливим. Однак більшість розробників не називали б такий код "розумним"; вони можуть вживати інший термін, як "елегантний". Може бути, а може і не бути дебатів щодо того, чи існує такий код.
2. Виробничий код, який вимагає значного часу та зусиль для розуміння навіть досвідченого розробника, знайомого з мовою, "розумний" і вважається шкідливим для всіх.
3. Виробничий код, який вимагає значних витрат часу та зусиль недосвідченими розробниками, дехто вважає шкідливим. Я бачив відповіді так чи інакше, і я працював з розробниками, які чітко сказали, що вважають за краще зберегти все "найнижчий загальний знаменник".

Я знаю хлопця; він, мабуть, найяскравіша людина, яку я коли-небудь зустрічав. Він, безумовно, неймовірний кодер, мабуть, кращий, ніж я коли-небудь буду в усьому своєму житті, з точки зору чистого відбивання програмування. Він пише код так, як він набирає текст документа і може скасувати пов'язаний список, як ви б не повірили. Якщо ви хочете поговорити про написання якогось серйозно складного коду, він ваш чоловік, і якщо я зіткнувся з неймовірно важкою проблемою, я завжди звертаюся до нього. Однак робота над проектом з ним у командній обстановці неприємна. Він не в змозі безпосередньо націлити бізнес-проблему і надати логічне, ефективне та стисле її вирішення. Для нього перелік коду з 1000 рядків був би кращим, ніж 100. Замість використання інструментів, наданих йому через IDE або фреймворк, він прокрутить власний супероптимізований інструмент.

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

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

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

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

Я пам’ятаю, що одного разу я використав 1 список замість 3 та створив одну велику функцію, яку було дуже важко підтримувати / змінювати.

У сучасному світі нам не потрібно жертвувати чіткістю коду для продуктивності (крім c ++, вони не повинні, але вони будуть).

Зазвичай, коли вам потрібно бути «розумним», щоб вирішити проблему в коді. Якщо вирішення проблеми не дуже просте, тоді ви отримаєте безліч плутаних облич чи інших дивних побічних ефектів при допущенні певних умов (що може бути на 100% правильним на момент написання коду)

Таким чином розумний == заплутаний == поганий :( Але це також приголомшливо, оскільки я використовував їх для практичного вирішення обмежених проблем.

Повторне цитування контексту та легшого розуміння:

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

Те, що тут написав Брайан Керніган, очевидно, стосується згортки, і він помилково вжив слово розумний.

"Налагодження вдвічі складніше, ніж написання коду в першу чергу. Тому, якщо ви пишете код якомога [згорнувшись], ви, за визначенням, недостатньо розумні, щоб налагодити його."

Звиток:

A thing that is complex and difficult to follow.

Розумний:

Showing intelligence or skill; ingenious

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

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

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

Мені потрібно уточнити, хоча часто розуміти складніше, ніж вигадувати своє. Через загальну проблему в промисловості за нереалістичні терміни винайдення власних для вашої меншої нішевої проблеми буде використано для економії часу. Це ґрунтується на спостереженні, що корисні речі для багаторазового використання зазвичай орієнтовані на більшу нішу або служать корисною абстракцією для винаходу. Він також ґрунтується на тому, що люди націлюються на великі ніші, щоб заробити більше грошей, коли часто це робить інструмент надзвичайно важким у використанні через складність, яка полягає в тому, щоб зробити щось корисне для широкої області застосувань.

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

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

• Розмова Гвідо Ван Россума про петлі подій та те, як він зрозумів їх
• Співробітник GitHub, який заявив, що вони уникають найму розумних людей на Y-Combinator
• Значна частина дискусій та знань, які тривають у спільноті Python. Спільнота Python особливо критично ставиться до нових ідей, але не відкидає нових ідей, які вони не розуміють поза рукою, і типово ти можеш бачити функції, які спочатку розглядалися як перекручені, бачать світло дня як основну особливість / пакет мови.
• Мій власний досвід та професійна думка, заснована на моїх 10000 спостереженнях. Я не можу реально побачити особливості просвітитись з усієї дороги там, хоча :( Сподіваємось, ваш досвід та спостереження скажуть вам те саме, і хтось ще може прокоментувати нижче, щоб дати цій відповіді певну заслугу.

Не соромтеся додавати власні цитати! Також сміливо додайте коми до мого тексту. Я не оновив свої знання щодо використання коми через англійську мову за досить довгий час ...

Тому що часто люди не знають мови, ідіоми та зразки. Вони могли б взяти книгу і вивчити її, але цього не роблять. І через цих людей вам слід написати простий код.

Це не кмітливість. Це знання.

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

Розумний розробник - це гарна річ.

Однак перед розумністю приходять інші риси. Як ви могли зрозуміти, я поговорю про дисципліну . Розумний і недисциплінований розробник може бути дуже поганим для довгострокової ремонтопридатності системи.

Припустимо, що виникає помилка або надходить нова вимога. Розумний розробник може незабаром зрозуміти, що пара локальних виправлень виконає роботу за 2 хвилини. Якщо цей розробник буде дисциплінований, він утримається від застосування цих виправлень до вихідного коду і натомість знайде змістовний спосіб скласти бажану поведінку в системі. Таким чином, наступного разу, коли виникатиме потреба змінити конкретні фрагменти коду, у сервісного сервісу буде легкий час зрозуміти код та реалізувати нові зміни, нічого не порушуючи. Якщо ні, то ви отримаєте картину.