Что отличает хорошего специалиста от плохого? Качество его работы, естественно. Его бывает сложно измерить, но сегодня пару слов о том, как стараться его обеспечить, будучи разработчиком. Качественно выполненная работа - та, что требует минимум дополнительных телодвижений, вопросов, правок, коммуникаций, исправлений.
На самом деле совет довольно простой: тестировать. Вы можете возразить, что:
а) это очевидно
б) для тестирования есть специально обученные люди
Но все не так просто. Тестирование нужно не только для кусочков своего говнокода, его стоит начинать с документации. Техническое задание поддается тестированию так же, как и реализованная фича. Его стоит начать с мыслей о том, как будет выглядеть базовый сценарий взаимодействия, если он продуман гладко - отлично. Но если есть сомнения по поводу надежности, производительности или безопасности будущего решения - самое время их озвучить и предложить решения. Потом прикинуть хотя бы пару корнер кейсов и убедиться, что их обработка гладко ложиться в концепцию фичи. Если нет, то она должна быть задокументирована
Например, пилим выдачу кредита: надо получить предварительный скоринг, получить одобренную сумму, если все ок - выдавать бабки. А что если скоринг ок, а сумма не пришла? Если в тз не указано, но есть понимание, что не стоит рубить выдачу с плеча из-за какой-нибудь сетевой ошибки - обсуждаем, отправляем на доработку. Получаем пояснения по поводу ретраев, либо минимальной несгораемой суммы кредита, которую можно без проблем одобрить, чтобы не потерять клиента.
Протестированный локально код - это хорошо. Это база, об этом я говорить много не буду. Для тех кто не тестирует свой код локально - в аду есть отдельный котел, а у тимлида - целый набор больших дилдо с маленькими металлическими шипами. Но тестировать свой код надо и в других окружениях.
Подвергать сомнению совсем все вокруг - путь в никуда. Слишком энергозатратно думать “а что если?” слишком часто. Но вокруг работают люди, они меняют контракты без обратной совместимости, вносят недокументированные изменения и экстренно латают дыры. От этого частично спасает smoke тестирование в dev/qa окружении, особенно в распределенных системах, где количество разработчиков и ежедневных изменений исчисляется сотнями. Прогнал базовый сценарий - убедился, что все хорошо, отдал тестировщикам, пьешь смузи спокойно. Не стоит поддаваться желанию сэкономить силы и время, пропустив этот шаг. Отвечать на тупые вопросы и потом возвращаться переделывать - сильно запарнее, чем сразу убедиться в какой-никакой работоспособности и подправить небольшие нюансы, не теряя контекст. Так можно сэкономить нервы и себе, и окружающим.
В качестве эпилога хотел бы сказать, что не все поддается тестированию. И это не философская мудрость, это просто плохо выполненная работа. Иногда нужна и такая, но если что-то слишком сложно тестировать - это что-то сделано рукожопо. Если есть возможность, лучше переделать.