Нажаль зараз дуже важка ситуація на ринку праці. Порадити щось важко. Вчиться, вдосконалюйте навички, але майте план Б.

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

Якщо у компанії вічний потік, то:

Завжди є робота, компанія розвивається і вас скоріш за все не виженуть на мороз ))

б) на таски з припискою todo точно буде всім начхати

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

А щоб нічого не зламалось, є тести

В великих розподілених системах нажаль на 100% сподіватись на тести не можна

При цьому якщо TODO/FIXME є прямо у коді, то це одразу видно і завжди спонукає це почистити.

Нажаль роки досвіду з різними великими проектами кажуть мені зовсім про інше. TODO/FIXME ніхто не чіпає, бо боїться щось зламати а в скоуп їхної таски це не входить. І через роки проект наповнюється цими тудушками, які застарівають і єдине що залишається з ними зробити це видалити. Тоді як таска в беклозі це прописаний action item який можна запланувати, взяти в спринт і зробити. У таски є приорітет, є відповідальний, вона проходить процес рев’ю.

Коротше ніякого зла немає, і це не моє імхо, це факт

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

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

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

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

Це різні речі. Наприклад є якийсь експерт, який веде блог по технології Х. Зараз його блог знаходять через гугл, дивляться його туторіали і він має з цього якийсь профіт. Чат жпт не видає посилання на блог експерта, він видає інфу. Відповідно профіту розміщати нову інфу цьому експерту немає, немає ринкового стимулу.

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

Та з часом всі люди перестануть бути потрібні )

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

Ну якби задачі важкої складності і багато хто з людей не вивозить )

Так, unit тести гарно пише

Ідея не в тому що ШІ буде ідеальним. Ідея в тому що він буде виконувати роботу краще ніж людина. І це вже не за горами.

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

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

Я думаю що забере. До цього ше багато років, але схоже що ми цю конкуренцію вже програємо. В кінці кінців більшість робіт будуть автоматизлвані за допомогою ШІ.
І тоді цікаве питання, як взагалі буде жити суспільство. Треба спитати в chat gpt )

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

Ну це цікава опція, коли важливий startup time. Але для цього кейсу є Spring Native.
Але якщо startup time не важливий, які ще плюси є в Dagger?

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

+