Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Топ-10 рис програміста-професіонала. Огляд книги Clean Coder Роберта Мартіна

Привіт! Мене звуть Михайло, я працюю Senior Software Engineer у компанії Plexteq. Одним з моїх основних професійних інтересів є тема розвитку себе як технічного спеціаліста і прагнення до technical excellence.

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

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

Програмісти-професіонали — хто вони?

Розпочнемо з простішого питання: хто такі програмісти? Очевидно, що це люди, які створюють програмне забезпечення. Багато хто з нас спробував програмування ще у школі або університеті, і з того часу став дивитись на світ інакше. Чи стали ми в той момент програмістами? Звісно, що так. Чи стали ми програмістами-професіоналами? Звісно, що ні.

Так що ж відрізняє програміста-професіонала від просто програміста? Отримання заробітної плати за свою роботу? Тлумачення можуть бути різними, але Роберт Мартін, також відомий як «дядько Боб», з таким визначенням ні в якому разі не погодився б.

Сьогодні я хотів би обговорити з вами його думки з цього приводу, викладені у книзі Clean Coder. Я обрав топ-10 його ідей, які, на мій погляд, підсумовують найважливіші риси програміста-професіонала.

1. Постійне навчання

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

Роберт Мартін вважає, що на таку діяльність необхідно витрачати близько 20 годин на тиждень (додатково до 40 годин, протягом яких ми працюємо на основній роботі). Щобільше, на його думку, — це єдиний можливий шлях не вигоріти. Це доволі суперечливе твердження, однак, звісно, час на самоосвіту виділяти необхідно. Якщо правильно підібрати матеріали, то самоосвіта може стати тим, що підтримує інтерес до професії, особливо тоді, коли справи на проєкті йдуть не надто цікаво.

2. Вміння казати «так» і «ні»

Do, or do not; there is no try. Програміст-професіонал вміє дотримуватись свого слова. Він повинен вміти казати «Ні». Наприклад, якщо програміст-професіонал бачить, що виконати задачу у поставлені строки без завдання шкоди продукту неможливо, він комунікує своє розуміння менеджменту. Це частина його професійних обов’язків.

Не менш важливим є вміння казати «Так». Якщо програміст-професіонал обіцяє, що він щось виконає — він повинен це зробити. Перед тим, як зробити таку обіцянку, необхідно зважити, як саме буде досягнуто поставленої цілі.

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

3. Вміння робити естімейти

Програміст-професіонал знає, що таке естімейт і вміє, у рамках обговорення з командою, чесно естімейтити задачі. Важливо розуміти, що естімейт — це не точкова оцінка. Естімейт майже завжди являє собою розподіл ймовірностей. Саме тому дядько Боб розповідає про Program evaluation and review technique, в рамках якої надається три естімейти: оптимістичний, реалістичний і песимістичний.

Не варто забувати і про популярний Planning Poker. Загалом, яку б техніку оцінювання складності задач ми не використовували, важливо пам’ятати, для чого естімейти існують як такі. Основна задача естімейту — надати менеджменту якомога точнішу інформацію про складність задачі, що дозволить краще спланувати майбутню ітерацію і краще розуміти «швидкість» команди.

4. Знання продукту і предметної області

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

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

5. Test-Driven Development

Програміст-професіонал намагається створювати якомога якісніший продукт. TDD є тією технікою, яка, при правильному використанні, призводить саме до такого результату.

«Чи можемо ми вважатись професіоналами, якщо не знаємо, чи наш код працює? Як ми можемо це знати, якщо не тестуємо наш код після найменших змін? Як ми можемо проводити таке тестування, якщо у нас немає автоматизованих unit-тестів з високим відсотком покриття? Як нам отримати такий набір unit тестів не використовуючи TDD?» — питає дядько Боб.

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

Я розумію, що серед усіх топ-10 рис програміста-професіонала, ця може викликати найбільшу незгоду. Попри це, я б радив усім, хто цього ще не зробив, спробувати TDD хоча б протягом декількох місяців. Одні з найрозумніших програмістів світу (Боб Мартін, Мартін Фаулер, Кент Бек і багато інших) рекомендують TDD. Навряд усі вони помиляються

6. Time management

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

Цікавою технікою для цього є Pomodoro. Pomodoro — схема роботи, при якій робочий день розбивається на короткі (близько 25 хв) продуктивні відрізки, між якими робиться 5-хвилинна пауза на відпочинок. Після кожного четвертого такого відрізка робиться довша пауза на відпочинок (близько 15-30 хв).

Під час продуктивного відрізку не рекомендується відволікатись на інші активності (навіть на відповіді колегам у чатиках, якщо їх повідомлення не є терміновими). Це дозволяє легше тримати фокус і бути сконцентрованим на конкретній задачі. Після прочитання Clean Coder, я почав використовувати Pomodoro і поки що задоволений результатами.

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

7. Менторство

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

8. Практика

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

Як на мене, аналогія трошки натягнута, але немає ніяких сумнівів, що практика (так само як і постійне навчання) йдуть на користь програмісту. Серед найпоширеніших способів тренування можна виділити роботу над pet-проєктом, написання коду для open source проєктів тощо. Дядько Боб також говорить про так звані Dojos і Katas — короткі вправи, які дозволяють вдосконалювати свою вправність у, наприклад, TDD.

9. Стратегія тестування

Програмісти-професіонали активно пропагують і беруть участь у створенні автоматизованої стратегії тестування. Дядько Боб любить вираз «QAs should find nothing». Звісно, це максима, якої складно досягти, однак варто намагатись до неї асимптотично наближатись. Автоматизоване тестування сприяє цьому.

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

10. Вміння працювати під тиском

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

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

👍ПодобаєтьсяСподобалось20
До обраногоВ обраному15
LinkedIn

Найкращі коментарі пропустити

Так що ж відрізняє програміста-професіонала від просто програміста? Отримання заробітної плати за свою роботу?

Відповідь «так». Розходимось.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Я щось не зрозумів, цю книгу варто почитати чи ні?)

Безумовно варто — як приклад того, як не треба робити, но як треба розповідати іншим (навіть клеїти QA-дівчиноньок).

Эти трое, судя по содержанию их книг, вообще не одупляют реальное программирование. Линус Торвальдс — программист. Эти трое — нет.

software engineering != programming

капец ну звідки стільки неуків, можна подумать мартіна чи торвальдса взагалі колише, що про нього сказав Dou Dou

Эти трое — нет

троє хто?

Одні з найрозумніших програмістів світу (Боб Мартін, Мартін Фаулер, Кент Бек

ну трєпачі й писаки, жить както надо і після 40

тим не менш, культові трєпачі й писаки

це бл як сказать, шо ньютон ламо, бо не шарить, як яблуко падає

формула вот неточная, вот ейнштейн фізік, а ньютон нєт

Скільки книжок написав Торвальдс?

Одні з найрозумніших програмістів світу (Боб Мартін

Це Боб сам себе вихваляє, чи автор статті постарався?

Програміст-професіонал намагається створювати якомога якісніший продукт. TDD є тією технікою, яка, при правильному використанні, призводить саме до такого результату

Звідки така впевненість?
А якщо розробник пише код, а потім тести (і у нього покриття під 100%), то він матиме неякісний продукт/код?

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

захардкодити якусь залежність, а потім «ой а як це тепер тестувати»

класний пойнт, до речі

tdd форсить писати srp-код який легко тестується

А про те, що якщо ти спочатку пишеш контракт

Коли його ще не знаєш, бо все зміниться 10 разів.

то ти теоретично робиш меньше дурні та зайвих рухів

А ще ти бог бо знаєш що писати з самого початку.

TDD звісно не срібна куля

А Кент Бек і Боб Мартін пропагандують інше...

В Кента Бека досить адекватне бачення TDD, до речі. Ось цитата з його інтерв’ю:
“If you’re in exploration mode and you’re just trying to figure out what a program might do and most of your experiments are going to be failures and be deleted in a matter of hours or perhaps days, then most of the benefits of TDD don’t kick in, and it slows down the experimentation”

В Кента Бека досить адекватне бачення TDD, до речі. Ось цитата з його інтерв’ю:

Ну всього-то років 20 пройшло, як зʼявилось перше «ну можуть бути винятки...» Але дякую, залишу в копилку.

If you’re in exploration mode

Справа в тому, що «exploration mode» зараз ледь менше аніж скрізь. Місць, де можна наперед визначити всю функціональність до розробки хоча б прототипу — настільки мало, що після студентських часів я їх не памʼятаю.

and most of your experiments are going to be failures and be deleted in a matter of hours or perhaps days

У мене зазвичай «most of experiments» мають зберігатись і ставати основою подальшої розробки (мабуть, після переобмислення і рефакторінгів, але видаляти і починати з нуля ніхто і ніколи з таким не буде).

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

Справа в тому, що «exploration mode» зараз ледь менше аніж скрізь. Місць, де можна наперед визначити всю функціональність до розробки хоча б прототипу — настільки мало, що після студентських часів я їх не памʼятаю.

це звісно 146% тому що зараз скрізь агілє і ні якого планування проектування архітектурування тощо усе гнучке і вкладається у рамки спрінта за якими усе може «півотититься» у різні боки здебільшого хаотично як метод гнучкого досягнення цілі якої ніхто не може назвати

У мене зазвичай «most of experiments» мають зберігатись і ставати основою подальшої розробки (мабуть, після переобмислення і рефакторінгів, але видаляти і починати з нуля ніхто і ніколи з таким не буде).

тоді до чого тут тдд якщо

most of your experiments are going to be failures
це звісно 146% тому що зараз скрізь агілє

Да.

і ні якого планування проектування архітектурування

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

хаотично як метод гнучкого досягнення цілі якої ніхто не може назвати

Може. Але с третього-четвертого підходу, коли вже більше половини роботи зроблено.

тоді до чого тут тдд якщо

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

Приєднуюсь до відповіді що TDD це не про процент покриття. Test-driven development, як слідує із назви, це про спосіб розробки програмного забезпечення, який стимулює гнучіксть, постійний рефакторинг, розробку highly cohesive and loosely coupled модулів і має багато інших плюсів.

Але якщо ми вже заговорили про покриття — покриття буває різним. Statement coverage — це добре, але TDD, через свою сутність призводить до того, що нам доводиться створювати код із кращим decision/condition coverage. Саме до цього нас стимулюють три кроки TDD (особливо перші два). TDD — це часто про дисципліну.

Так, бо як він пояснити клієнтові що фіча в проді нетестована і треба знову виділити на неї час для тестування рефакторингу? А де дев знайде час для цікавого теста якщо фіча уже написана? Клієнт рідко коли хоче працювати із технічним боргом. А потім просто продає забажений продукт. А що значить 100% покриття при нетестованних сторонніх залежностях, а при кривих деплоймент скриптах чи при коллезі який «поправив конфігурацію» і усе впало. Код це ніколи не кінцевий продукт. Я бачу як люди працють без ТДД, а потім бачу неінформативні повідомлення в виключеннях, які змушують дебажити. Наївні тести і в основному позитивні сценарії. Задача ТДД привчити розробника до розуміння як код та продукт можуть зламатися виправити те що може зламатися і красиво опрацювати те від чого не можна позбутися. І все це до того як він це зальє в прод а не о 3й годині ранку на саппорті

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

Якщо ви так стверджуєте, то цілком очевидно, що ви погано знаєтеся на тому, як влаштовано ІТ.
Програміст — це людина, яка пише код. А ось люди, які створюють продукт (або програмне забезпечення) — це розробники. Ну або software engineer.

Хм, можливо я допустив семантичну неточність. Під програмним забезпеченням я мав на увазі будь-яку робочу программу — навіть найпростішу. Чи робити з цього висновки щодо того, чи «погано я знаюсь на IT» — це вже вирішувати не мені.

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

Програміст — це людина, яка пише код

Це кодер.

А програміст — глобальне поняття.

що ви погано знаєтеся на тому, як влаштовано ІТ.

Ну на тому, як галері продавати дупочаси — мабуть, да, погано.

Не існує професії «кодер». Людина, яка пише код — це програміст

І ви таки можете це довести?

Ось про який паноптикон каже Фуко.

Я б зробив огляд альтернативного топ 3 thethreevirtues.com але перша риса мені забороняє.

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

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

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

імхо звісно..

фокусуватися на максимізації своєї ефективності яку міряти від своїх особистих цілей в житті

З цим повністю погоджуюсь, краще мабуть і не скажеш

Дякую, що читаєте!

А де тут стаття? Це просто короткий огляд іншої книги

Дякую за ваш час! Ваша думка дуже важлива, залишайтеся на лінії...

Так що ж відрізняє програміста-професіонала від просто програміста? Отримання заробітної плати за свою роботу?

Відповідь «так». Розходимось.

Зараз тільки 2 риси залишилось, і другої у книзі нема ))

1) дотримується дедлайнів
2) зайчує

Депресивно, як на мене. Професійний програміст — людина без родини, хоббі, спорта та відпочинку. 8 годин — робота, 4 — кодінг, 8 — поспати (хоча на фіг спати? ти ж професіонал) й лишається на все 4 години. Щодо п8 — взагалі тупість. Змагання кожен день по 8 годин. Мабудь автор ніколи не брав участи в змаганнях, бо не розуміє, скільки треба часу атлету для підготовки до виступу. Інші поради наче норм, але цей пункт ну прям капец вибісив. Ну й дякую за огляд — читати книгу не буду )) Бо часу на це нема, а я вже півгодини пишу цей коментар))

Попрактикуйтесь над вдосконаленням швидкості набору

Дякую за пораду, яку в вас ніхто не просив.

Вас теж ніхто не просив відповідати на мій коментар ;)

Так копати вiдcюди до 8 + 4 годин)

Професійний програміст — людина без родини, хоббі, спорта та відпочинку. 8 годин — робота, 4 — кодінг, 8 — поспати (хоча на фіг спати? ти ж професіонал) й лишається на все 4 години.

Welcome to America! Саме звідти цей Дядько Боб.

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

I am not talking about all your free time here. I’m talking about 20 extra hours per week. That’s roughly 3 hours per day. If you use your luch hour to read, listen to podcasts on your commute, and spend 90 minutes per day learning a new language, you’ll have it all covered.

Знову ж таки, навіть з такою інтерпретацією я не погоджуюсь (під час обіду краще їсти і спілкуватись з колегами/друзями/сім’єю, півтори години на день може бути забагато і тд), але 5-10 годин, думаю, знайти цілком реально (особливо якщо враховувати подкасти).

Так, тоді це абсолютно ок. Мені здалося, що мається на увазі саме 20 годин кодінгу, тому й трігернуло. А подкасти — це ок, це гуд, давайте більше подкастів ;)

Стаття супер, коротко і зрозуміло 👍

Дякую, дуже приємно :)

Я погоджуюсь, що TDD на початкових стадіях несе деякий overhead. Але: 1) TDD можна тренувати, і з часом overhead стає меншим 2) переваги TDD економлять час у майбутньому. Ну і код виходить якіснішим.

Ну і код виходить якіснішим.

Якіснішим чи краще відтестованим?

Why not both? Під час юніт-тестування коду ми, по суті, стаємо першими його користувачами. Це призводить до того, що у коду стає менше залежностей, і ці залежності найчастіше подаються зовні (інакше їх складно мокати), модулі стають більш цільними (для прикладу, якщо ми порушуємо SRP, це стає очевидним під час тестування). Крім того, рефакторинг — невід’ємна частина TDD (first make it fail, then make it work, then make it right). Загалом, TDD сприяє тому, що ми проводимо більше часу думаючи про код, а це однозначно йде йому на користь.

TDD допоможе у цьому щоб код був гарно поформатований, назви змінних і методів були адекватними?

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

У вас кожне наступне питання скасовує попереднє. Ви вже визначтеся, на що хочете отримати відповідь

Зачем мыть руки? Это поможет выплатить ипотеку? =)

Код не працює сам по себе. Бо зараз вже завжди є якийсь бекенд, чи сторонній сервіс, на роботу якого команда не впливає. І для повноцінного тестування, потрібно робити тестове дзеркало API. Яке теж підтримувати, та лагодити, бо тести мають таку особливість — вони сцуко, увесь час ламаються. Тобто TDD — це розкіш, яку не кожен власник продукту може собі дозволити.

Яке відношення має TDD до «сторонніх сервісів» ?

Таке, що без повноцінного тестування end-to-end, ні про яку якість мова не йде. Це просто даремно витрачений час.

Змішалися коні й люди

без повноцінного тестування end-to-end, ні про яку якість мова не йде. Це просто даремно витрачений час.

Чорнобіла маячня

ви колись рефакторили код без покриття чи з покриттям пізніше на отєбісь?

ви колись рефакторили код без покриття чи з покриттям пізніше на отєбісь?

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

Ну в мене інший досвід

Загалом я й сам не люблю фанатизм, але і TDD має багато сенсу на довгих дистанціях

Я лише можу погодитись, що юніт-тести корисні, якщо продукт — це фреймворк, або мова, або в загальному випадку, якесь публічне API. Наприклад Qt або Python. Де важливо, щоб була забезпечена зворотна сумісність, а також щоб користувачі могли протестувати власні збірки. І навіть в цих випадках, test suite що поставляється, не відпрацьовує на 100%, і це вважається норм. В інших випадках, TDD ніякої якості не забезпечує, окрім того моменту, коли воно пишеться вперше, бо занадто багато складових частин. І чим витрачати час на підтримку юніт-тестів, та оцієї mock/stub інфраструктури, краще вкластися в автоматизоване тестування по usecases, а також в функціональне тестування на рівні фіч продукту. Оце дійсне дає якусь впевненість в якості. Ну і також відділ manual QA в ідеалі.

І чим витрачати час на підтримку юніт-тестів, та оцієї mock/stub інфраструктури, краще вкластися в автоматизоване тестування по usecases

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

В інших випадках, TDD ніякої якості не забезпечує, окрім того моменту, коли воно пишеться вперше, бо занадто багато складових частин

Юніт-тести не мають прямої залежності від TDD. Якщо навпаки, то так. Але ви все перемішали в одну купу.

Мені здається ви плутаєте TDD й топорне якесь покриття тестами бо погонич вимагає метрики й зелені галочки

TDD ніякої якості не забезпечує

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

чим витрачати час на підтримку юніт-тестів, та оцієї mock/stub інфраструктури, краще вкластися в автоматизоване тестування по usecases

Ну окай допустім але ви пишете test usecases ДО чи ПІСЛЯ?

оцієї mock/stub інфраструктури

Емм, якої такої інфрастуктури???

У мене відчуття стійке що ми про різні речі сорі єсішо

Ну окай допустім але ви пишете test usecases ДО чи ПІСЛЯ?

Коли писали, то це було після. Бо складно тестувати те, чого ще нема.

Емм, якої такої інфрастуктури???

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

А на продакшені прийдуть інші дані і все зламається :)

Юніт-тести

Не

потребують заздалегідь підготовлених даних

І також не

треба робити фіктивні імплементації інтерфейсів та підсистем. Пхати їх в DI контейнери і оце все

Там, де це треба як мінімум робити, називається інтеграційними тестами

Ну це не tdd )) чуйка не підвела

Бо складно тестувати те, чого ще нема.

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

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

юзкейси це частина bdd, яке виросло з tdd

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

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

тести потребують заздалегідь підготовлених даних

ну звісно але коли їх придумуєш то знову ж таки краще розумієш, що писати теж

Банально приклад, коли тобі треба якісь карренсі обробляти, ти починаєш думати, а ага, а що якщо формат в іншій локалі, а як роздільники є, а якщо прийде з символом валюти, а як не на початку а в кінці, а що як від’ємна прийде, а якщо 0.00 а якщо 0, а якщо гарбедж якийсь, а якщо а якщо ітд

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

Емм, якої такої інфрастуктури???

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

Читай бека, чи пробуй сам, бо мені якщо чесно очевидно що ти не про tdd

100%. Единственно полезными бывают, когда нужно сложную логику всяких хелперов для манипуляций с датами, временем, таймзонами не сломать.

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

ну, якщо використовувати TDD, то дійсно вийде 40 годин)

поправочка, два тижні по 20 годин замість тижня в 20 годин зараз і 200 годин головняка потім

що ж відрізняє програміста-професіонала від просто програміста

Professional — a person engaged or qualified in a profession.
Дякую за допис, а то вже збирався прочитати цю книжку.

Роберт Мартін вважає, що на таку діяльність необхідно витрачати близько 20 годин на тиждень (додатково до 40 годин, протягом яких ми працюємо на основній роботі). Щобільше, на його думку, — це єдиний можливий шлях не вигоріти.

Путь к антидепрессантам, куче сердечно-сосудистых заболеваний из-за обездвиженности. Ну оно и неудивительно, это же туповатый дядя боб, что даже в силу возраста ума не набрался.

Вiн же не може написати «працюйте не 40 годин, а головою тодi у вас вистачить часу впихнути у 8 год i навчання i роботу» тому що його кенсельнуть)))
На то й голова на плечах щоб брати кориснi поради, а шiдливi iгнорувати)

Так, 100%. Ще такий момент — Марітн точно не писав цю книгу, тримаючи у голові нашу поточну ситуацію, де майже кожен так чи інакше волонтерить, і на це теж потрібен час. Тому так, особисто для мене по суті 60-годинний робочий тиждень не звучить реалістично, і я намагався підкреслити у тексті, що ця думка належить не мені

Дуже дякую за ваше самарі цієї книги!
Також є добра книга, на тему розвитку програміста, як професіонала, Джона Сонмеза, «Шлях програміста». Правда, не знаю, чи робили її український переклад...

То може, пишете нам самарі на цю книгу? ;) Завжди чекаємо на [email protected] або через онлайн-форму dou.ua/forums/new

Ось буквально нещодавно дізнався, що за теорією мсьє Кашкіна сер Мартін у деякому сенсі не шарить у програмуванні: youtu.be/ngyKqzqd2hA

Никогда не используйте TDD??? Рілі?

із задоволенням поставив дізлайк

ху із кашкін і ху із мартін

і фуфуфу руснявий контент

За руснявий контент звісно дізлайк.
За не юзайте TDD прям ніколи теж дізлайк.
Але я проти впровадження цієї методології прям як must have усюди. На мою думку це теж саме що сказати — юзайте мікросервіси, якщо ти не написав жодного мікросервісу то ти не профессіонал і взагалі гівно як людина
Десь воно приносить профіт, десь не приносить, а десь взагалі трохи шкодить (або не трохи)

ху із кашкін

Вперше бачу і чую, але те, що він розповів, в цілому правильно. Коли ще ситуація з вимогами нестабільна, щільне тестування неможливе. Тільки після того, як можна сформувати більш-менш стабільний стан з вимогами і постійну частину коду, є сенс додавати тести.
Звичайно, завжди бувають особливі випадки, але як головне правило треба робити саме так.
(Але — не відкладати тести на «потім»!)

і ху із мартін

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

і фуфуфу руснявий контент

Без політоти — проблема персонально ваша як споживача.

Як мінімум в мене сіпнулась брова

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

проблема персонально ваша як споживача.

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

так само як і доводити що чел, що подарував світу аджайл

Хто? Мартін? Читайте першоджерела.

Навіть якщо визнати його як видатного з 17 співавторів «Agile manifesto», сам маніфест тільки підсумував все, що індустрія наробила за десятиліття до того.

і SOLID

Який має в рази менше визначености і практичної цінности, ніж, наприклад, GRASP.

мабуть скоріше таки шарить нормально в розробці

Ні. Зі всіх соратників він найбільше і найгірше меле язиком без реальної цінности.
Його книги неможливо читати — суцільна маячня і самопротиріччя на кожному кроці.

Раджу пити з першоджерел.

Ось і почніть. Викиньте какашку мартіна і читайте нормальне.

Викиньте какашку мартіна і читайте нормальне.

сіпанулась брова на іншому оці, це тіпа кого, мисьє какашкіна?

Навіть якщо визнати його як видатного з 17 співавторів «Agile manifesto»

А можна без якщо і просто визнати? Не треба видатного, просто одним з авторів?

Про SOLID vs GRASP навіть соромно має бути. Те що вам здається що солід чомусь неважливий не відміняє факт, що його питають зара ледь не на кожному інтерв’ю

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

Це просто безпередметно, рілі

це тіпа кого

В статті про Agile все сказано.
І не треба домислювати всяку хню яку самі ж вигадали.
Або можна Макконнела, Фізерса, на крайняк того ж Бека — вони хоча б не таку некеровану пургу несуть.

А можна без якщо і просто визнати?

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

Це просто безпередметно, рілі

Ось зіткнетесь з мартіноїдами — побачите.

Загальний неконкретизований булшит

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

навєрна штото лічноє

Вау СОЛІД, а код в 24 рази повільніше робе. Так професійно! www.youtube.com/watch?v=tD5NrevFtbU

Вау, проблеми з логічним мисленням на ДОУ. Як несподівано!

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

О є, чистий код зливає говнокоду (обидва в лапках) по перформансу у синтетичному бенчмарку з двома арифметичними операціями — прямо відкриття століття. А тепер уяви, що отакі от «руйнівники міфів» написали велику ентерпрайз систему у такому стилі, а тобі її підтримувати... Різні кейси — різні обмеження.

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

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

Я написав фізбаз і поліморфізм в 24 раза повільніше ніж if/then при компіляції cpp навіть без будь-яких озвучених оптимізацій. Ужас 🫢. Ну шо тут сказать... мабуть це поліморфізм треба оптимізувати, давайте без поліморфізму рєбята, будем писать тоді if/then і єбісь оно коньом, наша мама любіт скорость, не для того я купляв райзєн і він там казав, айфон 14,, щоб на етот ваш поліморфізм размєнівацца

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

я думав ти зайнятий і пишеш десь if/then/else, без солід

де можна у клієнта спочатку гроші за тести стягти, потім напхати проект абстрактними поліморфічними функціями AddTwoNumbers(), за них стягти. Потім за підтримку ще трясти. Так то добра ідея.

звісно добра, саме завдяки тисячам таких нубів-самоуків без освіти, які солід не відрізнять від клін кода, і яким поліморфізм у 21ст раптом занадто повільний, у нормальних про завжди буде робота

В класиці все одно краще
github.com/...​BuzzEnterpriseEdition.git

6650 підписників це, звісно, дооо :-)

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

Так, саме для того я і вчу зараз в поті чола свою шосту мову (німецьку) :-D

Ого, шанування, це прям рівень вже реально недурний!

Заради цікавості. Перша, друга і третя то зрозуміло що укр, англ та м.б. рус. А які четверта і пʼята?

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

У Кашкіна це не теорія, а догма. «Вредная и бессмысленная. Никогда, никогда.» Вже реально лячно стало навіть думати про TDD.

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

Книжки писати не мiшки перекидати)

Моргніть якщо вас тримають у заручниках і примушують писати огляди книг.

Морг... Заручники в кайданах
Читати змушені книжки,
Й статті писати, поки десь весна

Доу хайку :)

Не змушують :) «я займаюсь цікавими проектами, які мені цікаві» ©

Чітко й по поличкам, навіть додати нічого, хоч огляду книги таки не вийшло

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

Поганий стереотип і порада, якщо ми говоримо про інженерів з рівнем професіонала

Дякую!
Ну так, з оглядом у класичному розумінні, мабуть, не склалось, але я постарався викласти свої основні takeaways з книги.

Йопт, це ж про іншу книжку! Сорян, все круто, сліпий на око, схожі заголовки :)

Стаття хороша!

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

Короче лайк!

Підписатись на коментарі