Comments 17
очень много теоретических букв, тяжко читать было =(
Мне преподавательница по английскому давала такое упражнение: в тексте (среднего уровня) надо было полностью устранить слова "good", "bad", "thing", "very", "it", "just", "totally/completely".
И вот я смотрю на ваш 'bad smell' и понимаю, что вам выразительности не хватает. Что за smell? Почему он bad? Где именно он? У вас есть прилагательное, используйте его.
Ну это же устоявшееся выражение? Если автор использовал его, значит, ему показалось, что так выразительнее.
Кто пустил в техническую статью гуманитария? bad smell - это термин, означающий признак, который надо искать в процессах. Статья о том, как bad smell узнать и почему он бывает.
П.С. Вы теперь предложите мне заменить слово "гуманитарий" на что-то другое (как предложили автору)?
Если я правильно понял amarao, то его смущает использование bad там, где оно не очень к месту. В оригинале действительно просто code smel, без прилагательных - и это правильно. Мне тоже стоило бы не добавлять характеристик, попахивает - и ладно. В конце концов у smell без прилагательных уже достаточно отрицательных коннотаций.
всё IT построено на словах. Если убрать слова, перед вами останутся квантовые чудеса, из которых нет ни битов, ни байтов, ни функций, ни "окон", ни "приложений" и т.д.
Хорошие названия что-то выражают. bad foo - это неудачное название, потому что оно выражает отношение и всё.
bad smell я в контексте IT как "термин" вижу первый раз (в этой презентации). Уж если говорить про разговорный, то будет просто "smelly" или "cheesy".
Автор презентации хотел развить блистательную метафору "code smell" на административные процессы, но найти яркую форму не смог.
Более того, я не уверен, что это "smell". В процессах мне больше нравится аналогия про friction и smoothness.
Отличная статья, на практике именно так и работает. Контекст определяет инструмент, изменения не избежны (хоть и ненавистны :) ), а core review нужен далеко не всегда.
отличная статья, спасибо большое
Я вот помню в те времена, когда я собеседовался в опенвей - там было по восемь интервью и компьютеры разработчиков полностью отключенные от интернета, как сейчас, запашок подвыветрился?
Ну, это уже давно не так, сейчас больше двух собседований не бывает. Но процессы найма вообще меняются сложнее всего, увы.
А по рабочим местам - нормальная современная компания, ноутбуки, рабочие станции, офис или удаленка и так далее. Много меньше проблем, чем, например, в Яндексе лет 10 назад (про сегодняшний просто не знаю). Некоторые вещи сделаны очень хорошо, некоторые еще нет.
Фил, спасибо за статью, буду людям скидывать.
И спасибо большое за ссылку на мой доклад. Если что, вот тут он доступен всем, а не только участникам Кодефеста: https://www.youtube.com/watch?v=FHu6lyngi1g&list=PLFtS8Ah0wZvWS37oveJ0-D5K6V7GWUpqY&index=6
Спасибо за статью.
Можно еще упомянуть подходы Школы Системного Менеджмента, как минимум потому, что там интегрируются уроки из классической системной инженерии, ТРИЗ, СМД-методологии, от Ivar Jacobson, и много чего еще.
"Рациональный подход" странноватое название, скорее описанную практику можно назвать просто экономическим анализом. Понятие рациональности шире. У меня лично оно скорее ассоциируется с "байесовской рациональностью" и соотв. сообществом - LessWrong.
Увы, я не проходил курсов у Левенчука, так что не мог кратко описать содержимое подхода ШСМ, хотя с удовольствием их порекомендую. Но это уже "следующий уровень", на мой взгляд.
С рациональностью чуть сложнее, описанный подход ближе к "формально научному", но и с его применением для улучшения процессов все непростом, тем более все сложно с применением менее очевидных практик из LessWrong-овской тусовки (и вообще я к ним отношусь с любовью, но осторожностью).
Отличная статья. Закинул нашим почитать.
Ваши процессы попахивают. Как это понять и что делать?