прикладная vs системная разработка

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

долгожданный костыль к Postgresql

Проблема down time при смене версий Postgresql похоже начала решаться.
Надо будет пощупать и возможно это снимет все наши вопросы.

Code review check-list

Честно спизжены из O'Reilly, Applied Software Project Management. Перевод на русский выполнен мной.

1. Ясность
   
   
   
   1. Ясен ли код и просто ли его понимать?
   
   
   2. Усложнил ли программист неоправданно часть кода?
   
   
   3. Может ли код быть подвергнут рефакторингу для его ясности.
   
   
   
   



2. Управляемость
   
   
   
   1. Будут ли другие программисты способны поддерживать этот код?
   
   
   2. Хорошо ли код откомментирован/документирован?
   
   
   
   


3. Точность
   
   
   
   1. Решает ли код поставленную задачу?
   
   
   
   2. Если реализован алгоритм, реализован ли он корректно?
   
   
   
   


4. Надежность и Устойчивость
   
   
   
   1. Устойчив ли код к проблемам? Устойчив ли он к ошибкам?
   
   
   2. Способен ли он обрабатывать предельные условия и плохой ввод?
   
   
   3. Способен ли он корректно аварийно завершаться при возникновении неожиданных условий?
   
   
   
   
   


5. Безопасность
   
   
   
   1. Подвержен ли этот код рискам неавторизованного доступа, неправильного использования и модификации?
   
   
   
   


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


7. Повторное использование
   
   
   
   1. Может ли код быть повторно использован в других модулях и системах?
   
   
   2. Можно ли его сделать более общим?
   
   
   
   
   


8. Эффективность
   
   
   
   1. Может ли этот код более эффективно использовать системные ресурсы?
   
   
   2. Может ли он быть оптимизирован?
   
   
   
   

Завтра думаю пройтись по коду ничего не подозревающих программистов. Боюсь, правда, что будет 2 из 16 :)

к вопросу о менеджменте

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

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

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

© Василий Васильевич Ершов. Раздумья ездового пса

Очень близко к требованиям выдвигаемым к IT-менеджеру. Правда вот беда, не всегда господа it-менеджеры это понимают.

Попробуем еще раз

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