Чи варто мені турбуватися, якщо мій коефіцієнт LOC / день занадто високий? [зачинено]

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

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

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

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

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

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

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

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

Найкращий спосіб уникнути дилеми, поставленої у вашому запитанні IMHO, - це забути про LOC та рефактор ВСІХ часів. Спершу напишіть свій тест коду, застосуйте його до відмови, пройдіть рефактор, потім подивіться, що там може бути відновлено, а потім вдосконалити код. Ви залишите завдання, знаючи, що ви вже двічі перевірили свою роботу, і не будете так перейматися тим, що вдруге здогадаєтесь про себе в майбутньому. Реально кажучи, якщо ви використовуєте тестовий перший підхід, як я описав, будь-яке вимірювання LOC / день на вашому завершеному коді дійсно означатиме, що ви написали 3-5 разів відміряну суму, при цьому ці зусилля успішно приховані вашим поточним рефакторингом зусилля.

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

Щоденний LOC нічого не каже вам, крім того, що завдання на цей день можна було виконати за допомогою 400 рядків коду.

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

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

Ви не повинні турбуватися кількістю LOC, який виробляєте за день.

Але вам варто турбуватися:

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

LOC - це "офіційний" показник продуктивності, але аргументи проти його значення можуть бути тривалими (ORM може генерувати 50 000 рядків коду за 3 хвилини, однак, якщо дизайн бази даних помиляється, все, що код може перейти в бін).

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

Деякі посилання про LOC

• Проти: LOC - найбільш безглуздий захід

• До деякої міри нейтральні: Wiki-LOC

• Про (я не згоден з більшою частиною цього, але ви можете поглянути): Економіка масштабу та ліній коду

Ви також вимірюєте кількість копій коду ?

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

Причина: якщо у вашому копії та вставці джерела помилки було виправити всі звичаї копіювання та вставки

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

"Це тече? Чи виглядає це красиво?"