+

Хто знає коли вже дженеріки запиляють? Це просто капєц без них ))

Також пишу todo в коді і стараюсь робити continuous refactoring. Але є один нюанс. Це не завжди можливо. Ось вам приклад. Ви заюзали якусь бібліотеку, все ок, все працює. Через якийсь час у вас трошки міняється умова а бібліотека не дозволяє її виконати. Відповідно вам треба викинути цю лібу, переписати клієнтських код і тести і аж потім робити фічу. Це може зайняти багато часу. Або варіант 2: написати костиль/хак і відкласти рефакторінг. От тут і починається проблема. Рефакторінг займе багато часу відповідно на коли його відкласти хз. У цих випадках я користуюсь цією самою технікою що описана в статті. Думаю тікети з поміткою тд норм штука ;)

Треба буде покласти ще раз code sniffer. Не можу знайти фіксера для UnnecessaryStringConcatSniff

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

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

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

У кожнїй спільноті/команді свої стандарти якості коду.

Viktor я бачу 2 типи костилів.
1. Не можливо реалізувати по іншому так як не має достатньо часу. Цей випадок виправляється просто. Знайдіть час і виправте якщо потрібно. Якщо не потрібно тоді який сенс читати статті про хороший код ;)

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

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

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

Для опенсорс проектів використовую scrutinizer-ci.com. Рекомендую всім. ;)

Хто Вам мішає заюзати якусь нову фішку рнр при вирішенні задачі і розібратись з нею? Як на мене це і буде навчання за яке платять ;)