Как показывает мне опыт, в любом приложении можно сделать такое логирование, при котором поиск стандартных багов и их локализация будет занимать минуты. Вряд ли Вы напишите хоть один толковый тест за это время.
Вы когда новую фичу добавляете вы только её тестите или проверяете не сломала ли эта фича что-то другое?
Все зависит от важности фичи и возможного его влияния. Для backend-фич, обычно, после тестирования ее разработчиком и того, кто принимает результат, она попадает в staging environment, где тестируется различными методиками на интеграции, включая Black Box. Если все ОК — идет в production.
Важные фичи тестируются более тщательно, включая написание автотестов, если потребуется.
Или скажем у вас никогда не бывает критических изменений которые хотя бы теоретически могут повлиять на любой кусок программы?
В большинстве случаев баги будут отловлены через автотесты Black Box или QA. Если баг прошел мимо них, а не должен был — добавляем новые тесты или новые инструкции для QA(aka checklist).
нет ресурсов ещё и им заниматься
Как Вы правильно заметили, ресурсов всегда не хватает и правильное их распределение — это искусство управления, то есть вотчина тимлида и выше. Со временем правильно выстроенные процессы позволяют практически гарантированно отловить все критические баги, а не критические — допустимы.
все молодые кого знаю, пытаются вскочить в IT поезд, правдами и неправдами.
Потому что молодые знают, что дальше будет интереснее — роботы, AI, всеобщее подключение к сети. IT открывает огромные возможности, в Америке даже джуны на расхват, я уж не говорю о сеньорах, за которых бьются лучшие компании. Да даже в Москве выпускник вуза, умеющий программировать, может смело претендовать на соточку в месяц. В 90-е такого спроса не было…
Ну не знаю, в России даже в 90-х разработчики получали вполне прилично и существенно выше среднего. Где пожирнее — туда и идут, так всегда было. С горящими глазами молодняк и сейчас бегает, тем более на стартапах можно заработать больше, чем сидя спокойно в офисе.
Простые решения — это всегда хорошо, при условии, что они работают и оправдывают себя.
Что ж за фронтенд такой, где написание теста быстрее, чем поиск и починка багов? Диагностика — один из ключевых элементов разработки, ему здорово помогает логирование и хранение метрик ПО. Если изменения часто ломают другой функционал — это проблема плохой структуры или некорректных изменений и пытаться это лечить тестами — не очень эффективная задача.
Рецепт вытекает из этой цели — соблюдать KISS, управлять техдолгом, обучать членов команды, расставляться грамотно приоритеты между скоростью и качеством. Более конкретно — можно долго расписывать, но это возможно практически для любой фирмы и команды, если есть взаимопонимание с бизнес-людьми/инвесторами/владельцами.
В этом и состоит сложность для технического руководителя проекта — правильно расставить приоритеты при разработке на различных этапах жизни и развития проекта.
юнит тесты очень помогают разработке, позволяя в процессе написания (либо после написания) модуля найти возможные ошибки
Никто ж не говорит, что unit-тесты всегда бесполезны и их нельзя применять. Это как один из инструментов для повышения качества продукта вполне эффективен, в определенных ситуациях и правильно написанные. Еще есть, как Вы правильно заметили, интеграционные тесты, а также Black Box и Input Validation тестирование, перекрестный code review, парное программирование, проверка кода специальными тулзами на ошибки — все это тоже повышает качество продукта. Естественно, за это нужно платить временем разработчиков/тестеров и другими ресурсами, что неизбежно. Для некоторых типов проектов, например, стартапов, это малоприменимо, так как нет столько времени на раскачку, а требования меняются чуть ли не ежедневно, что тянет за собой изменение тестов. Вполне работает для стабильных Enterprise-проектов с размеренными процессами и богатыми на ресурсы.
Проблема в том что «несложно» это всё-таки очень субъективное понятие.
Ну почему же, достаточно писать так, чтобы новый человек несложно разобрался в том, как работает Ваш код и смог его отладить/зарефакторить/развивать. А если при этом еще материться не будет — значит Вы сделали все как надо :).
Но имея адекватный code style это становится проще.
Ни один вменяемый разработчик не будет оспаривать нужность code style в каком-то виде. Более того, это сто раз описано во всех best practices.
И самое главное вопрос в том насколько понятен будет этот код через два-три-четыре года когда будут новые «опытные» со своим новым стилем написания кода.
А что с ним будет-то, с кодом? Он если написан несложно, то понятен будет и через 5 лет и через 50.
Тогда и сопротивляется народ меньше и привыкает проще.
Сопротивляются всегда излишним усложнениям, которые насаждаются излишне авторитарными тимлидами без оценки «а нахрена это нужно вообще».
Решает тот, кто апрувит изменения. Тимлид, естественно, должен быть ответственнен за весь код, выпускаемый его командой, но апрувить может любой опытный член команды.
Когда новый член команды начинает работать, его нужно ввести в курс дел и объяснить, что от него и в каком виде ожидают, этот процесс называется onboarding. Примерно за 1-3 месяца человек вьезжает в тему и начинает давать стране угля в нужном формате.
Автор статьи смешал в одну кучу оформление и организацию кода. Обычно, компании настаивают только на первом, например, вот Java Code Style от Google: google.github.io/styleguide/javaguide.html. Он не такой жесткий, весьма краткий и вполне выполним для большинства разработчиков. Я придерживаюсь похожего подхода.
Автор же в примерах кода показывает, что он сторонник одного подхода и считает, что все должны ему следовать:
В этом примере мы просто берем весь репозиторий, потом используем builder, чтобы создать коллекцию, потом применяем фильтр.
Я считаю, что упорно настаивать на каком-то конкретном подходе принесет только вред и разочарование обоим сторонам. Зачем тогда было нанимать этого разработчика, ты же видел его код? Я сторонник подхода, что если код легко читается, не усложнен без надобности и легко сопровождаем(есть комментарии, логирование, возможен несложный рефакторинг), то он однозначно имеет право на жизнь и нет повода разводить тут алармы.
Так в том-то и дело, что нет такого единого стиля, чтобы его все радостно придерживались. Поэтому всегда будут недовольные. Есть best practices, но они не навязывают единый какой-то стиль.
Ну так-то да, только таких компонентов в обычном SPA-приложении могут быть десятки, причем их поведение будет меняться по ходу разработки/уточнения бизнес-процессов. Каждый раз это покрывать тестами — дело ооочень недешевое для бизнеса, а времени займет — уйму.
Все же склонен считать, что программистов не стоит под одну гребенку чесать и настаивать на одном жестком подходе — это убивает интерес к работе у части талантливых ребят. Скорей всего они просто покинут такую команду. В большинстве случаев достаточно лишь нескольких правил к оформлению кода — длина строки, пробелы, оформление if/for/while и так далее.
Так и есть, первый лучше. Хотя уверен, найдутся люди, которые поддержат второй вариант. Из чего следует, что нет одного «правильного» подхода к программированию, в этом и есть fail суждений автора статьи, который хочет всех под одну гребенку.
Все зависит от важности фичи и возможного его влияния. Для backend-фич, обычно, после тестирования ее разработчиком и того, кто принимает результат, она попадает в staging environment, где тестируется различными методиками на интеграции, включая Black Box. Если все ОК — идет в production.
Важные фичи тестируются более тщательно, включая написание автотестов, если потребуется.
В большинстве случаев баги будут отловлены через автотесты Black Box или QA. Если баг прошел мимо них, а не должен был — добавляем новые тесты или новые инструкции для QA(aka checklist).
Как Вы правильно заметили, ресурсов всегда не хватает и правильное их распределение — это искусство управления, то есть вотчина тимлида и выше. Со временем правильно выстроенные процессы позволяют практически гарантированно отловить все критические баги, а не критические — допустимы.
Потому что молодые знают, что дальше будет интереснее — роботы, AI, всеобщее подключение к сети. IT открывает огромные возможности, в Америке даже джуны на расхват, я уж не говорю о сеньорах, за которых бьются лучшие компании. Да даже в Москве выпускник вуза, умеющий программировать, может смело претендовать на соточку в месяц. В 90-е такого спроса не было…
Простые решения — это всегда хорошо, при условии, что они работают и оправдывают себя.
Никто ж не говорит, что unit-тесты всегда бесполезны и их нельзя применять. Это как один из инструментов для повышения качества продукта вполне эффективен, в определенных ситуациях и правильно написанные. Еще есть, как Вы правильно заметили, интеграционные тесты, а также Black Box и Input Validation тестирование, перекрестный code review, парное программирование, проверка кода специальными тулзами на ошибки — все это тоже повышает качество продукта. Естественно, за это нужно платить временем разработчиков/тестеров и другими ресурсами, что неизбежно. Для некоторых типов проектов, например, стартапов, это малоприменимо, так как нет столько времени на раскачку, а требования меняются чуть ли не ежедневно, что тянет за собой изменение тестов. Вполне работает для стабильных Enterprise-проектов с размеренными процессами и богатыми на ресурсы.
Ну почему же, достаточно писать так, чтобы новый человек несложно разобрался в том, как работает Ваш код и смог его отладить/зарефакторить/развивать. А если при этом еще материться не будет — значит Вы сделали все как надо :).
Ни один вменяемый разработчик не будет оспаривать нужность code style в каком-то виде. Более того, это сто раз описано во всех best practices.
А что с ним будет-то, с кодом? Он если написан несложно, то понятен будет и через 5 лет и через 50.
Сопротивляются всегда излишним усложнениям, которые насаждаются излишне авторитарными тимлидами без оценки «а нахрена это нужно вообще».
Когда новый член команды начинает работать, его нужно ввести в курс дел и объяснить, что от него и в каком виде ожидают, этот процесс называется onboarding. Примерно за 1-3 месяца человек вьезжает в тему и начинает давать стране угля в нужном формате.
google.github.io/styleguide/javaguide.html. Он не такой жесткий, весьма краткий и вполне выполним для большинства разработчиков. Я придерживаюсь похожего подхода.
Автор же в примерах кода показывает, что он сторонник одного подхода и считает, что все должны ему следовать:
Я считаю, что упорно настаивать на каком-то конкретном подходе принесет только вред и разочарование обоим сторонам. Зачем тогда было нанимать этого разработчика, ты же видел его код? Я сторонник подхода, что если код легко читается, не усложнен без надобности и легко сопровождаем(есть комментарии, логирование, возможен несложный рефакторинг), то он однозначно имеет право на жизнь и нет повода разводить тут алармы.