Я частково погоджуюсь, але фразу «університет не повинен вас вчити, він повинен вас навчити вчитись!» часто використовують викладачі, які не здатні дати ніяких знань. Таким чином вони просто виправдовуються.
Проблема навіть не в тому, що університет дає несучасні знання, а в тому, що часто він їх взагалі не дає
Не те щоб я здивований. Люди часто обирають інтереси себе, а не суспільства. Думаю, у 21шому сторіччі таких випадків стало більше. Ті з нас, хто залишились, але не мобілізовані (як я) теж в якійсь мірі так вчиняють (але звісно ж в меншій мірі).
Але боляче розуміти, що не всі ми в одному човні. Не для всіх мрія № 1 — перемога над Росією. На жаль.
Великі молодці, вітаю!
Хм, можливо я допустив семантичну неточність. Під програмним забезпеченням я мав на увазі будь-яку робочу программу — навіть найпростішу. Чи робити з цього висновки щодо того, чи «погано я знаюсь на IT» — це вже вирішувати не мені.
В будь-якому випадку, це не сильно впливає на месседж, який я хотів висловити у цій статті.
Приєднуюсь до відповіді що TDD це не про процент покриття. Test-driven development, як слідує із назви, це про спосіб розробки програмного забезпечення, який стимулює гнучіксть, постійний рефакторинг, розробку highly cohesive and loosely coupled модулів і має багато інших плюсів.
Але якщо ми вже заговорили про покриття — покриття буває різним. Statement coverage — це добре, але TDD, через свою сутність призводить до того, що нам доводиться створювати код із кращим decision/condition coverage. Саме до цього нас стимулюють три кроки TDD (особливо перші два). TDD — це часто про дисципліну.
Якщо чесно, я думав що всі будуть сперечатись про 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.
Знову ж таки, навіть з такою інтерпретацією я не погоджуюсь (під час обіду краще їсти і спілкуватись з колегами/друзями/сім’єю, півтори години на день може бути забагато і тд), але
фокусуватися на максимізації своєї ефективності яку міряти від своїх особистих цілей в житті
З цим повністю погоджуюсь, краще мабуть і не скажеш
Why not both? Під час юніт-тестування коду ми, по суті, стаємо першими його користувачами. Це призводить до того, що у коду стає менше залежностей, і ці залежності найчастіше подаються зовні (інакше їх складно мокати), модулі стають більш цільними (для прикладу, якщо ми порушуємо SRP, це стає очевидним під час тестування). Крім того, рефакторинг — невід’ємна частина TDD (first make it fail, then make it work, then make it right). Загалом, TDD сприяє тому, що ми проводимо більше часу думаючи про код, а це однозначно йде йому на користь.
Так, 100%. Ще такий момент — Марітн точно не писав цю книгу, тримаючи у голові нашу поточну ситуацію, де майже кожен так чи інакше волонтерить, і на це теж потрібен час. Тому так, особисто для мене по суті
Я погоджуюсь, що TDD на початкових стадіях несе деякий overhead. Але: 1) TDD можна тренувати, і з часом overhead стає меншим 2) переваги TDD економлять час у майбутньому. Ну і код виходить якіснішим.
Не змушують :) «я займаюсь цікавими проектами, які мені цікаві» ©
Дякую!
Ну так, з оглядом у класичному розумінні, мабуть, не склалось, але я постарався викласти свої основні takeaways з книги.
+ вдруге за день
Звісно. Але робота викладача — викладати. Казати «вчіться самі» — не робота.