Archive for the ‘Код и программистское’ Category

По поводу рабочего графика программистов.

Sunday, August 29th, 2010

Один из читателей блога задал вопрос:

Как лучше всего распределять время и рабочий график программиста?

Я это спрашиваю в связи с тем, что в последнее время стал замечать, что совершенно не могу работать в офисе. Меня эта обстановка сковывает и я целый день занимаюсь фигнёй и ковыряюсь в интернете. Но совершенно по-другому обстановка выглядит дома. Тут я могу сосредоточенно думать, могу писать код по 4-5 часов подряд. И всегда, самые интересные мысли приходят когда я занимаюсь совершенно посторонними вещами.

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

Не уверен, но думаю не у одного меня такое ощущение: приходишь на работу работать, потому что это надо не тебе, а директору. Хотя хочется приходить на работу творить и создавать новое, ради удовольствия.

Как я понимаю, под “распределять время/рабочий график” имелось в виду “когда, где и как” работать.

Разобью вопрос на несколько частей.

1) Есть ли единый (и самый лучший) метод работы, который подойдет всем?
2) Какие методы хороши для каких видов работы?
3) Куда послать директора или что нужно фирме?
4) Творить или не творить?

Итак пойдем по пунктам.

1) Есть ли единый (и самый лучший) метод работы, который подойдет всем?

Бьюсь об заклад, это будет единственный вопрос, по которому все сойдутся в мнениях. Единственного и правильного решения не существует. Один человек “сова” и ему хорошо работать вечером, другой “жаворонок” и ему хорошо работать утром. Кто-то быстрее заныривает в работу, а кто-то буквально из-за мелкого внешнего раздражителя выпадает и долго не может сосредоточиться.

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

2) Какие методы хороши для каких видов работы?

Я бы сказал, что есть два типа программистской работы: требующая концентрации и требующая коммуникации. Решение сложный задач, добавление большего количество “мяса” на скелет, отладка – требует концентрации. Создание архитектуры, работа с QC, интеграция, планирование требует коммуникации.

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

3) Куда послать директора или что нужно фирме?

Если вы работаете в обстановке, которая не подходит для вашего типа деятельности, то это может обозначать несколько вещей
Категория недопонимание:
- вы делаете не тот тип деятельности который от вас на самом деле от вас ожидали (например, вы – team lead и должны со всеми общаться, а вы хотите на неделю запереться дома и активно педалить код)
- просто ваше начальство не осознает, что вы могли бы быть более продуктивным работая по другому.

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

Категория несоответствие:
- вы осознаете, что от вас хотят (например сосредоточение на коде), но вы хотите совсем другого (team leader’ство с постепенным переходом в менеджеры)
- вашей компании может не быть прямой выгоды от того, что вы работаете эффективно (например для тех компаний которые берут внешние проекты c time&material оплатой, может складываться ситуации, когда выгодно чтобы программист делал как можно дольше (естественно удерживая это ниже уровня, когда заказчик уйдет)

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

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

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

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

Стандартный говнокод включает в себя

Friday, August 20th, 2010

- Неправильное разделение на классы (в одни запихнуто куча разного, в других одна функция, которую можно было присоединить к другому классу)
- Отсутствие комментариев
- Гигантские функции на 20 экранов
- Куча глобальных и статических переменных
- Отсутствие разумных интерфейсов и всяческое другое притеснение encapsulation
- Исходные файл в многие тысячи строк и сотни килобайт

Ух… поубивал бы…

P.S. Я еще забыл – отсутствие единообразия по любому выбранному критерию и дублирование (хотя иногда оно три- или четверолирование) кода.

В пользу RoR.

Tuesday, August 10th, 2010

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

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

Что мне очень понравилось, что если бы мне второй раз понадобилось написать такую программу (с нуля), то заняло бы сейчас это у меня наверное пару часов, а третий раз уже в минут 20 вложился бы.

И это достаточно впечатлительно, как мне кажется, достаточно мало платформу дают такой коэффициент ужатия.

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

Ну и плюс потихоньку читаю Ruby Pickaxe книжку и впечатлен некоторыми возможностями/гибкостью Ruby. Чем-то мне Ruby напоминает по гибкости Perl, но когда я разбирался с ним, я был еще чертовски молод и плохо понимал его прелести.

Каскадные зависимости.

Tuesday, August 3rd, 2010

Сейчас мне нужно опробовать продукт X, он распространяется в исходниках. Почитал, как его компилить, покрутил настройки, поставил cygwin (так как готовый make file именно для него), начал компилировать – не может найти каких-то header файлов. Ладно.. смотрим, что за header файлы. Оказывается ему нужен OpenLDAP. Скачиваю OpenLDAP, пытаюсь снова скомпилить, снова не находит (правда других файлов). Покопался, оказывается в OpenLDAP некоторые .h файлы генерируются в момент компиляции. Ладно, начинаю читать про OpenLDAP и обнаруживаю, что он зависит еще от пару продуктов, некоторые их которых тоже в сорцах распространяются.

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

P.S. А никто случайно OpenLDAP под Windows из вас не собирал?