Як писати менше коду [закрито]

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

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

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

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

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

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

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

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

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

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

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

Але наше краще

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

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

• Додаткові роботи, необхідні для складання компонента
• Додаткова робота для нових бажаючих навчитися цьому
• Величезна додаткова робота для її підтримання

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

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

На мою думку, писати менше коду можна кількома способами:

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

• Не повторіть себе . Я вважаю, що використання CMS, Framework або сторонньої бібліотеки є одним із способів застосування принципу DRY.

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

Крім розуміння мови програмування, я вважаю, що розуміння проблеми та прийом хорошого рішення має багато спільного з цим. Рішення більшості проблем є багато, не всі вони оптимальні. Можна їхати з міста А до міста Б різними дорогами - одна може зайняти дві години, а друга - двічі. Це та сама ідея в програмуванні. Можливо, ви дуже добре знаєте мову, але ви можете придумати рішення, яке займає, скажімо, дві сторінки коду, тоді як хтось інший придумає рішення, яке може бути реалізовано за чверть половини розміру коду. Я багато років цього бачив.

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

Можна сказати, що все мистецтво програмування зводиться саме до цього.

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

Як і всі інші страждання, якщо ви не визнаєте проблеми, ви не збираєтеся шукати рішення. Досвід починає бути фактором, коли ви дізналися, як виглядає менше коду. Коли ви повторно перегляньте свій код, це прекрасний час, щоб визначити, чи можете ви використати код або рефактор для меншого коду. Корпорація Майкрософт змогла покращити швидкість друку за допомогою Windows 2000, НЕ замовивши її двічі (цитата від співробітника Microsoft на одному з їх безкоштовних демонстраційних демонстрацій).

1. Поверніться назад, ваш старший довго звитий код,
2. поставити його під контроль версій,
3. написати кілька тестів для цього, щоб сподіватися, що не вводити нових помилок,
4. переписати.

Повторіть рекламу. І ласкаво просимо в пекло.

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