Я думаю все помнят этот анекдот с длинной бородой:

Сидит программист глубоко в отладке.
Подходит сынишка:
- Папа, почему солнышко каждый день встает на востоке, а садится на западе?
- Ты это проверял?
- Проверял.
- Хорошо проверял?
- Хорошо.
- Работает?
- Работает.
- Каждый день работает?
- Да, каждый день.
- Тогда ради бога, сынок, ничего не трогай, ничего не меняй!!!

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

На самом деле, эта одна из самых моих нелюбимых фраз (от программистов) что-нибудь типа “Не трогай это, оно очень ненадежное/сложное”.

Собственно говоря, как только есть такая фраза, то это значит, что в engineering есть серьезные проблемы. И вероятнее всего на проекте нету достаточно хорошего программиста.

Пожалуй сразу оговорюсь, если это legacy система, которая доживает свои последние дни, то фиг с ним, действительно трогать наверное не стоит. Однако, чаще всего такое произносят о какой-то части кода для проекта в самом расцвете сил.

Итак, почему мне это не нравиться?

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

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

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

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

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

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

Я уже писал статью о крупных лажах, которые я сделал.

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

Технарьские проблемы:

- Очень неправильный изначальный estimate (чаще всего неправильная оценка сложности нескольких крупных задач)

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

- Отсутствие технического лидера (или другого опытного человека) на проекте.

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

Решение, просто - добавить технического лидера на проект.

- Развития конечного продукта на базе прототипа.

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

Правильное решение, либо привести прототип к нормальной архитектуры, либо не пытаться сэкономить время на стартование с прототипа.

Бизнес проблемы:

- Установка нереалистично коротких сроков.

Тут все просто. Технари говорят, нам нужно 12 месяцев. Бизнес отделение отвечает - есть только шесть.

Зачастую пробелема не решаема. Если вы находитесь на таком проекте - бегите с него к чертовой бабушке. Через 6 месяцев таки обнаружится что время нужно еще и бизнес отделение начнет пинать технарей и искать куда бы слинять, так как денег от продаж ждать надо будет долго.

- Установка завышенных требований к первой версии

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

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

Даже при портировании нужно разбивать на несколько версий.

- Слишком большое количество разнообразной требуемой функциональности.

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

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

- Малое внимание к проекту

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

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

Вчера, играл с друзьями в пинг-понг (как именуют его тут, в стране заходящего солнца). И вот слово за слово, завязался разговор о текущих багах и потихоньку все погрузилось в глючность реализации JNI (java native interfaces) для какого-то Linux и ошибки в C++ коде, которые вызывается через C прослойку через JNI и т.п.

Где-то после минут десяти у меня начал активно проявляться комплекс неполноценности. Хотя это абсолютно не моя техническая область, но тем не менее, она была и не слишком ихняя. При этом люди меня повергли в ужас, количество разнообразной технической информации о java, c++, по ходу был зацеплен unicode (и его виды utf-8 и utf-16), а так реализация виртуальных машин, их оптимизация, задеты темы языков ruby on rails и чего-то еще.

В общем, после игры в теннис, я чеща голову ушел думать… Что ж блин я такое пропустил в своем интеллектуальном развитии?  Почему же, я какой-то прям таки недоразвитый?

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

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

- знание платформы - 30%

- умение создавать нормальную архитектуру - 20%

- умение решать проблемы 20%

- понимание логики программы - 20%

- знания языка программирования - 10%

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

Я как-то фактически не побывал снаружи от мобильных разработок. Как оно вообще во вне?  Такие же приоритеты или что-то по другому?

Ура господа, случилось то о чем так долго говорили большевики.

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

Если кому нужно будет для блога, с удовольствием отдам фикс в хорошие руки

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