3 речі, що псують програміста

Які 3 речі не дадуть тобі стати кращим програмістом?
Відео про TDD, яке згадував у відео :
"Is TDD Dead" - • Is TDD dead?
Станьте спонсором цього каналу: / @aboutprogramming
Допоможіть каналу розвиватися й отримуйте доступ до ексклюзивного контенту.
Зміст відео:
0:00 - Вступ
0:21 - Перше
3:18 - Друге
8:30 - Третє
🏠 Мої соцмережі:
Жабаскрипт в телеграмі - t.me/jabascript
Я в Твітер - / viktorturskyi
#programming #javascript #програмування #українською

[@maksym.s]

Той рідкий момент, коли стаття на DOU дала рекомендацій дійсного гарного контенту. Дякую за вашу працю!

[@user-ch4vs7hb8n]

Все вірно сказано. Важко дається 3-ій пункт. Багато знаю колег хто зневажливо відноситься до інших. Якщо буде можливість і вам буде цікаво, можливо зробити відео як ви дизайните застосунки, можливо мікросервіси. Цікаво дізнатись які техніки solution design ви приміняєте наприклад для комунікації декількох ізольованих компонент. І можна наприклад погратися з типами ізоляції щоб було зрозуміло що для вас є чинниками зміни транспорту комунікації між компонентами. Також було б цікаво більш глибше зануритись у типи даних. Можливо у вас є приклади з життя де можна застосовувати якісь екзотичні структури даних. Дякую за Вашу роботу! Цікаво дивитись!

[@v.ilchenko]

Про допомогу іншим - дуже життєво. Це як інвестиція, яка в перспективі дуже добре окупається❤

[@ievgenk.8991]

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

[@MrShamanist]

Про якість та те, що якісний код писати швидше і дешевше - це одна із моїх ідей та принципів, котрими я теж керуюсь. Дуже, дуже приємно почути цю думку у вашому відео! Про догматизм та паттерни згадується, що років 12-15 тому на конференціях часто говорили, що Singleton - це антипаттерн. А тепер уявімо DI в OOP та його швидкодію без Singleton. Чи буде це добре працювати і чи має сенс? А можна потренуватись писати stateless код, трохи послухати про функціональні підходи, розділити обробку даних та їх зберігання - і досить швидко вийти на новий для себе рівень.

[@TheGiver0]

Дякую за ваш контент. Круто, що є на кого орієнтуватись в україномовному ІТ просторі.

[@oleksandrlesiuk6239]

Дуже цікаво

[@oleksandrpozniak]

Ох! Аж попустило. 13 років в девелопменті. Наче сходив до психотерапевта. Незважаючи на те, що я не у веб, а у ембедед С/С++ Дякую! Про моки взагалі. Прошу відео, як не зійти з розуму на проекті з певним достатньо великим досвідом не бажаючи ну ніяк йти у менелжмент роками. Залишаючись людиною, що просто любить писати код

[@AboutProgramming]

Мені подобається, що в Гуглі менеджмент й інженірінг це 2 окремим вертикалі й можна зростати як individual contributor (IC) не переключаючись в менеджмент. Але немає навіть вимоги, щоб зростати як IC вище L4. Але відносно IC L6+ (staff engineering), то читаю зараз www.amazon.com/Staff-Engineers-Path-Individual-Contributors/dp/1098118731

[@oleksandrpozniak]

@@AboutProgramming Дякую за відповідь та посилання на книгу

[@andriipolishko1477]

Круте відео, дякую вам! Приємно слухати досвідчену людину, яка говорить про цікаві речі ще й українською)

[@kukunin1]

Гарно сформулював і виразив те, що я довгий час відчував. Круто!

[@mrart5498]

Надихаєшь! Дякую!

[@romannimchuk5073]

Кайф, дякую!

[@antonsalatskyy]

Нарешті норм контент українською 🤩

[@Natalicha1234]

Супер контент! Дякую!

[@namirGO]

Дякую за подібні відео, одразу підписався ❤

[@yarqui]

Вікторе, дякую вам за контент. Душевно.

[@AdminAdmin-sl2qf]

❤❤❤❤❤❤❤❤

[@MS-tb4sk]

Дякую за відео, було цікаво

[@user-vj4lx6bc3i]

Дякую дуже за відео! Було корисно почути, радію що є такі програмісти - людяні та професіонали)

[@andrednepr]

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

[@AlexCage19]

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

[@asolokh]

Дуже корисні поради * український контент = підписка

[@user-du4rf1bu2o]

Моя персональна догма: "Ніяких деплоїв в п'ятницю"

[@dmytrofiialo4818]

Віктор, вітаю із створеннямм свого каналу!

[@AboutProgramming]

Дякую!

[@mrart5498]

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

[@AboutProgramming]

Я колись хотів зробити курс по розробці й показати всі аспекти проектування на прикладі якоїсь системи. Можливо частина курсу попаде на канал просто в форматі окремих відео

[@mrart5498]

​@@AboutProgramming Пам`ятаю, Ви казали, що хотіли зробити курс, але так і не доходили руки. То виходить він вийшов?

[@AboutProgramming]

@@mrart5498 курс ні, а от план для курсу є. Ось якраз хочу взяти з нього теми для відео на канал

[@mrart5498]

@@AboutProgramming Зрозумів! Дякую, будемо чекати :)

[@ALEKS09FMF]

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

[@viktoriia809]

привіт! цікаве відео, сподіваюсь що на каналі буде ще багато нових. була б цікава твоя думка про різницю між сіньйором, мідлом і джуном, які умови потрібно виконати для себе щоб "підняти ранг" :) так, різні компанії у вакансіях окреслюють типу сіньйор = досвід 5+ років, але ж ми знаємо що пишуть одне, а насправді очікування можуть відрізнятись. а десь 2 роки роботи більш продуктивні і розвиваючі, ніж 5 років в іншій. Тому цікаво, як ти посвячюєш дева в сіньйори)

[@AboutProgramming]

Дякую! Це цікава тема. Насправді, в тому самому Гуглі не вимагається, щоб розробник ріс вище мідла. Всі мідли, яких я знаю персонально, це 8-12 років досвіду. Сеніор з України з 5 років досвіду часом попадає в Гугл на позицію джуна, але буває, що на джуна потрапляють й після університету. Тобто кількість років досвіду це не те, що забезпечує "ранг"

[@viktoriia809]

@@AboutProgramming от і цікаво, як розуміти де ти є і до чого реально/посильно прагнути. Як є у вивченні мов, іспити на рівні В2/С1, тільки для розробників, були б круті) хоча може такі і є, але я про них не чула

[@AboutProgramming]

@@viktoriia809 Часто в великих компаніях є engineering ladder з описом всіх вимог до кожного рівня. Але зазвичай логіка проста. Чим вищий рівень, тим більший твій імпакт очікується на проект й ти отримуєш задачі з більшим ступенем невизначеності

[@nazarlesyuk2705]

цікава тема роботи з часовими поясами на фронті, особливо цікавить варіант коли потрібно переводити час в часові пояси які юзер вибирає з ddl

[@AboutProgramming]

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

[@ruslantropin5712]

Привіт, хотів би почути як ти готувався до проходження інтерв‘ю в Гугл.

[@van777ok3]

Привіт, крута тема та подача! Мені цікаво було б почути, як опанувати кілька стеків та набратись на них комерційного досвіду. Я пишу на php, але вивчаю с#. Як можно залишаючись на одній основній роботі, влаштуватись на іншу з новим стеком. Окрім парт тайм. Може є якісь лайфхаки чи іх досвіду шось підкажеш. Хочу відійти від певного стеку і стати інженером, а не кодером

[@sezam-zz6lf]

Гірше за программіста, що не читав "чистий код", тількі программіст, який щойно прочитав. ))

[@YuriiYermolenko]

Дякую за супер цікавий контент 👍🏻 У мене питання про зіпсутих програмістів. Я багато цустрічав людей які вже мають багато років досвіду (іноді 20+) але відчуття запаху у них відсутнє 😂😂😂 і при цьому вони іноді займали такі самі позиції як і я (у мене майже 10) а іноді і вищі. Можливо вони ніколи не працювали на великих проектах, але мені бувало складно пояснити переваги базових best концепцій (тестування, single responsibility, мовчу про DDD) бо "код і так функціонує" і "який сенс всьго цього оверхеду". Я прийшов до висновку, що можливо вони і праві і для малих проектів це ок, мати низьку якість. Немає сенсу спорічатись з людьми які не хочуть навчатися... Я б дуже хотів працювати з людьми які знають більше (DDD гарний індикатор доречі). Думаєш це можливо тільки в big tech?

[@AboutProgramming]

Точно не тільки big tech. Відносно питання явного розміру має бути проект, щоб варто було вкладатися в якісь, то зазвичай через пару тижнів говнокоду швидкість сильно уповільнюється. Є стаття цікава на цю тему martinfowler.com/articles/is-quality-worth-cost.html

[@slavapinchuk4829]

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

[@AboutProgramming]

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

[@oleksandr.demianenko]

Хотілося б відео з прикладами говнокода)

[@rusiklusik8451]

І догматизм і говнокод це про інтелектуальну лінь. Особисто я можу кілька разів переписати код, поки він мені почне подобатися. Але це все робота головою. Те саме і про догматизм, зазвичай догматики не замислюються чому так. Тому я би узагальнив - треба вмикати голову, робити це постійно і свідомо. :) Але тих хто так роблять зазвичай дуже мало в соціумі взагалі :(

[@AboutProgramming]

Гарне узагальнення. В цілому згоден. Як кажуть: "в будь-який незрозумілій ситуації - думай". Я спроектував досить багато систем й є багато схожих, але кожен раз доводиться багато чого продумувати по новому :)

[@dimasamchuk4733]

насправді, за 3 роки, які я працюю з AI я втратив здатність писати придатний до підтримки код це, насамперед, пов'язано з тим, що безліч ідей треба дуже швидко прототипувати. Це біль.

[@AboutProgramming]

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

[@Epic0n]

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

[@AboutProgramming]

Насправді, це вже про перфекціонизм. Я би не став ділити код на 2 групи - або "ідеальний" , або "говнокод". Є ще багато гарного коду, який існує посередені й не є говнокодом. Й важливо не плутати технічний борг й говонокод - це теж про різне

[@v.ilchenko]

@@AboutProgrammingв моєму розумінні гамнокод часто (завжди) призводить до технічного боргу. Банально нову фічу додати займатиме вічність

[@AboutProgramming]

@@v.ilchenko на практиці технічний борг виникає при написанні будь-якого коду

[@new_avangard]

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

[@AboutProgramming]

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

[@Epic0n]

Проблема догматизму в реакт, в тому що куди не плюнь в редакс попадеш )))

[@AboutProgramming]

Дуже часто це не про догматизм, а про зважене рішення (не обовʼязково технічне навіть, моживо чисто бізнесове)

[@shinobi_313]

а як боротись з фразами «історично склалось», «так зробили не чіпай», «зроблю окремим тікетом»? особливо коли ти нова людина, яка наче ще бачить «code smells» і вказує ще як іх змінити… брати перероблювати тихенько і вигоряти, чи тупо іти далі?

[@AboutProgramming]

Так це стандартна історія. Окремим тікетом не так погано. Тут головне, щоб завести цей тікет в систему й періодично їх переглядати й брати в роботу. Тобто, щоб був свідомий менеджмент технічного боргку. Відносно чи тихенько перероблювати й вигоряти, то тут складне питання. Від говнокоду часто страждують навіть ті, хто його створює. Буває таке, що розробник говнокодить, а потім такий "я не хочу на цьому проекті більше працювати, бо тут суцільний говнокод". Тому тут важливо, щоб всі розуміли цінність від більш якісного коду. Можу сказати, що технічний борг накопичується й в Гуглових проектах, але через певний час всі починають страждати від нього (фічі повільніше додаються й тд) й доводиться цілі спрінти приділяти виправленню проблем в коді. Тобто найперше питання - це питання цінності якісного коду й чи розуміє команда це чи ні. Й з цього я би почав - обговорити з командою, зробити аналіз проекту, зробити план. Ну й часом бувають речі, які вже може бути дуже дорого виправити - або якісь суттєві архітектурні проблеми, або проект весь в такому стані, що там говнокод утрамбований говнокодом :)

[@user-rm7oz4xu3k]

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

[@gildorgames]

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

[@AboutProgramming]

Так, передбачається, що програма буде розвиватися певний час. Згадав фразу "Якщо ви думаєте, що гарна архітектура це дорого, то спробуйте погану"). В цілому, є певна межа, з якої внутрішня якість починає себе окуповувати. Є дуже гарна стаття у Фаулера на цю тему - martinfowler.com/articles/is-quality-worth-cost.html яка каже, що внутрішня якість продукту починає себе окуповувати не через місяці, а через тижні. Багато разів бачів, коли низька якість призводили до проблем й значного зростання строків імплементації. Тобто, я не можу сказати, що низькоякісний код це дешевше підтримувати й швидше додавати нові фічі. Скоріше навпаки, якісний код призводить до більше швидкого додавання нових фічей й більше дешевої підтримки

[@IhorVyshniakov]

5:33 що значить "мОкати"?

[@AboutProgramming]

Від англійського Mock - en.m.wikipedia.org/wiki/Mock_object

[@eolit1o]

Я почав читати дуже цікаву книгу "Выход из кризиса" Деминг Эдвардс. Він ставе на перше місце якість. Кажуть що він той самий хто зробив з Японії чудо. Не гроші змінили Японію, а зміна процесів. Ось я хочу перекласти, доказати цю ідею у програмуванні. Дати визначення говнокоду, виміряти говнокод у "попугах".

[@AboutProgramming]

Є різні метрики складності/якості коду типу McCabe complexity та інші. Й вони можуть показати проблеми з кодом, але не можуть довести, що код якісний (окрім того проблема якості може бути в ідельно написаному коді, який просто не оперує тими самими сутностями, що й бізнес). Це як з тестуванням. Тестуванням можна довести наявність багів, але не можна довести іх відсутність. Й є схожа історія з продуктивністю розробника (martinfowler.com/bliki/CannotMeasureProductivity.html). Тут основна проблема, що як міряєш, то так й пишуть :) Але є ряд показників, який дозволяє оцінити якість коду через якість процесів. Взагалі, цікаво було б побачити якийсь робочий підхід, задача досить складна. За книгу дякую, подивлюся - теж цікаво

[@eolit1o]

@@AboutProgramming дякую за лінку. А у вас є телеграмм чи якийсь чат?

[@AboutProgramming]

@@eolit1o чомусь ютуб вирішив, що коментар схожий на спам й я його тільки зараз побачив. Так, є телеграм канал - t.me/jabascript (в описі каналу є лінк на мій телеграм теж)

[@user-gm5lk6us2i]

ахаха, не гроші і не мафія, ага)))

[@eolit1o]

@@user-gm5lk6us2i так. Є ще крута книга Японське економічне чудо Чалмерса.

[@Poodrdt]

- говнокод - догматизм - зневажливе ставлення до колег

[@AboutProgramming]

Нажаль, просто список не розкриває суті

[@user-dq5yx3cq3f]

Вже досить розуміти про що мова йде в цьому відео і ти вже класний програміст 😅

[@AboutProgramming]

😄

[@donutWiggum]

Про догматизм прямо в точку

[@MasterSergius]

Насправді, є дві речі, які псують програмістів: аджайл і ефективні менеджери

[@AboutProgramming]

Ось 12 принципів з аджайл маніфесту agilemanifesto.org/iso/uk/principles.html . Чому це псує програміста?)

[@MasterSergius]

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

[@AboutProgramming]

@@MasterSergius тобто аджайл не працює бо комунізм не працює?

[@MasterSergius]

​@@AboutProgrammingдивний висновок, ну добре, хай буде

[@AboutProgramming]

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

[@eugenefedorov3498]

Я соло програміст фріланс фул стек 12 років. Php js зараз react більше. Жодної книжки не прочитав. Рейт 100$. Щоб ви могли порекомендувати мені щоб писати кращій код? Топ 1 книжка по проектуванню?

[@AboutProgramming]

Я не знаю, як ви пишите код, то тут мені складно порекомендувати, що саме треба покращити. Ну й мабуть щось читали за цей час, просто не в форматів книг. На каналі робив одне відео про книги - kzbin.info/www/bejne/pmjEqKB9jp6sq9Usi=UFKe03u0T8h_1ytP Також після DDD Еванса є ще "Implementing Domain-Driven Design" Вернона - доповнює Еванса різними практичним підходами (можно й тільки її). Просто обирайте ту одну, яка виглядає найбільш цікаво й по темі якої найменше знаєте

[@eugenefedorov3498]

@@AboutProgramming дякую. Код пишу не дуже, але ті архітектури яки я бачив, мені не подобаються. Думаю що не існує ідеальної. Але краще знати пару для різних випадків. І краще знати гарно пару аніж трішки багато різних. Ви казали що є укорочена версія DDD? Як вона називається? А ще я так і не зрозумів як вивчити глибше то, чим ми вже користуємось, https, linux, node, chrome ітд. І я о думаю, чи не буде таке поглиблення шкідливе, так як технології міняються, і через деякий час те шо ти поглиблювався і зробив висновок що краще писати Б ніж А вже не актуально з 156.2 версії Хрома. Чи не вважаєте ви це розпилюванням уваги?

[@AboutProgramming]

Є непогане самарі www.infoq.com/minibooks/domain-driven-design-quickly/ й DDD Distilled www.amazon.com/Domain-Driven-Design-Distilled-Vaughn-Vernon/dp/0134434420

[@gradient8516]

+

[@heavydirtysoul1491]

Дедлайни > чистий код

[@AboutProgramming]

Так й є. Але це не значить, що "дедлайни = говнокод" 🙂

[@nas1k]

Де слова Кент Бека?

[@AboutProgramming]

А що він казав?)

[@nas1k]

@@AboutProgramming так у відео ж є про те що він казав що дуже рідко мокає тести. Хотів це показувати фанатам моків 😂

[@AboutProgramming]

@@nas1k ааа)) Так, серія відео "is TDD dead". Тут посилання на всі частини martinfowler.com/articles/is-tdd-dead/

[@bidanfullko1]

А чого прагне гугл? Вкурсі його політики розвитку? Нащо йому захоплювати інтернет?

[@AboutProgramming]

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

[@Sernuzh]

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

[@AboutProgramming]

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

[@xforeal-dj2jt]

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

[@AboutProgramming]

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

[@artemzabolotnyi3838]

10 год тюрми за гавнокод

[@artemzabolotnyi3838]

Най ідуть н🦆й з тими ES модулями. некомпатибільна 🚽

[@AboutProgramming]

ESM вже норм)

[@kisyakkisyak7708]

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

[@AboutProgramming]

Таке враження, що це якась особлива ситуація :) Практично всі проекти запускаються в умовах обмежений ресурсів, навіть в Google. Я запустив більше 50-ти проектів й для стартапів й для великих компаній типу Mercedes/Uber/Pfizer й всі хочуть дива. Відносно якості, то в розробці софта часто якісний код це дешевше й швидше, якщо проект триває більше місяця. Класна стаття була у Фаулера - martinfowler.com/articles/is-quality-worth-cost.html Окрім того, дуже допомогає стандартизація процессів, кодовой бази, архітектури. Робив колись доповідь про стандартну архітектуру - kzbin.info/www/bejne/ipvZenidd6irkNE