Comments 39
Но лучше все-таки, чтобы их не было.
Тестировщики вас заплюют при таких мыслях. На их языке: «дефектов не может не быть, просто недостаточно тестировали». :)
Если бы не было ошибок, большинство программистов остались бы без работы :-)
Если бы асфальт клали без ошибок, то дорожники бы тоже остались без работы?
У асфальта, как у любого физического элемента, есть эффект изнашивания.
Код не изнашивается. В нему данный критерий неприменим без хорошей аналогии.
Может «изнашиваться» (как синтаксически, так и семантически) только код на границе интерфейсов с внешними системами (включая ОС) при развитии этих систем.
Работа программистов состоит в удовлетворении требований заказчика. Заказчик платит деньги за исправление ошибок или за добавление нового функционала. При этом если заказчик является фактическим потребителем продукта, то доля нового функционала достаточно быстро уменьшается. Поэтому остро встала бы проблема поиска новых заказчиков.
Код не изнашивается. В нему данный критерий неприменим без хорошей аналогии.
Может «изнашиваться» (как синтаксически, так и семантически) только код на границе интерфейсов с внешними системами (включая ОС) при развитии этих систем.
Работа программистов состоит в удовлетворении требований заказчика. Заказчик платит деньги за исправление ошибок или за добавление нового функционала. При этом если заказчик является фактическим потребителем продукта, то доля нового функционала достаточно быстро уменьшается. Поэтому остро встала бы проблема поиска новых заказчиков.
Да просто со стороны очень хорошо заметна разница между неработающим и работающим результатом. В других условиях ты бы за день не сделал систему, которую до тебя делали 3 месяца, но она не рабоала из-за пары багов.
Когда над душой стоит начальник и приказывает в кротчайшие сроки устранить баг в модуле уже внедренной в производство системы, к которому ты не имеешь никакого отношения, то вся радость куда-то улетучивается.
А.С.Некрасов, Приключения капитана Врунгеля:
У меня вот один знакомый есть, так он даже любит, когда зубы болят.
— Конечно, — говорит, — когда болят, действительно и больно и неприятно, но зато, когда пройдут, уж больно хорошо!
У меня вот один знакомый есть, так он даже любит, когда зубы болят.
— Конечно, — говорит, — когда болят, действительно и больно и неприятно, но зато, когда пройдут, уж больно хорошо!
У меня вот как бывает. Порой зависнешь в раздумьях над какой-нибудь функциональность в плане «как это сделать красиво», «как это сделать гибко», «как это сделать быстро», «да как черт возьми это вообще сделать!». Возникает ощущение легкой депрессии, от того что ты долго не выдаешь результат и топчешься на месте. Тогда «баг-фиксинг» — самое верное лекарство от подобной хворобы. Вроде бы и полезным делом занят и результат виден и прогресс на лицо и солнышко на улице ярче светить начинает и птички весенние песни поют и… Бац! Нашел компромиссное решение для злополучной проблемы, которую откладывал.
Если задача хорошего разработчика — разобраться в инструментах и получить опыт, то ок. Если задача — срздать работающий продукт вовремя, то с вами можно спорить.
Я так разобрался с линуксом. Поставил и начал исправлять «дефекты»…
Конечно, я понял, о чем речь, но здесь, на мой взгляд, больше подошло бы устоявшееся название «баг». Пускай это заимствование, но «дефект» в таком контексте звучит как-то странно.
Кстати, натолкнули на мысль — надо бы вести свою коллекцию занятных багов, в виде описаний и/или кода(иногда в виде кода получается очень объёмно). Порой наткнёшься на что-то, обалдеешь, посмеёшься, поделишься с коллегами, а через некоторое время — забудешь. А некоторые баги вполне стоят того, чтобы о них помнили :)
Есть много таких сервисов для тестировщиков. itsfeature.com/ — один из них.
Собственно, thedailywtf.com/
Думаю, заголовок не совсем корректен.
Хороший разработчик не радуется своим дефектам, а просто начинает понимать, что еще есть чему учиться. Чтобы в следующий раз с первого раза правильно написать то, с чем уже сталкивался.
У меня, например, часто возникают проблемы не только из-за того, что я криво написал, но и от того, что изменился формат вводимых или выводимых двнных. Или размер файла стал очень большим. Или заказчик захотел сначало одно, потом другое, а ты уже спроектировал архитектуру не так.
Да много причин, чтобы возвращаться к своему коду и лучше решать поставленную задачу, прогнозируя возможные изменения. Вопрос упирается во время, отводимое решению поставленной задачи.
Хороший разработчик не радуется своим дефектам, а просто начинает понимать, что еще есть чему учиться. Чтобы в следующий раз с первого раза правильно написать то, с чем уже сталкивался.
У меня, например, часто возникают проблемы не только из-за того, что я криво написал, но и от того, что изменился формат вводимых или выводимых двнных. Или размер файла стал очень большим. Или заказчик захотел сначало одно, потом другое, а ты уже спроектировал архитектуру не так.
Да много причин, чтобы возвращаться к своему коду и лучше решать поставленную задачу, прогнозируя возможные изменения. Вопрос упирается во время, отводимое решению поставленной задачи.
Если новый код заработал сразу без багов, то закрадываются подозрения о его нестабильности )) Баг заставляет ещё на раз проанализировать код, протестировать его.
Хороший программист подобен «Доктору Хаусу» — его интересуют только загадки. Только дело, и никаких контактов с «пациентами» (читай «заказчиками»).
Согласен с автором, это ведь отличная возможность разобраться в большом проекте, и почти всегда решение таких задач — процесс исключительно увлекательный =)
Дефект хорош тем, что если он обнаружен — то значит, система работает не так, как планировалось, и есть шанс, что после исправления она будет работать в каком-нибудь смысле эффективнее (по точности, скорости, памяти...). Ну и, конечно, при ловле дефекта можно улучшить и другие части системы, непосредственно к этому дефекту не относящиеся.
Хороший разработчик не радуется дефектам, не надо.
Нравится править чужие/свои баги? Думаю, все были бы в восторге, если разработчики не копались бы в дефектах, а продолжали пополнять функционал. Никому не будет хорошо, если разработчик увязнет на пару недель в лапше кода, полным дефектов.
Нравится править чужие/свои баги? Думаю, все были бы в восторге, если разработчики не копались бы в дефектах, а продолжали пополнять функционал. Никому не будет хорошо, если разработчик увязнет на пару недель в лапше кода, полным дефектов.
Sign up to leave a comment.
Почему хороший разработчик радуется дефектам?