Коли "правильне" програмування вже не має значення?


49

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

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

Коли я стикаюся з дивними проблемами і шукаю Stack Overflow за допомогою, я бачу, що багато людей просто переспівують питання, які використовують певний тип даних, коли інший є технічно "належним". Як і використання ArrayList, оскільки він не вимагає визначених меж проти повторного визначення int [] з новими відомими межами. Або навіть щось тривіальне на кшталт цього:

for(int i = 0; i < items.length; i ++)
{
    // do something
}

Я знаю, що вона оцінює довжину item.length на кожній ітерації Однак я також знаю, що предметів ніколи не буде більше 15-20 предметів. Тож я повинен дбати, якщо я оцінюю item.length на кожній ітерації?

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

Тож я гадаю, що моє запитання до вас таке: чи є поріг, коли це вже не має значення бути належним? Чи гаразд сказати - "поки ця робота буде виконана, мені все одно?"


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

8
Якби у вашій мові був справжній цикл FOR, ця проблема з численним оцінюванням не трапилася б. На жаль, цього вимагає синтаксис C, оскільки це насправді не цикл FOR; це цикл WHILE, який носить перуку та окуляри з великим носом, і для припинення циклу потрібно прийняти будь-які довільні умови (або взагалі ніякі).
Мейсон Уілер

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

17
Як ви знаєте, що він "оцінює" item.length на кожній ітерації? Компілятори досить розумні. І навіть якщо він неодноразово отримує item.length, то що? Мені б не хотілося бачити код на зразок 'int itemsLength = items.length; для (; i <itemsLength; ...) ', якщо не було проблеми з вимірюваною продуктивністю.
Кевін Клайн

6
Ваша item.length річ абсолютно не має нічого спільного з "правильним програмуванням". Це мікрооптимізація, і хороші програмісти знають краще, ніж витрачати час на тих, поки вони не запустять профайлер і не знають, де реальні проблеми з продуктивністю. Мікрооптимізація та хороший стиль програмування - це часто протилежності, не одне і те ж.
Майкл Боргвардт

Відповіді:


65

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

Це воно.

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

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

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

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


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

21
Можна зробити так, що будь-коли дисциплінований в будь-який час, полегшує бути дисциплінованим, коли ти повинен бути. Деякі люди ставлять запитання щодо Stack Overflow, не натискаючи жодної клавіші перемикання, використовуючи обґрунтування того, що вони можуть адекватно передати свої ідеї без цього, і що англійська мова так чи інакше є текучою і розвивається річчю. Я не знаходжу нічого гнівнішого, окрім, можливо, вірусів, які вважають, що мій час процесора вільний.
Роберт Харві

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

5
@KaiQing, Angry Birds доводиться працювати на декількох платформах, і якщо гра зависає на 2 секунди, х% аудиторії збираються відмовитись від неї, що означає, що для людей із Сердитими птахами на y менше доларів. Надіюсь, це було написано дуже, дуже ретельно. Можливо, це відповідає на ваше запитання. Якщо код призначений саме для вас, хто дбає про те, що ви робите? Якщо є гроші на гроші чи інші народи, то вам краще бути дуже, дуже обережним.
Чарльз Е. Грант

2
@KaiQing Ніхто не може сказати вам поріг для цього, він мінливий від проекту до проекту та кожного проекту протягом часу. Кількість змінних, які впливають на поріг між системою, яка підтримується і не покладається на: LOC, базу користувачів, базу розробника, тип додатка (криптографія порівняно з суворим проти драйверів), надійність функції, вимоги до надмірності, критичність програмного забезпечення (сервер електронної пошти проти . пристрій життєзабезпечення та віджет годинника), підтримувані платформи, стек технологій, кількість даних, що підлягають трансакції чи аналізу, обмеження історичного аудиту та багато іншого впливає на те, наскільки може бути поганим кодом
Jimmy Hoffa

18

Є стара мудра цитата: "Не йдіть слідами мудреців старих. Шукайте, чого вони шукали". Існують причини всіх правил "правильного" кодування. Знати, чому ці правила існують, важливіше, ніж знати, що це за правила.

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

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

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


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

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

1
Якщо це звучало так, ніби я вам казав за порушення правил, я це погано сформулював. Жодна з речей, про які ти говорив, - це те, що я заперечував би. Я намагався зазначити, що «дух закону» важливіший за «букву закону».
Майкл Шоу

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

10

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

Зменшення віддачі встановлюється тоді, коли гранична вигода менше граничного часу / зусиль.

Чи можете ви зробити бізнес-випадок для items.lengthвиходу з forциклу? Економічно чи може ця зміна навіть виправдати витрачений час на її виправдання? Оскільки в користувацькому досвіді немає різниці, ви навіть ніколи не отримаєте нічого навіть за витрачений час на вимірювання (крім корисного запам'ятовування). Користувачам програма не сподобається більше, ніж їм, і більше копій не буде продано в результаті цієї зміни.

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

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

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


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

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

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

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

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

3

Коли ви не повинні дбати про те, щоб ваш код був "належним"

  • Якщо вам вдасться відповісти на бізнес-мету, і тримати її з часом з низькими накладними витратами. (користувачі не переглядають джерело, перш ніж вони заплатять вам)
  • MVP / POC - Якщо написання правильного коду означає витратити час на концепцію, перш ніж ви знаєте, як заробити на ній гроші (якщо ви витрачаєте роки та 45 мільйонів доларів на написання програми та закінчуєте закривати магазин, тому що в ньому не було ринку, нікого не цікавить, як належним був код)
  • Коли у вас була небезпечна для життя ситуація (наприклад, залізний чоловік, прототип 1 був брудним злом, але це вивело його з печери, правда?)
  • або якщо ви просто не знаєте, як написати належний код (якщо комусь вдається заробляти на життя письмовим кодом без належного коду, я кажу, що в сьогоднішньому безробітті краще написати поганий код, ніж бути бездомним)
  • якщо ви просто знаєте, що ви робите, або думаєте, що можете піти звідси, роблячи вигляд, що ви робите

Коли правильно написати код

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

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

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

2

Чи є ваша робота головним питанням? Це те, що ви намагаєтеся максимально використати?

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

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

Це вгадування. Всі роблять це, але це не працює.

Натомість нехай сама програма розповість вам, у чому її проблема. Ось докладний приклад.

Ви бачите різницю?


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

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

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

2

Ваше запитання - "поки ця робота буде виконана, мені все одно?"

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

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

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


1

Відповідь - це ніколи не має значення, і це завжди має значення ...

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

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

Що відповідає на питання про те, коли можна проігнорувати - коли ти впевнений, що іншим способом буде простіше у довгостроковій перспективі (можливо, тому, що довгого бігу не буде).

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

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


1
"ніколи" та "завжди" скасовують одне одного. Створення вашої відповіді і доброю, і поганою.
Тулен Кордова

@ user1598390: справа в тому, щоб скасувати один одного. Скасуйте догму, і ви залишитеся так, як здається корисним. І ви помилитесь і навчитесь тому.
jmoreno

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

@KaiQing: Тестування та налагодження трапляються звичайно, але, як правило, обмежуються тим, що існує на даний момент - так, наприклад, якщо процес може вийти з ладу з файлом, який мав кодування UTF, і жодним із файлів, над якими ви працюєте. робити, ти цього не тестуєш. Оптимізацію слід проводити, коли виявлена ​​проблема продуктивності. Щодо того, чому смердючість неприкладних прикладів кодування рядків на SO - я думаю, це функція цілей сайту. Він має на меті бути постійним ресурсом, коди у відповідях (і навіть питаннях) розглядаються таким чином, ніби вони будуть шаблоном, який використовують інші.
jmoreno

1

Або навіть щось тривіальне на кшталт цього:

for(int i = 0; i < items.length;i ++) {
     // do something 
}

Я знаю, що вона оцінює довжину item.length на кожній ітерації Однак я також знаю, що предметів ніколи не буде більше 15-20 предметів. Тож я повинен дбати, якщо я оцінюю item.length на кожній ітерації?

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

Тож я думаю, моє питання до вас таке: чи є поріг, коли він більше не має значення? Чи гаразд сказати - "доки вона не виконає роботу, мені> все одно?"

Це дійсно залежить від того, що ви очікуєте від свого кінцевого продукту; різниця між середнім продуктом та чудовим продуктом покладається на деталі. Автомобіль на кшталт Tata Nano та автомобіль на кшталт Mercedes S "виконує роботу" - він перевозить вас з одного місця в інше. Різниця покладається на деталі: потужність двигуна, комфорт, безпеку та інші. Це те саме з будь-яким наявним продуктом, включаючи програмні продукти; наприклад, чому б хтось платив Oracle, IBM або Microsoft за базу даних Oracle, DB2 або MS SQL Server, оскільки MySQL і Postgre безкоштовні?

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


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

@Kai Qing Один клас не має великої різниці (або не повинен). Я сказав це: якщо ви очікуєте, що ваш продукт буде високоякісним продуктом, тоді зверніть увагу на деталі (навіть якщо це означає можливу невелику оптимізацію або ретельний дизайн); з іншого боку, якщо єдине, що ви хочете, - це функціональна система, то, ймовірно, ви не повинні приділяти великої уваги крихітним деталям.
m3th0dman

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

1

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

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

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

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


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

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

1

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

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

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


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

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

Мені постійно доводиться писати постійний код. Просто в деяких випадках цього не повинно бути. Однак у мене є багато досвіду, тому я зазвичай знаю, коли і де вирізати кути. Суть цієї публікації полягала в тому, щоб просто розпалити розмову про поріг належного і неохайного з будь-якою метою. Мій приклад лише злегка кидає його, оскільки наведений приклад здебільшого нешкідливий у меншому застосуванні. Однак, якби я писав банківське програмне забезпечення, я ніколи не був би таким недбалим.
Кай Цін
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.