Як вже написали накрупнішим провалом був Windows Phone.
Windows Phone 7, на який не можна було взяти програми з Windows Mobile, з дуже крутим дизайном, але без многозадачністі(якщо не вважати Tombstone). З крутою програмою для прослуховування музики.
Windows Phone 8. На який можна було поставити деякі програми з WP7, але не усі.
Windows Phone 10, який був майже несумісним з 8.
Для них був зроблений з нуля браузер Edge. Дві фічі, які я використовував там: підтримка epub та вбудоване пришвидшення відео.
Ще в Windows Store можна було купити музику та книжки. (це теж закрили з телефонами).
Windows Band — розумні часи,що заряджалися за десять хвилин на день, з вбудованим сенсором ультрафіолету. Але з поганою якістю, через що ремішок постійно рвався.
Ще Microsoft Health був гарний сервіс.
Windows Live — набір сервісів та програм. Але окрім месенджера там нічого не взлетіло. Програми перестали підтримувати, Live сервіси перейшли до Bing.
IronRuby та IronPython були відповіддю на JRuby та Jython. Була ідея на більше Iron мов(згадується IronLisp), Microsoft зробили фреймворк для цього, але потім перестали фінансувати, після чого IronRuby відразу загнувся.
У збільшення кількості програмістів можна інвестувати: організовувати клуби накштальт coderdojo(і оплачувати частину годин, організовувати в університетах якісь додаткові курси з бізнес програмування, можна відправляти перекладені книжки в сільські та районні бібліотеки, можна спонсорувати придбання прав та переклад, якої-небудь книги з програмування для дітей чи навіть в написання щось на зразок книги про професора Фортрана. Багато чого можна.
Але простіше бідкатися і розводити руками.
Без QA. Середня програмістка пише тести півтора дня і код два дні, ще дві години на контекст. Ще дві години на CI/CD. В сумі чотири дні від задачі до продакшну.
З QA. За півтора дні напрограмована задача, можливо ще години дві на юніт тести.
QA бере задачу через день, пише день тести. Знаходить баг. Повертає задачу розробниці.
Розробниця витрачає годину на контекст, годину на виправлення, потім ще годину, щоб повернутися до іншої задачі.
Знову QA чекаємо півдня. Потім за дві години QA каже, що працює і можна релізити.
В сумі п’ять днів на задачу.
Якщо реліз можна зробити дуже швидко, то це відразу помітно.
Мабуть так.
А ні почекайте, бо програмісти пишуть тести різного рівня. Разом з doc командою пишуть документацію.
Support допомагає зрозуміти проблеми користувачів, шле баги.
А якого розміру має бути проект, щоб там потрібні були QA?
Це цикл з позитивним зворотнім зв’язком.
Рефакторинг будуть тестувати, що займе наприклад п’ ять годин. Тож, я не буду робити десять малих рефакторингів на тиждень, а зроблю один дуже великий. Який щось зламає, що буде важче починити(бо де саме буде помилка буде важко знайти) , що збільшить у майбутньому час на перевірку, і на рефакторинг і зробить його більш небезпечним.
Ну прям король.
Якісь люди мають писати документацію.
Чому це не програмісти чи тех райтери.
Про автотести не зрозумів. Чому їх не можуть писати програмісти? (Окрім того, що тестери трохи дешевші). І знову таки — затримуємо реліз на час написання автотестів чи релізимо без тестів?
Рефакторинг має покриватися тестами проекту, інакше не можна робити легкі рефакторинги постійно, що робить код слкаднішим і підвищує ризик рефакторингів, бо якщо треба чекати на тестера, то витрачати на рефакторинг будуть не підвгодини-годину, а декілька днів.
Тобто або затримуємо реліз на декілька днів, щоб написати тести(плюс час на повернення коду з помилками, плюс реверт, плюс зміна контексту) , або деплоїмо непротестований код.
Або девелопери пишуть E2E тести під час роботи на завданням. Але навіщо тоді QA?
Тут усі такі розумні, то задам питання.
Є декілька команд, взагалі п’ятдесят людей. Одна людина робить в середньому дві задачи за тиждень, але періодично є тижні де майже немає нічого зробленого, лкрім рефакторингу чи внутрішніх програм, а іноді дуже багато зроблено.
Деплой йде хвилин зі двадцять без жодних проблем для користувача.
Питання, де в цьому процесі потрібні QA?
PS. Я не пов’язаний з People ai анітрішки.
Так документального підтведження не знайду, проте я знаю людей, які працюють (чи працювали) над проектом і знаю, що там було TDD.
Зараз подивився. Бачу, що core-team свої комміти помічає з B: на початку і в цих коммітах є частіше тести. Бачу, що змінилося дещо.
Але ящо піти в історії назад роки на два версія 5.0.0 і раніше, то видно, що тестів, що додані пізніш не було.
Швидкість розвобки потрібна для проекту, що буде йти більше одного року. Бо без тестів рефакторити набагато важче.
Швидкість розробки, легкість онбоардінгу та зменшення регрессій. Я бачу тільки 35(github.com/...issues?q=label:regression) з яких більшість UI.
Наприклад, Concourse.
Більшість коду написана з TDD.
github.com/concourse/concourse
Не зовсім так з Pivotal тільки.(Бо саме з 2014 до 2016 Pivotal сильно зростав). А підтримка була припинена в 2015.
Pivotal намагався продавати консалтинг з Groovy, але нікому це було потрібно з клієнтів.
Джава зрозуміло бо ентерпрайз, Ruby для стартапів. І ще вже зі три роки Скала набувала популярності.
Groovy не використовувався для внутрішніх сервісів (судячи з пошуку).
А потім ще й замість Jenkins вирішили зробити нормальний CI (перша публічна версія Concourse вийшла восени 2014) — і причин для філантропії не залишилось.
Зазвичай, в кожного серьора є якісь специфічні знання, яких немає в інших програмістів, кожен читає щось своє і робота в парі це шанс вивчити щось обом.
Люди часто починають робити щось з різних сторін. В мене були випадки, коли я вважав, що починати якимось способом було очевидно, але мені показували інші способи.
Також це можливість обмінятися контекстом — в кожного можуть бути припущення, що будуть невірними. В парі легко порівняти свої погдяди.
У випадку рутини можна вкласти час в вивчення інструментів, але що використовуються (vim, and tmux, and tuple), відрефакторити чи завтоматизувати щось.
Давайте порахуємо вартість. Щоб було простіше розробники працюють в парі 6 годин на добу з перервами та перевіркою пошти.
Два розробника — кожен працює десь годин п’ять з перервами на доу. (Втикати в парі набагато складніше).
Ще десь півгодини на те, щоб зрозуміти як зробити, але замість поради людини в парі.
Ще десь півгодини на рев’ю коду. В парі код вже перевірений.
Це вже 8 годин коду проти 6.
А ще ж є час на здобуття контексту — в парі це за замовчуванням.
Ще початковий час на onboarding. В парному програмуванні розробник може наносити користь з першого тижня, але в звичайному з мого досвіду легко може пройти місяць.
Ще час на менторинг. В парному програмуванні набувають навички швидше, ніж у звичайному.
Не побачив жодного прикладу Copilot з підказками в коментарях, що писати.
Ось декілька днів тому статтю опублікували.
github.blog/...ompts-for-github-copilot