Archive for Май, 2008

Моя любимая чашка.

Вторник, Май 13th, 2008

Знаете, меня убивают вот такие фразы: «Это моя любимая чашка, поэтому я ее никогда не использую ее и храню за стеклом. Поэтому она никогда не поцарапается и не разобьется».

Как вы считаете, какова реальная ценность такой чашки? Ну, ok, будет она храниться за стеклом и ее никто не разобьет, но ведь получается, что так никогда в жизни и не попьешь из любимой чашки.

Наверно, вы уже приподымаете бровь, думая, совсем бедняга Виктор сдал. В блоге о IT пишет про любимые чашки 🙂 Ан нет…

Это я пишу к тому, что меня убивает, когда люди оставляют куски ОЧЕНЬ важного и возможно полезного кода, которые мы используем в каком-то неопределенном будущем. Люди… очнитесь, либо код важен и полезен, потому, что он пользуется прямо сегодня, либо этот код представляет из себя ту самую чашку, на нее всегда молятся и никогда не пользуют.

Особенно это актуально, учитывая, то что есть системы контроля версий и можно достать всегда удаленный код из закрамов.

Да, возможно, есть ситуации, когда код нужен на завтра и его можно оставить (написал, конктретно когда и зачем он должен быть использован). В остальных случая код должен либо иди в пользование, либо в мусорку.

P.S. Кстати, я имел в виду старый код, который вроде уже и не нужен, но так как он когда-то делал что-то очень полезное, его не удаляют, в надежде, что он пригодиться.

И я ничего не имею против разумного задела в архитектуре для решения потенциальных будущих задач. Хотя, как я сказал, в прошлом предложении — задел должен быть разумный.

И еще раз о амнезии (часть вторая). Буква закона vs. Дух закона.

Воскресенье, Май 11th, 2008

Я написал статью о том, что в компаниях знаниях не накапливаются, а теряются и был удивлен, количеством комментариев и споров, которые возникли вокруг этой статье. Как я и обещал, продолжаю эту больную тему.

В этой статье не буду писать никаких решений, а только буду бить по больным местам… э… пожалуй, только по больным местам этой темы.

Итак, начнем с человека который генерирует знания (кстати, я вообще говорю о любых знаниях – технических, менеджерских, бизнес процессах и т.п.). Вот те вещи, которые отбивают охоту записывать знания:

а) Тот человек, которые создает знания и так их знает, поэтому для него запись знаний чаще всего бесполезная трата времени.

б) Запись знаний, чаще всего низкий приоритет в системе ценностей человека. И поэтому, когда встает выбор – разгребать текущие проблемы или создавать «нетленку» 🙂, то чаще всего начинают разгребать именно текущее дела.

Дальше, перейдем к менеджеру того человека, который генерирует знания. Опять же у него возникает проблема очень похожая на б):

в) Нужно ли заставлять подчиненного писать свои знания или делать остальную часть работы. Опять же возникает конфликт приоритетов.

Потребитель знаний:

г) Почему собственно нужно читать чьи-то ошибки, сделанные непонятно когда и кем и пытаться понять какие-то решения, принятые людьми, которые уже не работают в фирме?

д) Как справляться с тем потоком информации, которые могут быть сгенерированными многими людьми. Как отбирать только нужное и важное и не тратить время на все остальное?

Ну, и с точки зрения компания, проблемы следующие

е) Что делать с людьми, которые не хотят сохранять знания, особенно если они ими обладают. Должно ли стать это требованиям к работе. Что делать с теми, кто не хочет изучать знания?

ж) Какова приоритетность записи и изучения знаний? Это нужно для того, чтобы менеджеры могли выставлять приоритеты рабочим

В) Выделение специальных людей для сбора, организации знаний и контроля за этими процессами. Кстати, это требует финансов.

Д) Самое главное, как сделать весь этот проект прибыльным?

Возможно, я пропустил, что-то важное. Но, даже эти вопросы очень часто выбивают землю из под ног тех, кто пытаются организовать систему сохранения знаний.

Теперь перейду ко второй части статьи. Как многие ответили, нужен отдел, который бы занимался именно этими вопросами – контроль за тем, что знания сохраняются, изучаются, используются, что приоритетность выставляется правильная, что все бизнес процессы идут именно в соответствии с какими-то записанными методиками.

Как я уже писал, это затея очень неплохо «ест» деньги. И любой человек который работал или владел маленькой компанией знает, как для них критичен каждый доллар. И чаще всего вкладывается только в проекты первой приоритетности, которые могут вернуть деньги.

Даже, если деньги выделены, обычно в этот отдел нанимают юношей бледных со взором горящим. Я имею в виду, молодежь без опыта, знаний и только с амбициями и желанием менять мир (они наиболее дешевы при найме).

И именно это убивает эту идею на корню. Проблема состоит в том, что скажем тренер по футболу может натренировать команду с игроками, которые играют лучше него. Но вот человек не игравший в футбол никогда не может натренировать команду.

И вот те самые юноши (или девушки), которые были наняты контролировать, оказываются во главе процессов которые они не понимают, не знают и не пробовали. И получается, то самое, что я писал в названии статьи – они начинают пользоваться буквой закона, вместо духа закона.

Например, в правилах сказано, каждый работник должен записывать знания. Они выбивают их какого-нибудь большого начальника цифру (сколько конкретно нужно записывать в день). Предположим они получили цифру – три абзаца в день и теперь они начинают носить с этим проверяя, что каждый пишет не меньше, чем эти три абзаца.

И естественно, это вызывает мгновенно отвращение на всех уровнях организации. Вчера менеджер, ратовал за сбор знаний, а сегодня его обязуют написать не меньше, чем три абзаца информативного текста (при том, что он сегодня не в духе, у него горит проект или еще что-то).

Таким образом этот отдел, которые изначально был призван поддержать идею, вместо поддержки начинает ее активно и бездумно насаждать, что вызывает полное отторжение.

Как я и говорил, я не хочу писать никаких решений проблем, а только их формулирую. И проблема того, что отдел контроля становится своеобразным КГБ внутри организации очень типичная и большая проблема.

Очень хочется услышать ваше мнение о том, если я забыл указать какие-то проблемы и то, как вы считаете нужно решать самые серьезные их этих проблем.

Пожар, чистые зубы и приоритеты

Вторник, Май 6th, 2008

Написал вчера пост о том, что мелкими действиями плохой проект не спасти и натолкнулся на удивительный отпор 🙂

Признаю, моя ошибка была в том, что я не указал изначально все-все детали. Но с другой стороны, тогда у меня вышел бы не пост, а роман.

А в этом посте, хочу привести один пример.

Человек пошел в ванну чистить зубы, вдруг слышит пожарную серену и видит, что в ванну врываются клубы дыма… Ну, он подумал-подумал и решил, что чистить зубы это полезно для здоровья и решил продолжить это делать. Вот такая, странная трагическая история.

Внимание вопрос. Стоило ему пытаться спасаться? Я думаю — ответ «да». Полезно ли чистить зубы? Ответ тоже «да». Какого же фига нужно спасаться от пожара, а не чистить зубы?

То, что я хотел сказать (и в прошлом посту и в этому), что в мире есть миллион полезных вещей. В программирование этих полезных вещей не меньше.

Сделать ВСЕ полезные вещи нереально. Следовательно нужно расставлять их по приоритетам. Зачастую приоритеты зависят от сложившейся ситуации.

Если человек не умеет выбирать между чисткой зубов и спасание от пожара, долго он не протянет.

Из моего лично опыта, если человек делает даже приоритет N2, вместо приоритета N1 — это уже обычно на длительном отрезке времени ведет к проблемам. Если человек делает приоритет N10 , вместо приоритета N1 — то это полный пипец (даже на коротком участке времени)

Резонный ответ из зала. Но, все равно, лучше делать N10, чем N20 или чем вообще ничего не делать.
Моя саркастическая фраза: Да, конечно, в момент пожара лучше чистить зубы (N10), чем читать газету(N20). Это гораздо эстетичнее и красивее.

Опять ответ из зала: Так, что же вообще ничего не делать? Я скажу так, что если кто-то не решаете приоритет N1 или N2, то толк от человека фактически равен ничего не деланию. А если этим еще и расходуются деньги фирмы на деланье приоритета N10, то лучше вообще чтобы такой человек ничего не делал (был уволен).

Поднятие качества. Либо пан, либо пропал.

Понедельник, Май 5th, 2008

Я когда-то уже писал о рефакторинге тут.

Просто, мне вспомнилась забавная история. Был большой и достаточно жуткий проект. Жуткий в том смысле, что писан был он большим количеством людей, без какой-либо толковой архитектуры и понимания, что делает каждая часть и как они должны взаимодействовать. Причем туча кода, писалась, хоть и толковыми парнями, но все же пока студентами, что опять же придавало проекту дух … э… ну, в общем студенческий дух. То есть код, вроде есть, вроде что-то делает, но скорее все это было похоже на переросшую (причем дико) лабораторную работу.

И вот один из продвинутых студентов (не я 🙂 ) , начал выбивать рефакторинг, чтобы переварить всю эту кучу (хотел сказать говна, но решил сказать кода) в что-то более менее удобоваримое. Ну и начал он выбивать под это время. Естественно проект не маленький, поэтому время он пытался выбить тоже немало (уж очно не помню, но что-то типа 6-9 ч/м), на что в общем ему ответили, что иди мальчик – подыши свежим воздухом, столько бабок мы лучше в пофикс проекта вложим или скажем в новую функциональность.

Кстати, что меня, прикололо (и послужили поводом для статьи), то, что главный разработчик тоже похерил эту идею на корню (хотя он уж точно должен был поддержать). Не буду дословно цитировать, но что он сказал – что код нормальный, единственное иногда непонятно, что он делает. Поэтому единственное, что надо — больше комментариев писать.

Да, так вот, во первых могу с высоты нынешнего полета заверить – нормальностью там и не пахло. Как я уже писал, полное отсутствие архитектуры, кучу дублирования, жесточайшие заплатки на заплатках.

Вернемся к тому продвинутому студенту. Товарищ поразмыслил и сказал, блин если вы такие жлобы, что не хотите давать 6 месяцев, то давайте хоть все начнем придерживаться единого стиля написания (название переменных, отступы и т.п. штучки).

И вот эту идею уже похерил я (не будучи даже главных разработчиком на проекте). И собственно я и сейчас готов отстаивать бессмысленность идеи. С одной стороны, вроде ясна логика студента, блин если нельзя сделать все красиво и качественно, то давайте делать, хоть что-то красиво и качественно. Но, тут есть одно «Но».

Две аналогии. Перед вами стоит жуткий, шатающийся дом с выбитыми окнами, поросший бурьяном и без крыши. Ваша задача его привести в божеский вид и у вас нету денег чтобы сразу сделать это целиком. Вопрос – имеет ли смысл вытирать ноги при входе в дом и вешать красивые зановесочки на окна?

Вторая аналогия. У человека перелом ноги, малярия и чесотка. Нам нужно его вылечить. Имеет ли смысл человеку для лечения давать детскую дозу витаминку C?

Оба раза можно ответить – ничего плохого действие не принесет, но задачу это действие сто процентно не решит и вероятнее всего будет просто трата времени и денег (в пример с домом гораздо более актуально, наверное в примере с человек чуть более спорно).

Так вот, возвращаясь к коду. Если код плохой, то его нельзя вылечить витаминкой C (правильным именование переменных), его можно лечить только более серьезными лекарствами (например понемногу начать разгребать/рефактирить кусочки проекта).

Иначе все эти именования переменных будут простой тратой времени. Можно вполне положить скажем неделю, на то, чтобы все переменные назывались правильно. А можно ту же неделю положить на то, чтобы расчистить один модуль. Как по мне второе, гораздо более эффективно.

В общем, это я о том, что не всякая польза хороша. Важно делить результат пользы на потраченные усилия. И как только это соотношение падает меньше определенного значения, то вероятнее всего – это дело, хоть теоретически и полезно, на практике оно так же бесполезно, как вытирание ног, перед захождение в грязный, заброшенный дом.

P.S. Несколько вещей, которые были затронуты в комментариях. Отвечу сразу всем.

— Откуда вязалась неделя?

Идея паренька была не просто придерживаться новых мелких хорошестей, но и изменить текущий код, чтобы соответствовать им. Именно это и была та самая неделя (на изменения)

— Был ли это legacy проект?

Проект, содержал legacy части, но сам он не был legacy. Причем, его не собирались выкидывать

— Идея, не прогужения в гавно.

Я бы сказал, есть тонкая разница. Если вы по колено в говне, то идея не погружения очень разумная.

Если говно покрывает вас с головой, то нужно не «не погружатся» а всплывать, иначе дышать тяжело будет.

— Форматирование пробелов можно делать  автоматически

Да. Я об этом знаю. Там было больше чем форматирование. Там был достаточно длинный список в основном визуальных изменений, многие из которых нельзя было автоматизировать.

Остальное в комментариях.