Ага, не за что!
Проблемы, связанные с изменением структуры через интерфейс довольно известны (спасибо дядьке Рихтеру), а вот многие другие — известны не так уж и многим…
Ну, хз. Мне часто говорят, что я задаю сложные вопросы на собеседовании, но про устройство замыканий я никогда не спрашивал, и подобный хард-кор, как приведенные выше примеры (кроме первого случая) — тоже.
Ну, можно провести опрос, но мне как-то сомнительно, что много людей скажут точное поведение для 2-го и 3-го случаев, т.е. для readonly и массива и тем более за трюк с анонимным классом.
И я никого не знаю, кто такую жесть спрашивает на собеседовании:) (помимо первого случая).
Вот блин, из-за проблем с инетом все обсуждение пропустил.
В целом смысл этой серии статей (в которую входит текущая статья, а также Технический долг и Синдром рефакторинга) заключается в желании показать типовые паттерны поведения команды разработчиков в ходе работы над проектом. Смысл этих статей в чем-то схожий с основной идеей последней книги Демарко, Листера и компании под названием «Adrenaline Junkies», в которой они прежде всего хотели обобщить некоторые паттерны поведения и придать им пригодную для повторного использования форму. Т.е. ты работаешь над проектом и вместо смутного предчувствия, типа че-то с этим проектом не так, ты легко можешь выразить это словами. «А… дело все в том, что „технический долг“ слишком велик», или «да у нас тут, батенька, классический эффект второй системы». Как мне кажется, увидеть существование подобной проблемы является первым и главным этапом на пути ее решения.
Теперь что касается решения. Как мне кажется, есть несколько ключевых идей, способных если не устранить, то, по крайней мере, существенно снизить риск подобных проблем. Во-первых, стараться не высекать решения в камне, а давать возможность от них отказаться за разумное время и количество усилий. Очень часто бывает, что вот, приняли решение использовать СОМ, и запихнули это дело в каждую дырку. Или взяли какую-то библиотеку и размазали ее использование тонким слоем по всей системе. Понятное дело, что от всего абстрагироваться нельзя (более того, это не нужно), но разумным образом минимизировать зависимости – просто необходимо.
Во-вторых, диктатура – это хорошо, и, наверное, должна быть одна голова, принимающая окончательные решения, но, мне кажется, нужно, чтобы у этой головы был как минимум один помощник, с не меньшим авторитетом и опытом. Я неоднократно сталкивался с ситуацией, когда проблемы у проекта были из-за того, что один человек значительно превосходил всех остальных по опыту и, соответственно, авторитету. Люди тупо начинают привыкать к тому, что этот человек прав и уже просто не думают самостоятельно. А ведь есть определенный круг задач, где без второго мнения просто не обойтись: это и ряд архитектурных решений, которые хорошо бы проверить на вшивость, да и разработка библиотечного кода (которым обрастает практически каждая команда), и много других задач, все это требует взгляда со стороны. Второй сильный чел, способный сыграть, когда нужно адвоката дьявола – это здорово.
Ну и в-третьих, и я об этом уже упоминал, прагматичное отношение к текущим задачам и избегание крайностей – это одно из ключевых условий спеха (хотя здесь, опять таки, без второй головы весьма тяжко). Нужно помнить, что мы работаем не ради работы (хотя, кого я обманываю, и сам процесс и эстетическая составляющая нам тоже безумно важна), иногда об этом вспоминать и принимать решения соответственно. Т.е. не страдать фигней в виде идеальных решений, а иногда забить на красоту и какие-то правила и каноны и сделать так, чтобы добиться результата; пусть не идеального, но зато в разумные сроки.
З.Ы. хз, стало ли понятнее, но в, в общем, где-то так.
>> Рефакторинг должен решать какую-то коммерчески обоснованную задачу. Если он этого не делает, то мне жаль компанию, которая занимается этим за свой счет. В своих проектах для себя можно делать рефакторинг хоть до посинения.
Проблема в том, что зачастую у разработчиков достаточно сильно развязаны руки (и в большинстве случаев — это хорошо), тогда решение о том, сколько выделить времени на рефакторинг, а сколько на саму реализацию — его дело (и опять таки, в большинстве случаев — это хорошо). Еще раз повторюсь, закручивание гайек — таже фигня, что и полное отсутствие контроля.
Да, все эти аспекты, в купе со здоровым прагматизмом (полностью связывать руки разработчиков — та же хрень, что и позволять переписывать все подряд, даже хз, что хуже) рулит.
По поводу 20% я имел ввиду несколько иное: если взять за 100% усилий, вклад человека для доведения системы до идеала путем рефаторинга, то за первые 20% усилий вы уже получите 80% результата. А все оставшиеся 80% усилий, пойдут лишь на 20 процентный остаток доведения системы до идеала.
Посмотрите по поводу указанной в самом начале метафоры технического долга; рефакторинг — не сверический конь, он призван выплачивать технический долг (или доставлять моральное удовлетворение автору, кстати, в этом случае этот синдром хотя и вредный, если имеет патологическую природу, но есть в нем и положительная сторона). А метафора технического долга позволяет говорить с пользователем на одном языке, приводя в качестве аргументов, не технические доводы, а экономические.
З.Ы. Да, оценить точную величину технического долга сложно. Фаулер считает (Cannot Measure Productivity), что это невозможно, хотя есть и другие мнения (гугл).
Сейчас все еще часто можно прочитать статью по паттернам проектирования. Баян страшный, но иногда бывают полезными и статьи и книги (Head First Design Patterns тому пример). Кроме того, в разное время (речь о проф. карьере) одна и таже информация воспринимается человеком по разному. Так что, :bear: И надеюсь, что и этот поток сознания найдет свою аудиторию.
>> «Бытует мнение, что программные системы не поддаются старению» — у кого из программистов оно бытует-то?! Все давно поняли, кроме самых новичков. Да и те поддакивают, если хоть раз услышат =)
А никто и не говорил, что это мнение бытует среди программистов;) Я например, слышал подобное заявление от нескольких своих руководителей, некоторые из которых, к сожалению имели какое-то отношение к разработке аппаратно-программных комплексов.
>>По статье:
Я хз, у меня как попрет. Очень часто бывает, что начинаю статью, иду в одну сторону, бросаю этот кусок и переписываю заново, получается совершенно другая статья. Ну, а тут, что вышло, то вышло:) Во многом баян, но как правильно когда-то высказались ДеМарко с Листером (кажись в «наркоманах»), часто бывает полезным вынести некоторые суждения (или паттерны поведения, если хотите), на вербальный уровень. Тогда с их помощью значительно легче коммуницировать с другими людьми.
:) Можно подумать авторы книг (особенно технических) просто в золоте купаются. У Эрика Липперта была весьма любопытная заметка по этому поводу, в которой он черным по английскому показал, что вероятность того, что автор сможет разбогатеть на продаже книг — очень небольшая (в смысле, это возможно, но вот распределение такого, что только единицы этого добиваются).
Полностью согласен.
Мне очень понравилась позиция одного моего американского коллеги, который сказал, что покупает книги, чтобы отдать уважение автору за вложенный труд, даже если уже давно пользуется пиратской версией книги, найденой на бескрайних просторах инета.
Я, если честно, хотел покупать ее в бумаге, но нашел электронный вариант раньше. К сожалению с покупкой электронной версии на тот момент было туго.
Если судить по комментарию самого Марка, в одном из комментариев к записи на его блоге, то проблема в следующем:
Unfortunately, MacMillan, my publisher, has not worked out an agreement with Amazon, Apple or other eBook retailers for sale outside the US. I apologize to those of you that are unable to obtain electronic copies
Во всяком случае это было так где-то с месяц назад, когда я занимался активным поиском этой книги и возможно сейчас что-то поменялось.
В общем, если невтерпеж или так и не получится купить эту книгу — пишите в личку.
Согласен, с «maybe». К сожалению, это сокращение в книге больше не встречается (только что поискал его) и дополнительного контекста тоже нет, т.е. приведенная фраза — это все, что есть.
В мире разработки ПО происходит отвратительно мало новых событий. Если знать нормальные источники, то найти там себя проблем абсолютно не составит. Так что да, такое происходит, причем достаточно часто.
Проблемы, связанные с изменением структуры через интерфейс довольно известны (спасибо дядьке Рихтеру), а вот многие другие — известны не так уж и многим…
И я никого не знаю, кто такую жесть спрашивает на собеседовании:) (помимо первого случая).
В целом смысл этой серии статей (в которую входит текущая статья, а также Технический долг и Синдром рефакторинга) заключается в желании показать типовые паттерны поведения команды разработчиков в ходе работы над проектом. Смысл этих статей в чем-то схожий с основной идеей последней книги Демарко, Листера и компании под названием «Adrenaline Junkies», в которой они прежде всего хотели обобщить некоторые паттерны поведения и придать им пригодную для повторного использования форму. Т.е. ты работаешь над проектом и вместо смутного предчувствия, типа че-то с этим проектом не так, ты легко можешь выразить это словами. «А… дело все в том, что „технический долг“ слишком велик», или «да у нас тут, батенька, классический эффект второй системы». Как мне кажется, увидеть существование подобной проблемы является первым и главным этапом на пути ее решения.
Теперь что касается решения. Как мне кажется, есть несколько ключевых идей, способных если не устранить, то, по крайней мере, существенно снизить риск подобных проблем. Во-первых, стараться не высекать решения в камне, а давать возможность от них отказаться за разумное время и количество усилий. Очень часто бывает, что вот, приняли решение использовать СОМ, и запихнули это дело в каждую дырку. Или взяли какую-то библиотеку и размазали ее использование тонким слоем по всей системе. Понятное дело, что от всего абстрагироваться нельзя (более того, это не нужно), но разумным образом минимизировать зависимости – просто необходимо.
Во-вторых, диктатура – это хорошо, и, наверное, должна быть одна голова, принимающая окончательные решения, но, мне кажется, нужно, чтобы у этой головы был как минимум один помощник, с не меньшим авторитетом и опытом. Я неоднократно сталкивался с ситуацией, когда проблемы у проекта были из-за того, что один человек значительно превосходил всех остальных по опыту и, соответственно, авторитету. Люди тупо начинают привыкать к тому, что этот человек прав и уже просто не думают самостоятельно. А ведь есть определенный круг задач, где без второго мнения просто не обойтись: это и ряд архитектурных решений, которые хорошо бы проверить на вшивость, да и разработка библиотечного кода (которым обрастает практически каждая команда), и много других задач, все это требует взгляда со стороны. Второй сильный чел, способный сыграть, когда нужно адвоката дьявола – это здорово.
Ну и в-третьих, и я об этом уже упоминал, прагматичное отношение к текущим задачам и избегание крайностей – это одно из ключевых условий спеха (хотя здесь, опять таки, без второй головы весьма тяжко). Нужно помнить, что мы работаем не ради работы (хотя, кого я обманываю, и сам процесс и эстетическая составляющая нам тоже безумно важна), иногда об этом вспоминать и принимать решения соответственно. Т.е. не страдать фигней в виде идеальных решений, а иногда забить на красоту и какие-то правила и каноны и сделать так, чтобы добиться результата; пусть не идеального, но зато в разумные сроки.
З.Ы. хз, стало ли понятнее, но в, в общем, где-то так.
Проблема в том, что зачастую у разработчиков достаточно сильно развязаны руки (и в большинстве случаев — это хорошо), тогда решение о том, сколько выделить времени на рефакторинг, а сколько на саму реализацию — его дело (и опять таки, в большинстве случаев — это хорошо). Еще раз повторюсь, закручивание гайек — таже фигня, что и полное отсутствие контроля.
З.Ы. По поводу совместного владения кодом в гугле, когда-то ваял одну заметку: Совместная работа над кодом в компании Google.
З.Ы. Да, оценить точную величину технического долга сложно. Фаулер считает (Cannot Measure Productivity), что это невозможно, хотя есть и другие мнения (гугл).
А никто и не говорил, что это мнение бытует среди программистов;) Я например, слышал подобное заявление от нескольких своих руководителей, некоторые из которых, к сожалению имели какое-то отношение к разработке аппаратно-программных комплексов.
>>По статье:
Я хз, у меня как попрет. Очень часто бывает, что начинаю статью, иду в одну сторону, бросаю этот кусок и переписываю заново, получается совершенно другая статья. Ну, а тут, что вышло, то вышло:) Во многом баян, но как правильно когда-то высказались ДеМарко с Листером (кажись в «наркоманах»), часто бывает полезным вынести некоторые суждения (или паттерны поведения, если хотите), на вербальный уровень. Тогда с их помощью значительно легче коммуницировать с другими людьми.
З.Ы. Вот блин, опять многовато букав:)
Мне очень понравилась позиция одного моего американского коллеги, который сказал, что покупает книги, чтобы отдать уважение автору за вложенный труд, даже если уже давно пользуется пиратской версией книги, найденой на бескрайних просторах инета.
Если судить по комментарию самого Марка, в одном из комментариев к записи на его блоге, то проблема в следующем:
Unfortunately, MacMillan, my publisher, has not worked out an agreement with Amazon, Apple or other eBook retailers for sale outside the US. I apologize to those of you that are unable to obtain electronic copies
Во всяком случае это было так где-то с месяц назад, когда я занимался активным поиском этой книги и возможно сейчас что-то поменялось.
В общем, если невтерпеж или так и не получится купить эту книгу — пишите в личку.