Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Як кількість рядків коду впливає на складність його підтримки в майбутньому

Привіт, мене звуть Андрій, я керівник напряму NodeJS у компанії ArtJoker Software. Хочу поділитися думкою про те, який підхід до написання нового коду є найкращим. Ця стаття дозволить вам подивитися на деякі усталені підходи з нової точки зору, через призму мого досвіду, та знайти рішення для написання коду.

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

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

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

Ця стаття буде корисною як для мідлів, так і для сеньйорів. Для починаючих програмістів це скоріше інструкція — як уникнути помилок в майбутньому.

Думайте про тих, хто підтримуватиме код

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

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

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

Simplicity

Підтримувати код складніше, ніж писати новий, тому при написанні намагайтесь максимально спростити його. Ви ж знаєте, як розробники ненавидять колег, чий код вони рефакторять? Пам’ятаєте, як часто люди кажуть: «Працює, тож не чіпай, можеш щось зламати»? Це відбувається через те, що якийсь розробник написав код, не дивлячись у майбутнє. Не будьте як він, зробіть свій код зручнішим, а світ — трохи кращим за допомогою таких рішень. Як саме? Розглянемо далі.

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

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

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

Щоб запобігти хаосу, дотримуйтеся таких принципів.

Уникайте непотрібної абстракції

Вам знайомий сценарій, коли у вас 100+ класів із 1-2 методами? Це викликає проблеми у програмістів, наприклад, коли ви хочете зрозуміти, як працює один клас, необхідно зрозуміти, як працюють усі інші класи.

Не дотримуйтесь правила DRY фанатично

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

Уникайте довгого ланцюга відповідальності

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

Приклад з довгим ланцюгом відповідальності

Приклад з коротким ланцюгом відповідальності

Не використовуйте коментарі в коді

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

Не намагайтеся застосувати кожну хорошу практику

Хороша практика придатна для конкретної мети, наприклад, як шаблон MVC для REST API. Але якщо ви хочете реалізувати всі відомі вам практики, такі, як усі шаблони, SOLID, поліморфізм, інкапсуляція та успадкування, це може бути поганою ідеєю, не раджу використовувати її. Застосовуйте різні практики тільки за умови, якщо ви побачите точне рішення з ними та ніякі інші варіанти не підходять.

Чи впливає обсяг коду на подальшу його підтримку

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

Код, який виглядає компактно, але містить велику кількість вкладених складних функцій — це не зручно. Просто об’ємний код, в якому надто складно знайти «заповітний» рядок — теж не підходить. Шукайте компроміс. Як я зазначив, «Більше — значить краще» не зовсім актуальний для коду підхід.

Що кажуть відомі експерти

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

Про деякі з цих висновків Роберт Мартін (дядько Боб), автор «Чистого коду» та «Швидка розробка програм. Принципи, приклади, практика» розповідає у курсі Software Programming, який безкоштовно доступний на YouTube. Я наполегливо рекомендую його подивитися, бо складне тут подається простою мовою.

Simplicity: не тільки для початківців (або як написати простіший код) — ненудна лекція від Кейт Грегорі — регіональної директорки Microsoft у Торонто, Онтаріо, та партнерки-засновниці Gregory Consulting Limited. Кейт ділиться деякими конкретними підходами, які, ймовірно, спростять ваш код, і обговорює, що потрібно знати і робити, щоб послідовно писати простіший код і пожинати переваги цієї простоти.

Simplicity is not simple — лекція Девіда Хога. Як визначити, коли і чому код є складним, і як ми можемо зробити його простішим? Девід розповідає про методи спрощення продуктів і досвіду, про деякі міркування та рішення, з якими ми можемо зіткнутися під час боротьби з ускладненнями. Також розглядає деякі приклади кодів, які вдалося зробити простішими, не жертвуючи функціональністю.

Маєте власний досвід та інсайти щодо рефакторингу вже готового проєкту або написання коду з думкою про рефакторинг, який колись відбудеться? Діліться ними у коментарях, та нехай випадків, коли за рефакторингом та виправленням помилок минають тижні, буде менше!

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

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

Цікава думка. Мені раніше здавалося, що SOLID, DRY та інші принципи таки придумали, щоб використовувати всюди.

Ни один такой принцип не пригоден для применения _везде_.

100 класів з 1-2 методами краще, ніж 10 класів на 5000 строк з купою всього. Так-так, той самий single-responsibility. І до класу кожного — коментар, для чого він. Навіщо взагалі писати коментарі ? Ну, тут є два види програмістів — які їх пишуть, та які не пишуть і вважають що «з коду все зрозуміло». Воно може й зрозуміло, але ... ви просто навіть сам можете забути, що мали на увазі 2-3 роки тому. А код ваш. А ти так — «О... хто це ла..но писав? А , та це ж я!». А навіщо така складність отут ? Коментарі писав, та обома руками за коментарі. Бо у програміста немає днів-тижнів уявляти «що там малось на увазі», є хвилини або години. Прочитав — зрозумів, це набагато швидше.

Не факт, не завжди. По факту краще 10 класів на 5000 строк + 100...5000 класів даних, + невеличка купка структурних класів (тих вже може бути яка завгодно ієрархія).

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

До речі, це велика проблема IDE — не дозволяти відкрити один документ у кількох вікнах. Навіть ReadOnly.

До речі, це велика проблема IDE — не дозволяти відкрити один документ у кількох вікнах. Навіть ReadOnly.

например IDEA -> right click on header -> split right

А просто не лезть давать советы в том, в чём не разбираешься и даже не пытался — это реально сложно?

©

Про себе
Программист, опыт работы 10+ лет, из них 4 на Java.
До речі, це велика проблема IDE — не дозволяти відкрити один документ у кількох вікнах. Навіть ReadOnly.

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

Каждый по себе судит. А ярлычок мне новый придумай, я коллекционирую.
Разделить экран — да, возможно, один из вариантов. Не лучший. Хотя на очень широком экране вполне годится и такое.

100 класів з 1-2 методами краще, ніж 10 класів на 5000 строк з купою всьог

Неа. Должен быть здравый баланс.
Потому что сделанный по книжке большой проект, где все что «больше 3 строк-функция» тоже не сильно читаем. Это как реляционная БД — в идеале должна быть в одной из НФ, чем выше тем лучше — но на практике их обычно еще и денормализуют

Бо у програміста немає днів-тижнів уявляти «що там малось на увазі», є хвилини або години. Прочитав — зрозумів, це набагато швидше.

Это же неспортивно ))) Прям как фора и допинг

Хуже, это как ответы в задачнике, написанные карандашиком — от того, кто решал их до тебя :)

надругательство над dry не одобряю категоричеськи. афтар, копипаста грех!

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

Уже была шутка про меньше строк кода?

Уникайте непотрібної абстракції

абстракции лоло
org 0×100
mov dx, msg
mov ah, 9
int 0×21
mov ah, 0×4c
int 0×21
msg db ’Hello, World!’, 0×0d, 0×0a, ’$’

Не використовуйте коментарі в коді

а щё тести и документацию тыж программист
и вообще мньше букв луще код
>++++++++[<+++++++++>-]<.
>++++[<+++++++>-]<+.
+++++++..
+++.
>>++++++[<+++++++>-]<++.
------------.
>++++++[<+++++++++>-]<+.
<.
+++.
------.
--------.
>>>++++[<++++++++>-]<+.

Тесты нужны, для валидации продакт-кода. Документация (как и комментарии) — да, не нужны.

Код — самая лучшая, легкочитаемая, актуальная и достоверная документация.

Тесты нужны, для валидации продакт-кода.

И как тесты могут валидировать код? Только если множество входных данных конечно и мы можем их вес перебрать.

Документация (как и комментарии) — да, не нужны.

Скажите, вам понятие L3 support что-то говорит? Особенно, когда это связано с чужой кодовой базой?

Особенно, когда это связано с чужой кодовой базой?

С кодовой базой всё достаточно просто: умеешь читать кодовую базу — никакая иная (кроме спецификации) документация тебе не нужна. Не умеешь читать кодовую базу — никакая документация тебе не поможет.

С кодовой базой всё достаточно просто: умеешь читать кодовую базу — никакая иная (кроме спецификации) документация тебе не нужна.

Когда это простые CRUD-сервисы — несомненно. Но это далеко не всегда так
И одно дело, когда ты можешь неспешно

читать кодовую базу

без документации и комментариев, спокойно сидя и попивая кофеек в понедельник утром, и совсем другое — когда это надо делать в рамках эскалации от top-level customer в пятницу вечером в весьма нервной обстановке. При этом воспроизвести ошибку локально невозможно, так как она специфична для энвайронмента

Так себе экспиреенс хочу сказать, и точно не то, что хотелось бы испытывать постоянно

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

org 0×100
mov dx, msg
mov ah, 9
int 0×21
mov ah, 0×4c
int 0×21
msg db ’Hello, World!’, 0×0d, 0×0a, ’$’

Таки, если заменить это вызовом одной сишной функции — кода получится меньше.

Уникайте непотрібної абстракції

контекст аляля

Таки, если заменить это вызовом одной сишной функции — кода получится меньше.

так?

Уже была шутка про меньше строк кода?
#include <stdio.h> int main() {printf("Hello, World!"); return 0;}

Як можна розмовляти про код без прикладів? А єдиний приклад це взагалі ілюстрація простенького аплікативного функтору

pure userData <*> createUser <*> checkUnique <*> hashPassword <*> saveToDB
над Maybe a чи Either String a чи Either WhateverYouWant a

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

скажуть, що ти не джунфрендлі, або ще гірше: не тімплейєр і зажав свій трансфер нолідж

Бажаю автору побільше чужого коду без коментарів)

Скорочу до змісту: «Не використовуйте коментарі в коді, бо інакше ваш код — загадка».

Так от, код — завжди загадка, яка полягає у тому, що ви ХОТІЛИ зробити. Дуже наївно вважати, що те що код робить і те що хотів автор — одне й те саме, а помилок не існує в природі. Задокументований код — це загадка із відповідями. Великі частини документуються окремо, але є дрібнички, які варто пояснювати тільки тим, хто захоче щось міняти. Диявол саме у тих дрібничках.

Є частини коду, які варто сприймати «як є», вважаючи що вони роблять саме те, що заплановано. По коду розбирати кожен плюсик — тупо вижере людині оперативку, вона дуже невеличка. А от почитати коментар не складно. В сам код ви полізете лише коли вважаєте, що там помилка, або захочете зробити рефакторинг, або покрити інтеграційними тестами. Але щоб зрозуміти одну деталь — треба виходити з презумпції, що всі інші працюють як задумано.

Коментарі допомагають зрозуміти, куди саме перенесли важливу логіку. Особливо коли вона дублюється у кількох місцях, зокрема, логіка безпеки. Левова частина коду логічного навантаження не несе, лише рутині процедури. Але по коду того зрозуміти неможливо, кожен символ «=» може означати щось важливе, кожне оголошення змінної чи створення класу — то невідомо що, невідомо де потім буде застосовано.

Зворотна задача: шматочок коду використовує кількадесят змінних. Звідки вони взялися? Коли і де отримали значення? Де шукати їхню ініціалізацію? Як перевірити валідність даних.

Ну і моя улюблена сфера застосування коментарів: закриваюча дужка }. Ви дійсно вважаєте, що зможете легко знайти по синтаксису, де воно і звідки? В стабільному коді — так, можливо. А коли щось міняєте? Коли вставили фрагмент коду з іншого місця? Коли шукаєте помилку у лінії виконання коду?

На всяку загадку корисно знати відповідь заздалегідь

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

Step1: Всегда использовать пару {} даже для одного вложенного оператора, и бить по рукам при ее отсутствии, принудить команду использовать шаблоны
Step2: Использовать для работы с кодом что-то сложнее блокнота
Step3: ... PROFIT ! ...

«Что-то сложнее блокнота» опускает лапки как только код идёт в редактирование, более того, как правило стремится НАГАДИТЬ, отравляя память ложной подсветкой синтаксиса, покуда код не собран. Насколько полезны IDE для чтения кода, настолько же они напичканы ложками дёгтя для редактирования — разумеется, не отключаемыми сколь-либо адекватным способом.

А ну, назови мне IDE, в которой можно ОСТАВИТЬ КАК ЕСТЬ подсветку синтаксиса, и НЕ МЕНЯТЬ ЕЁ, покуда не скажу? То есть не заниматься дебильным рендеренгом во время набора.

Твои лишние скобки проблему не решают, они её усугубляют, нарушая читаемость. Грубо говоря, к 10й закрытой скобке ты добавишь ещё несколько, пока код не дописан. И вероятность внесения ошибки каждым оператором.

Другими словами, «включать дурака» — любимая реакция бюрократа на любую проблему. А просто не лезть давать советы в том, в чём не разбираешься и даже не пытался — это реально сложно? Что-то мне подсказывает, ты давно уже бросил кодить и перешёл в менеджмент.

любимая реакция бюрократа на любую проблему.

Понятно, стандарты придумывают те, кому нечем заняться — так?
Если кому нравиться видеть в PR 80% диффов в файле после коррекции одной строчки, потому что изменение делалось любителем извращенного странного форматирования, то пусть — дело личных предпочтений, мазохисты же есть в мире. Но мне лично нет. И у меня банально нет ни возможности, ни желания терять время на ревью такого буллшита от непризнанного гения.

Твои лишние скобки проблему не решают, они её усугубляют, нарушая читаемость

O, RLY? Несомненно в случае например нескольких вложенных if-else отказ от скобок крайне поможет с читабельностью. Особенно если случайно удалится где-то tab на среднем уровне. Успехов в дебаге, «почему оно идет не в тот else»

ты давно ужебросил кодить и перешёл в менеджмент.

Не вдаваясь в подробности — абсолютно мимо.

в чём не разбираешься и даже не пытался

Честно говоря да — вся глубина глубин проблемы } при копипасте чужого кода в свой класс прошла мимо меня, признаю

Если кому нравиться видеть в PR 80% диффов в файле после коррекции одной строчки, потому что изменение делалось любителем извращенного странного форматирования,

для Rust
cargo fmt
для Golang
go fmt

як там в JS хз,
а форматування С/С++/Java, мабуть таки для збоченців повно можливостей

в Пайтоні є відступи

Несомненно в случае например нескольких вложенных if-else отказ от скобок крайне поможет с читабельностью.

Зато поможет плагин что колорит фон блоков по типу ide bracket coloring
,а ещё есть фолдинг блоков со стрелочками

Особенно если случайно удалится где-то tab на среднем уровне.

шутка для питониста )

А ну, назови мне IDE, в которой можно ОСТАВИТЬ КАК ЕСТЬ подсветку синтаксиса, и НЕ МЕНЯТЬ ЕЁ, покуда не скажу?

лол
java eclipse «report problems as you type»
и выключить авто билд он сейв )

Покажи это на видео. Не подсветку ошибок, не отключение подсветки, не билд, а СОХРАНЕНИЕ раскраски синтаксиса, без учёта того, что редактируется прямо сейчас. Грубо говоря, когда ты поставил { тебе нужно чтобы это было проигнорированно подсветкой — до того, пока сам не скажешь обновить (удобной комбинацией или настраиваемой), либо настраиваемым таймаутом.

Не путай «лол» с киллер-фичей.

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

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

Но я согласен с тем, что в критических местах (где явно не уразуметь логику), можно оставить комментарий.

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

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

Краткие комментарии для функий/процедур больше пары десятков строк никогда не помешают даже при читаемом названии — это заметно сокращают время на понимание в целом.
Понятно что не стоит в текстовой форме 1:1 детально дублировать описанием логику внутри в этом случае

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

А якщо код не написаний взагалі — то для його розуміння взагалі нічого не потрібно. Think about it.

Я чув так думку що коли нема коду — тоді найменше проблем. Firebase сворили саме для цього! )

Не коли нема коду, а коли в тебе нема доступу до коду. Але це створює потребу робити де-факто код, щоб обходити обмеження недосяжного коду.

(пошепки) Це зветься бюрократією.

С кодом всё достаточно пртосто: чем больше рукописного кода — тем больше проблем (места для багов, количества необходимых тестов для покрытия, итп).

Потому, основным стремлением на проекте — должна быть минимизация рукописного кода. Собственно, на этом основаны и ООП/паттерны (реиспользование), принципы «чистоты кода» тоже.

Слишком лаконичный код нечитаемый.
Пример 1: объединение логики наполовину похожих классов шаблонами или макросами в С++.
Пример 2: функциональное программирование и многолямбд.

Вообще-то лаконичный и читаемый — это синонимы. А вот написанный на машинном языке вместо человеческого — потом оказывается чрезвычайно дорог, потому что поддерживать-то его должны люди. И люди недешёвые. Особенно когда срочно-быстро.

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

perl код очень лаконичен, в строку часто. но сильно мало с ним проблем ?
и таких примеров -море

perl код очень лаконичен, в строку часто. но сильно мало с ним проблем ?

Скажем, если какую-нибудь функцию пёрла ты на проекте перепишешь, в виде собственнописного велосипеда (скажем, на С) — с твоей функцией будет куда больше проблем, чем с перловской.

Говнокод можно написать на любом языке, даже на украинском. Не веришь — открой законы.
Минимизируют не количество кода. Минимизируют количество ПАМЯТИ человека, требуемой для управления этим самым кодом. Минимизируют вероятность ошибки.

И всё это — ценой избыточности. Потому что избыточность в современном IT стоит вообще понты. Скопировать один и тот же кусок кода в 20 мест? Говно вопрос! Это лучше, чем спрятать его в одно место, а в 20 местах создать барьер в понимании логики. Если считаете, что потом этот кусок кода есть вероятность что нужно будет поменять во многих местах сразу — удостоверьтесь, что он содержит уникальную строку. Если её нет — добавьте, например имя класса или переменной сделайте специфическим, или коммент.

Да, есть места, которые требуют управления из одного места, потому что они логически понятны как единый блок. Но если это какая-то рутиная процедура, то пусть она и в 100 местах повторится. И потом в 40 из них поменяется каким-то костылём. Зато когда на 41й раз попросят свистелку-перделку сделать, то изменение будет ОДНО, и не затронет ничего больше. А «don’t repeat yourself» — придётся искать 1000 и 1 причину, чтобы просто не сделать желаемое, чтобы не менять всё. И как поступят? Да просто спрячут под ковёр, в беклог спрячут, продолжая усугублять ситуацию.

Скопировать один и тот же кусок кода в 20 мест? Говно вопрос! Это лучше, чем спрятать его в одно место, а в 20 местах создать барьер в понимании логики

Если это серьезно — то дайте мне это развидеть.
Если нет — то слишком толсто даже для пятницы ))

А как ты естественными-то языками пользуешься? Как тебя понимают? Как тебя понимают быстро и с ходу? И почему код нельзя делать таким же — максимально понятным за счёт избыточности, за счёт повторяемости и узнаваемости шаблонов.

Говнокод, понятный только автору, может писать любой индус. Разумеется, понятный только пока пишет, потом и он хрен поймёт. Ты напиши так, чтобы можно было отдать другому человеку, и код не требовал пояснений и мифической способности «читать чужой код».

А как ты естественными-то языками пользуешься? Как тебя понимают? Как тебя понимают быстро и с ходу? И почему код нельзя делать таким же — максимально понятным за счёт избыточности, за счёт повторяемости и узнаваемости шаблонов.

Потому что то, что ты сгенерировал с помощью естественного языка — это read-only.
«Слово не воробей ...» и вот это вот все

повторяемости и узнаваемости шаблонов.

Мне кажется что ты смешиваешь в кучу разные вещи. Узнаваемость шаблонов — это одно (например, в коде возвращается консистентно null/Collections.emptyXXX/NoSuchElementException/some_weird_custom_approach если функция поиска ничего не нашла. P.S. Как правильно — не топик этого примера, смысл в том, чтобы подход был всегда консистентный), а брутальный copy-paste — совершенно другое

Буває.

В дитинстві було набагато більше.

на этом основаны и ООП/паттерны

гагага

Не «гагага», а «так точно!».

Если отбросить словесную шелуху, ничего иного, кроме облегчения реиспользования кода — в ООП/паттеpнах и прочем СОЛИД нет.

SOLID це не про ООР паттерни (сінглетони, фабрики фабркик і т.д.)

SOLID це не про ООР паттерни

Паттерны — это типовые реализации, основанные на принципах СОЛИД.

гагага

Не «гагага», а «так точно!».

Если отбросить словесную шелуху — ничего иного, кроме использования принципов СОЛИД в типовых реиспользуемых реализациях, в паттернах нет.

Підписатись на коментарі