Чи повинен мій код бути сухим чи читаним, якщо він не може бути обом?

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

Мій останній приклад: Моя програма приймає дані, і через жорсткі вказівки щодо формату, вона може легко визначити, чи слід вводити чи розшифровувати вхід. Для спрощення, коли ключ шифрування та повідомлення конвертуються / генеруються на сумісність, справа в тому, щоб відняти ключ із зашифрованого повідомлення або додати ключ до незашифрованого повідомлення, щоб отримати бажаний вихід (думайте про ключ як шифрування, повідомлення + шифрування = код; код - шифрування = повідомлення). Положення DRY говорить мені, що я повинен перетворити своє зашифроване повідомлення інакше від мого незашифрованого повідомлення, щоб функція, яка приймає ключ шифрування і застосовувала його до повідомлення, ніколи не потребувала розрізнення. Я виявив, що це означає, що мені потрібні деякі вкладені, якщо заяви у функції, але логіка здається суцільною. Однак цей код не легко читається.

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

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

Поки я схильний наголошувати на стислій, DRY-коді над читабельним кодом.

DRY - це настанова, а не релігія. Ті, хто переносить це до сухих, перш за все, завели занадто далеко.

Перш за все, корисний код є першорядним. Якщо код не є корисним і корисним, він не є ... і немає сенсу писати його в першу чергу.

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

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

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

Я не впевнений, виходячи з того, що ви розумієте СУХО. DRY-код не є тим самим, як стислий. Досить часто відбувається навпаки.

Тут я не впевнений, у чому полягає велика справа для цього прикладу. Створіть функцію шифрування, функцію для розшифрування, помічники для загальної функціональності (змішування байтів) та простий передній кінець для введення та визначення шифрування / розшифрування ... Не повторюючи себе.

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

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

Я не знайомий з вашим конкретним випадком, але можу дати деякі загальні вказівки.

Метою як читабельності, так і DRY є ремонтопридатність .

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

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

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

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

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

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

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

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

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

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

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

Створення коду DRY майже завжди означає рефакторинг загальної функціональності на більш дрібні функції. Кожна з цих функцій повинна бути простішою (і, отже, більш читаною), ніж оригінальна. Щоб зберегти все в початковій функції на одному рівні абстракції, це також може означати рефакторинг додаткових деталей, які не використовуються в іншому місці. Тоді ваша оригінальна функція стає "функцією високого рівня", викликаючи менші, і вона стає також меншою і простішою.

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

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

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

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

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

Повторний код слід або переробити на власний метод, або витягнути у власний клас.

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