статью и правильно заминусили, она ни несла ничего полезного для сообщества
есть необходимость рационально использовать ресурсы и не загрязнять окружающую среду, а есть потепление или нет не так важно, главное что есть причина заставить экономить и меньше углекиского газа выделять
хех где-то пользуются навигацией убера, у нас все таксисты на это забили и используют вейз, ведь для убера всё равно главное только начало и конец пути, а вейз довольно хорошо работает и иногда даже помогает пробки обьехать
а статья может и написано хорошо, но она ни как не коррелирует с реальным миром качество разработки ужастное, баги лезут переодически, на винфоне он у меня вообще не заработал, походу апи поменялся, а приложение не обновили и он не давал залогиниться ругаясь на версию, но новой версии не было.
на js в больших проэктах не был, но неудобства не типизированных языков я решал за счёт написания тестов, из кучи тестов выходил своего рода компилятор который ругался если где-то что-то пойдёт не так
при хорошем сочетании функциональных и юнит тестов можно добиться стабильности, и потом рефакторить совсем не страшно
тут неправильно определили требования к архитектору, у него есть конкретные задачи за рамки которых можно выходить если есть время и умения, но они вовсе не обязательны да и платят не за это, больше похоже на то что основная работа архитектора у вас уже зделана и больше эта позиция не нужна, потому и занимаетесь всякими не архитекторскими задачами.
работал в фирме которая софт для страховщиков пишут и многие страховые ещё сидят на старье потому что старое поддерживать стоит денег, а на новое ещё не решились или нет денег, на новый софт переходили в основном только когда уже программисты которые это всё поддерживали уходили на пенсию/умирали, тогда ничего не оставалось делать как резко найти денег или закончить существование
вот не надо про лошадь и машину, лошадь тогда будет аджайлом так как по параметрам ближе,
кстати раз аджайл уже работает и есть оценимые результаты то надо для сравнение поработать без него какоето время и тогда можно не только сравнить, но и убедить всех скептиков в выгоде ну или наоборот тут всё от результата зависит.
думаю довольно разумное предложение, сам бы потестил, но я ни кем не руковожу, а в новой фирме пока достаточного влияния не имею
без знания задачи трудно оценить где именно пошло не так, но скорее всего демо тут проблему не решилобы, да и готовый образец видимо зделали потому что его было легко зделать, если же клиент ждал год и не интересовался что вы делали, то может ему и не нужен был хороший результат.
но у вас всё равно нет сравнения до и после
как аналогия, взяв машину с мощным двигателем ещё не означает что она доедет из одной точки в другую за более быстрое время, по пути изза большего расхода придёться заправляться намного чаще и в конце она может приехать медленнее чем со слабым двигателем, но меньшим расходом
все менеджеры любят этот аджайл скрам, всякие графики, но почему-то никто не сравнивает с тем что было до этого, тупо перешли потому что модно и графики красивенькие, но ведь это не показатель, показатель это количество полезной работы которая была зделана, надо сравнить до аджайла и после
померить конечно трудно, но без этого нельзя сказать что стало лучше или хуже.
как показывает практика внедрение управление процессами менеджмента задачами не повышаеат качество и быстроту написания продукта, его повышают внедрение правильных процессов разработки: техническая документация, TDD, код ревью и различные виды тестирования конечного продукта.
тут квартира, комуналка, мед страховку не надо, проезд в талине бесплатный, интернет, телефон фирма оплачивает, спортзал тоже, а вот покушать на работе надо самому платить 5€ в день 13 зарплата тоже есть 10% от годовой правда не везде
хех в эстонии чуть выгоднее жить получается, получая 3к и отдав 500 еур 2,5к на остаёться ну и наверно цены на остальное тут пониже, правда такую зп дают не всем, но в среднем около 2-х получают
тесты как минимум в данном примере не несут вреда, больше работы, да, но в идеале тестировать надо абсолютно все действия приложения, если она чтото рендерит то иногда и это нужно потестить, если же кусок для рендеринга используется ещё гдето не не тестить уже нельзя, тесты бывают плохими когда нужно кусок функционала перенести и сделав это надо переписать ещё и сотню тестов, но это значит лишь то что надо тесты правильнее писать
в идеале ещё и свои деньги иметь, крипто валют нынче много развелось, со стороны государства город должен выглядеть как частная компания, которая платит налоги и всё такое, так же охрана своя которая вместо полиции будет, вообщем думаю если хороших юристов найти то можно вписаться в текущее государство не нарушая законов, но строить надо вокруг какого-то бизнеса который расширяясь будет всё больше отраслей использовать, так как это всеголишь бизнес то свои жители «работники» могут пользоваться всеми ресурсами города на одних условиях, а те кто не свои на других, с преступностью надо чтото придумать, и видами наказания, а так довольно интерестно
большая вероятность что и сам заказчик виноват, так как написано выше, что не было знаний о разработке, потому и ТЗ наверно было очень кривое и постоянно менялось, потому аджайл и практикуют чтоб заказчик был ближе к разработчику чтоб через сломанный телефон требования передавались, а почти напрямую.
в прошлой фирме ситуация была похоже тока я со стороны разработчиков, тут и заказчик был такой который и сам не знает что хочет, но и местный менеджмент не особо пытался чтото исправить, потому на исправления времени почти не давалось, а главное было налепить кучу непродуманного функционала, после срыва очередного срока, наконец удалось убедить что надо написаное переделать иначе новое уже не влезет, смогли переписать и многое исправить, но после этого всё продолжилось по старому, и в конце проэкт забросили, так как приобрели компанию с аналогичным продуктом, но пока без нужного количества фич, но там ситуация не лучше уже 2 года прошло, а единственный клиент не хочет на новый продукт переходить потому что он получился ещё хуже, плохо ещё то что заказчик внутренний, а потому не его деньги тратяться на разработку и он вроде как в этом не виноват вовсе, это всё плохие програмисты :D
наверно тут как и везде надо знать меру, нет смысла писать тесты на то что не может сломаться, тдд не обязательно должно распостряняться на весь проект, как и покрытие кода не должно быть 100% если это не несёт никакой пользы, поддерживать кучу тестов тоже напряжно, я вообще считаю что нужно писать в основном функциональные тесты, причём их писать можно также до написания самого кода, а юнит тесты только в местах где функциональные не дадут преимущества или тесты писать слишком сложно
за удалёнными работниками надо следить лучше, работают ли они вовсе и сколько, если в офисе баг пофиксил за час и дальше надо опять работу искать скучно же без дела сидеть, то удалённо можно растянуть на день и никто придраться не сможет что слишком долго.
Уровень лени и умений у всех разный и ленивого, но умного лучше держать в офисе, но ведь хорошие программисты как раз таки и должны быть умными и в меру ленивыми.
есть необходимость рационально использовать ресурсы и не загрязнять окружающую среду, а есть потепление или нет не так важно, главное что есть причина заставить экономить и меньше углекиского газа выделять
а статья может и написано хорошо, но она ни как не коррелирует с реальным миром качество разработки ужастное, баги лезут переодически, на винфоне он у меня вообще не заработал, походу апи поменялся, а приложение не обновили и он не давал залогиниться ругаясь на версию, но новой версии не было.
при хорошем сочетании функциональных и юнит тестов можно добиться стабильности, и потом рефакторить совсем не страшно
кстати раз аджайл уже работает и есть оценимые результаты то надо для сравнение поработать без него какоето время и тогда можно не только сравнить, но и убедить всех скептиков в выгоде ну или наоборот тут всё от результата зависит.
думаю довольно разумное предложение, сам бы потестил, но я ни кем не руковожу, а в новой фирме пока достаточного влияния не имею
как аналогия, взяв машину с мощным двигателем ещё не означает что она доедет из одной точки в другую за более быстрое время, по пути изза большего расхода придёться заправляться намного чаще и в конце она может приехать медленнее чем со слабым двигателем, но меньшим расходом
померить конечно трудно, но без этого нельзя сказать что стало лучше или хуже.
как показывает практика внедрение управление процессами менеджмента задачами не повышаеат качество и быстроту написания продукта, его повышают внедрение правильных процессов разработки: техническая документация, TDD, код ревью и различные виды тестирования конечного продукта.
в прошлой фирме ситуация была похоже тока я со стороны разработчиков, тут и заказчик был такой который и сам не знает что хочет, но и местный менеджмент не особо пытался чтото исправить, потому на исправления времени почти не давалось, а главное было налепить кучу непродуманного функционала, после срыва очередного срока, наконец удалось убедить что надо написаное переделать иначе новое уже не влезет, смогли переписать и многое исправить, но после этого всё продолжилось по старому, и в конце проэкт забросили, так как приобрели компанию с аналогичным продуктом, но пока без нужного количества фич, но там ситуация не лучше уже 2 года прошло, а единственный клиент не хочет на новый продукт переходить потому что он получился ещё хуже, плохо ещё то что заказчик внутренний, а потому не его деньги тратяться на разработку и он вроде как в этом не виноват вовсе, это всё плохие програмисты :D
Уровень лени и умений у всех разный и ленивого, но умного лучше держать в офисе, но ведь хорошие программисты как раз таки и должны быть умными и в меру ленивыми.