Я прекрасно знаком с фразой о том, что преждевременная оптимизация — это корень всех зол
И как всегда переврали фразу (не специально). Почему-то в русскоязычном сегменте я очень редко встречаю «полную версию» )
Полная фраза в оргининале звучит так:
«We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified» — Donald Knuth
То есть речь шла не о том, чтобы вообщее не заниматься оптимизацией заранее, а о том, чтобы не тратить время на оптимизацию мелочей.
Все же перевод трудно назвать завершенным. Уж очень много разного рода ошибок, вплоть до потери смысла отдельных предложений:
Как вы можете увидеть, если вы хотите достичь теоретической максимальной производительности, которую может предложить SSD, сеть становится узким местом для количество в зависимости от типов подключения, при количестве SSD от 1 до 9 штук
Мне кажется даже однократная вычитка могла бы сильно улучшить качество текста.
Что такое «самопальный рефактоинг»? Рефакторинг, который не был официально подписан PM-ом? )
В результате «самопального» рефакторинга вы скорее всего после очередного просранного срока просто окажетесь на улице.
Я не встречал проектов, в которых над уровнем когда следят и при этом хронически фейлящих сроки. Зато встречал проекты, где всё делалось «побыстрее», на технический долг регулярно забивалось и в итоге в один прекрасный момент оказывалось, что для исправления накопившихся проблем проще (и быстрее) всё выкинуть и переписать с нуля. Удивительно, правда?
Да, но ответственность за этот процесс лежит на техническом руководителе / архитекторе и договариваться с PM должен он, а не конечный разработчик.
Это дОлжно быть оговорено им (архитектором/техлидом) и всей командой в целом один раз и навсегда, еще на старте проекта. PM-а это касается только косвенно. Поддержка качества кода проекта должна присутствовать в каждой задаче, а не делаться задним числом. Это как сначала писать приложение, а потом добавлять в него «безопасность».
Вариант «знаешь, я тут решил отрефакторить кое что и потратил 3 лишних дня и еще пару дней уйдёт на то, чтобы этот функционал стабилизировать» — хреновый звоночек, хотя бы потому, что разработчик не подумал, сколько времени еще понадобится на то, чтобы это протестировать, исправить мелкие баги и т.д.
То, что вы описываете — это не проблема, а следствие проблемы. Если функционал приходится «стабилизировать» — значит он изначально был сделан хреново. Это значит, что либо код не проходил ревью (ССЗБ), либо проходил, но ревьюеры это пропустили (вдвойне ССЗБ).
Любым, кто имеет право делать code review и применять по итогам животворящий паяльник. В некоторых компаниях для этого даже есть специальный человек в QA подразделении.
Если ревью занимаются по сути сторонние люди, а не другие члены этой же команды, то вы теряете канал передачи между разработчиками ифнормации о том, что вообще на проекте происходит, как именно что делается, какие были обнаружены ошибки/недочеты/замечания по коду и т.д. Ревью должны делать все. В том числе джуниору весьма полезно ревьювать то, что делает техлид/архитектор ибо это весьма способствует улучшению понимания проекта джуниором.
Нельзя назвать срок «неделя», а делать три, пояснив потом, что вы решили рефакторинг сделать.
Соверешенно верно. Называя срок «неделя» вы должны в том числе учитывать, что вы точно будете делать рефакторинг. Потому что вы всегда должны делать рефакторинг. Как часть каждой задачи. Постоянно.
Привыкайте, что рефакторинг бизнесу нужно уметь продавать.
Еще раз: бизнесу не нужно и не положено знать про рефакторинг вообще. Оценки времени — да. Риски — да. Как именно оно «внутре» работает и что именно входит в оценку реализации конкретной задачи — нет.
1. Рефакторинг не должен быть соглсован с руководителем. Рефакторинг должен быть постоянным процессом, идущим совместно вместе с любыми задачами. В этом варианте затраты на поддержку кода в хорошем состоянии будут минимальны. Иначе, да, всё будет накапливаться и выполнение «рефакторинга» станет само по себе настолько тяжеловесной задачей, что вам придется «продавать» это PM-у. И он скорее всего не купит. И будет прав (2).
3. Каким «техническим специалистом»? Тем, что работает в этой же команде? Если да, то почему бы это не сделать частью процесса?
Бизнесу не нужен код, бизнесу нужен функционал и выбор приоритетов — это задача руководителя, а не разработчика.
Именно поэтому бизнес не должен принимать технических решений. В частности о том, делать рефакторинг или нет.
В качестве решений могу предложить альтернативу первому пункту («Отказ от сайтовой структуры»). Хотя, пожалуй, можно сказать, что это способ реализации первого пункта.
А именно: разработать платформу пользовательских дополнений (userscripts), которая позволит выполнять динамическое связывание конкретного контента с учетом места (сайта) его размещения с пользовательскими метаданными. Упрощенный пример: пусть есть десяток сайтов с рейтингами фильмов. Когда пользователь просматривает один из сайтов и оценивает какой-либо фильм, оценка сохраняется пользовательским дополнением в метаданных пользователя. Причем, возможно (по желанию пользовтеля), эта оценка не передается самому сайту (в этом варианте даже не требуется регистрация там), а хранится у пользователя локально. Благодаря такому подходу мы можем показывать ему его оценки фильмам на каждом сайте с фильмами, даже если он там впервые. Сделующий шаг — системы обмена рейтингами, тегов и другими метаданными между пользователями.
А можно был хотя бы пару ссылок, где бы можно было посмотреть на именно что действующий вулкан? А то что-то всюду по ссылкам либо ничего не видно, либо вообще какая-то статика.
То есть понятно, что где-то сейчас ночь, но хотелось бы хоть на что-то посмотреть.
Это уже о попытке воспользоваться данной утилитой для уже имеющегося своего диска OCZ. Результат попытки: неверные либо по меньшей мере, непонятные данные, предоставляемые утилитой.
Для OCZ Vector в Overview неправильные данные — почему-то весь объем диска обозначен как «Other», тогда как на самом деле диск заполнен лишь наполовину.
С предыдущим вектором в течение года постоянно мучился с BSOD-ами, пока OCZ не выпустили нормальную прошивку (где-то спустя год после выхода модели). Что особенно грустно — для решения проблемы с BSOD-ами пришлось полностью стирать данные с диска.
Вполне доупускаю, что с железом у OCZ действительно хорошо, но с их firmware — больше иметь дела не хочется.
Полная фраза в оргининале звучит так:
«We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified» — Donald Knuth
То есть речь шла не о том, чтобы вообщее не заниматься оптимизацией заранее, а о том, чтобы не тратить время на оптимизацию мелочей.
Мне кажется даже однократная вычитка могла бы сильно улучшить качество текста.
Я не встречал проектов, в которых над уровнем когда следят и при этом хронически фейлящих сроки. Зато встречал проекты, где всё делалось «побыстрее», на технический долг регулярно забивалось и в итоге в один прекрасный момент оказывалось, что для исправления накопившихся проблем проще (и быстрее) всё выкинуть и переписать с нуля. Удивительно, правда?
Это дОлжно быть оговорено им (архитектором/техлидом) и всей командой в целом один раз и навсегда, еще на старте проекта. PM-а это касается только косвенно. Поддержка качества кода проекта должна присутствовать в каждой задаче, а не делаться задним числом. Это как сначала писать приложение, а потом добавлять в него «безопасность».
То, что вы описываете — это не проблема, а следствие проблемы. Если функционал приходится «стабилизировать» — значит он изначально был сделан хреново. Это значит, что либо код не проходил ревью (ССЗБ), либо проходил, но ревьюеры это пропустили (вдвойне ССЗБ).
Если ревью занимаются по сути сторонние люди, а не другие члены этой же команды, то вы теряете канал передачи между разработчиками ифнормации о том, что вообще на проекте происходит, как именно что делается, какие были обнаружены ошибки/недочеты/замечания по коду и т.д. Ревью должны делать все. В том числе джуниору весьма полезно ревьювать то, что делает техлид/архитектор ибо это весьма способствует улучшению понимания проекта джуниором.
Соверешенно верно. Называя срок «неделя» вы должны в том числе учитывать, что вы точно будете делать рефакторинг. Потому что вы всегда должны делать рефакторинг. Как часть каждой задачи. Постоянно.
Еще раз: бизнесу не нужно и не положено знать про рефакторинг вообще. Оценки времени — да. Риски — да. Как именно оно «внутре» работает и что именно входит в оценку реализации конкретной задачи — нет.
3. Каким «техническим специалистом»? Тем, что работает в этой же команде? Если да, то почему бы это не сделать частью процесса?
Именно поэтому бизнес не должен принимать технических решений. В частности о том, делать рефакторинг или нет.
А именно: разработать платформу пользовательских дополнений (userscripts), которая позволит выполнять динамическое связывание конкретного контента с учетом места (сайта) его размещения с пользовательскими метаданными. Упрощенный пример: пусть есть десяток сайтов с рейтингами фильмов. Когда пользователь просматривает один из сайтов и оценивает какой-либо фильм, оценка сохраняется пользовательским дополнением в метаданных пользователя. Причем, возможно (по желанию пользовтеля), эта оценка не передается самому сайту (в этом варианте даже не требуется регистрация там), а хранится у пользователя локально. Благодаря такому подходу мы можем показывать ему его оценки фильмам на каждом сайте с фильмами, даже если он там впервые. Сделующий шаг — системы обмена рейтингами, тегов и другими метаданными между пользователями.
То есть понятно, что где-то сейчас ночь, но хотелось бы хоть на что-то посмотреть.
Ко всему прочему, данные из отчета этого OCZ Guru нельзя копировать. Соответственно это еще больше затрудняет заполнение этой объемной формы.
Вполне доупускаю, что с железом у OCZ действительно хорошо, но с их firmware — больше иметь дела не хочется.