среда, 30 ноября 2011 г.

Простые правила хорошего разработчика

Первоначально этот пост планировался как перевод статьи "15 Tenets for Software Engineer". Но по мере написания становилось понятно, что в чистом виде перевод не катит. Поэтому получилось то, что получилось. Допускаю, что все это выглядит, как очередной флуд из серии "умные идеи от Капитана Очевидность", но мне статья понравилась и я постарался выразить свое мнение по данному вопросу (ниже по тексту для этого используется курсив). В конце концов, иногда очевидные вещи услышанные (прочитанные) в очередной раз, могут помочь окончательно сформировать мнение по тому или иному вопросу.

На этом месте большинство может перейти на оригинал и не терять время на попытки найти неточности в переводе - их масса :)

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

Попытаемся объединить все это.

Итак, чтобы быть успешным, разработчику нужно выполнять следующие простые правила:

  • Помнить базовые основы языка программирования. Всегда. Если ты забываешь (не будем говорить "не знаешь") эти основы, ты теряешь инструмент, без которого ты не можешь применять остальные знания и умения. Это всегда плохо. По себе могу сказать, что как только не используешь язык больше чем полгода, ты начинаешь забывать много тонкостей. Часто я использую разные языки для разных задач, это помогает освежать знания.
  • Всегда понимать, какой сценарий наихудший. Если у вам довелось изучать алгоритмы (мне, например, в военном училище это счастье не привалило), то вы знаете что означает нотация "О". Знаете, почему алгоритм не может работать лучше - хорошо. Понимаете, почему данный сценарий хуже, чем остальные - отлично. Это то, что позволит вам оставаться успешным. В реальных проектах лично мне редко случалось оценивать именно алгоритмы и выбирать из них лучший. Чаще при оценке приходится учитывать множество факторов, а не только скорость определенного алгоритма. Но почему-то на собеседованиях спрашивают именно об оценке сложности алгоритма. Поэтому, я думаю, имеет смысл поддерживать себя в тонусе и освежать теорию. Например, вот недавно наткнулся на бесплатный онлайн-курс от Стенфордского университета Design and Analysis of Algorithms.
  • Читайте, много читайте. Если вы не читаете материалы посвященные вашей сфере деятельности, то рискуете отстать от постоянно изменяющегося мира. Это может стать препятствием для вашего карьерного роста. "6 книжек которые должен прочитать каждый разработчик"
  • Проверяйте, тестируйте свой код. Добивайтесь того, чтобы у вас были тесты на ваш код, неважно следуете ли вы TDD практикам или используете другие способы. Уровень покрытия кода тестами зависит от типа тестов, но вы должны писать столько тестов, сколько можете. В качестве одного из критериев оценки необходимости написания автоматических тестов можно использовать стоимость написания и последующего запуска тестов. Думаю, есть вещи которые все же дешевле проверить руками, нежели написать тесты. В конце концов код для тестов - это тоже код, для него тоже пишем тесты? Включаем мозги и решаем, что тестируем автоматом, а что ручками. И помните, тестирование не улучшает качество, а измеряет его.
  • Не начинайте использовать новые технологии только потому, что они новые. Используйте их, если они решают вашу проблему. Часто мы следуем новым технологиям в надежде найти "серебряную пулю". Технологии это инструмент, а не волшебство.
  • Пробуйте новые практики и технологии. Постоянно. Да, выше уже говорилось, что не надо использовать новые технологии просто потому, что они новые. Но вы должны пробовать новое, хотя бы для того, чтобы определить, чем оно вам будет полезно. Это также поможет учится и быть в курсе всех последних веяний. Да это сложно, найти баланс между "использовать" и "пробовать". Чаще бывает проще взять и "заюзать", а дальше посмотрим. Не всегда у вас есть возможность сначала обкатать технологию, понять все ее плюсы и минусы, и только после этого принять решение о целесообразности ее использования. Более того, часто, эти самые плюсы и минусы можно увидеть только после реального использования в «продакшене». Но смотри следующий пункт.
  • Ошибаясь, вы учитесь. Как минимум вы поймете, что именно не работает и сможете улучшить свой продукт. В некоторых случаях вы даже можете рассматривать неудачу как маленький успех.
  • Отношение к выдаче «сырого» кода. Иногда вам нужно просто выполнить свою задачу, но вы должны понимать и оценивать оставшиеся долги (если они есть). Если вы постоянно отдаете «сырой» код и накапливаете свои долги, то это прямой путь к кошмару, который настигнет вас, когда в продукте вылезет бага.
  • Делайте «все правильно». Большинство разработчиков имеют свое представление о том, как сделать «все правильно», но не всегда это совпадает с мнением менеджера проекта. Этот пункт можно рассматривать как противоположность предыдущему пункту про выдачу «сырого» кода. Нужно пытаться удержать баланс между этим крайностями.
  • Постоянно улучшайте код: оставляйте код в лучшем состоянии, чем он был на тот момент, когда вы начали с ним работать. Вместо проповедей о достоиствах рефакторинга, подумайте, хотите ли вы поддерживать кучу кода, который становится все хуже. Если вы будете улучшать код по чуть-чуть каждый раз, когда вы его меняете, то код уже не будет ужасным. Ну или, по-крайней мере, хуже он становится точно не будет.
(Дальше идут совсем банальные вещи, но как часто я встречал случаи, когда их игнорируют...)
  • Думайте об одновременном доступе. Если вы разрабатываете веб-приложение, и разговор вовсе не идет о приложении масштаба Facebook-а, то при нагрузке могут вылезти странные вещи. Даже у приложения со 100 одновременно работающими пользователями могут возникнуть проблемы из-за параллельных операций записи и чтения например в HashMaps. И это только вершина айсберга.
  • Места на диске может быть много, но I/O операции могут тормозить. Вы можете полагать, что сохранять все на диск, это отличный способ хранения данных. В общем случае это так, но если вы используете диск как временное хранилище, ваше приложение может быстро споткнуться. Использование физического хранилища должно быть ограничено только теми случаями, когда данные нужно хранить долго, или они просто не помещаются в памяти.
  • Кэш творит чудеса, до тех пор, пока не умирает сервер. Если вы ищете способы избежать повторяющихся запросов к базе, вы начинаете использовать кэширование. Но проблема в том, что кэш требует гораздо больше памяти, чем обычно использует ваше приложение, особенно когда разговор идет о данных, размер которых увеличивается с увеличением количества пользователей. Худшее, что может случится с кэшем, это неконтролируемый рост его размера, что приводит к OutOfMemory ошибке. После этого ваш сервер или «упадет», или перестанет отвечать на запросы. И кэширование уже не поможет, так как стало частью проблемы.
  • Думай и действуй как консультант. Очень часто компании могут поступать с сотрудникам так, как не поступили бы с консультантами: сроки могут быть изменены, объем работ увеличен. И разработчик должен найти способ решить задачу с учетом изменившихся реалий. Как сотруднику, вам нужно использовать все силы для того, чтобы предупредить о том, что сроки не могут быть изменены ввиду имеющегося объема работ, или что объем работ не может быть увеличен без увеличения количества задействованных ресурсов.
  • Внимание к деталям и уважение. От себя добавлю, что хорошего разработчика отличает внимание к деталям и уважение к результату своего труда . Если ты просто генеришь строчки кода без понимания того, зачем они нужны, без проверки того, что они действительно работают - ты не можешь себя считать хорошим разработчиком. Уважение надо также проявлять к тем, кто помогает оценить качество твоей работы, тестировщикам. В конце концов задача у нас одна - получить готовый продукт достойного качества.
PS перечитав еще раз это творение, почему то вспомнился анекдот про начальника, который согласно первому пункту всегда прав, а если не прав - смотри пункт первый. Уж очень, как то, все банально получилось. Надеюсь вы тоже повеселились :)

суббота, 26 ноября 2011 г.

Первый на русском или хороший повод

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

Сегодня состоялась первая конференция Software Project Management. Организована она была компанией SQALab, у которой получилось собрать в одно время и в одном месте много умных людей с интересными идеями про то, как правильно управлять проектами в IT, как работать с командой, какие процессы и как использовать. Большое спасибо SQALab за возможность это все послушать и пообщаться с коллегами.
Итак о моих впечатлениях в целом и о тех докладах, которые удалось посетить.

Сначала о докладах.
Макс Вишнивецкий (@vishmaks). "Отдельные вопросы анатомии менеджера".
Несмотря на медицинское название разговор шел об ошибках, которые часто совершают молодые (я думаю не только молодые) менеджеры: недостаток опыта часто компенсируется (или усугубляется) горячностью, увлечением новыми технологиями и практиками. При этом только с опытом понимаешь, что знаменитые проектный треугольник PMI (бюджет, сроки, объем работ) на самом деле выглядит далеко не как треугольник, а скорее как многогранник. Макс предложил свой вариант треугольника, который, на его взгляд, отражает, как правильно работать с командой. Его составляют доверие, воспитание команды и умение ее защищать. Рассказывалось все очень увлеченно и зажигательно и сопровождалось замечательно подобранными слайдами. Я думаю, что все проснулись (доклад был первым) и получили заряд на весь день. На вопрос "нужно ли помогать менеджеру избегать ошибок" Макс ответил, что "грабли" очень полезны, более того иногда имеет смысл предлагать ему неверную подсказку на его вопросы (для получения иммунитета видимо :)

Лиля Горбачик (@Gorbachik_Lilia) "Как сохранить команду в эпоху перемен"
Доклад в целом неплохой, но без фейерверка. Рассматривались проблемы, с которыми сталкивается менеджер, когда в компании грядут перемены. Для общего развития имеет смысл посмотреть/послушать, но меня не зацепило. Из запомнившегося - "всегда надо готовится к разговору с сотрудником". Ну и уж очень часто звучала пропаганда курения, как способ успокаиваться :), хотя сама она я так понял не курит. Пообщался в кулуарах, по поводу вопросов тестирования (Лиля из QA) и взаимодействия команд разработчиков и тестеров. Она озвучила мысли совпадающие с моими, а именно что эти команды не могут быть по разные стороны баррикад - цель одна: продукт.

Вика Придатко (@nikavika) "Техническое интервью с человеческим лицом"
Вика была в ударе :) Как в общем и обычно на ее докладах. Раньше смотрел в записях - вживую круче :)
Тезисы:
"Первое впечатление второй раз не создается" (классная мысль)
Общайтесь с кандидатом, как с членом вашей команды
Слушайте людей
Всегда задавайте вопрос "что вам важно?"
Берите людей, которые обожают то, что делают
Обязателен feedback, это важно для имиджа компании
забавные вопросы для собеседования:
"Какой самый интересный вопрос вам задавали на собеседовании?" (а вдруг потом вам пригодится :))
Что вам нравится в себе?
Последнее важно не путать с "Кем вы видите себя через 5 лет?" - это булшит

Михаил Завилейский (Ген. менеджер DataArt SPb) "6 хороших идей, которые я бы не посоветовал реализовывать, пока это возможно"
Зачетный доклад, надо еще раз пересмотреть в записи
Тезисы:
- Соревнования между командами - часто больше вредит, чем помогает.
-Нужно ли доводить дело до конца? (лисы vs ежи). Лисы часто не могут доделать дело до конца, ежи всегда доделывают. Программеры почти все лисы. Интересный пример про гору с кучей трупиков ежей под ней. "Если то, что ты обещал нужно только тебе - то ты сам вправе решать нужно ли это доделывать или нет"
- Об измерениях (KPI): измерения могут изменить поведение измеряемой системы (и чуток квантовой физики для примера :) и не факт, что эти изменения будут полезны.
- Кнут vs пряник. На пряник обычно не хватает денег, так может и кнута не надо? Человек сам переживает, а если нет - то с таким расставаться. Нужно благодарить людей и делать это часто. Кстати тема благодарности команде звучала сегодня очень часто на разных докладах.

Сергей Архипенков (очень умный и суровый) "Антипаттерны командного поведения"
Какие бывают типы людей и как это нужно использовать. Пересказывать я бы не рискнул, надо просто посмотреть запись.
Из запавшего в мозг:
- Все программисты - меланхолики (интересно действительно так? Про себя бы не сказал, но я все же не до конца программист)
Надо поощрять командное поведение
"Твое ДА ничего не стоит, пока ты не говоришь НЕТ" - нужно любить людей, которые умеют отстаивать свою точку зрения.
"Ни в одном ВУЗе не учат РАБОТАТЬ"
3 признака хорошего менеджера
- приверженности проекту
- эмоциональный интеллект
- лидер умеющий видеть цели

Оля Павлова (@op) "Курс молодого бойца для менеджеров" или как жить без HR
Очень драйвовый, я бы сказал, жесткий доклад. Рекомендую.
тезисы
Искать людей надо до того, как они понадобятся
Не надо быть как все (на HH.ru работу никто не ищет, как и работников - хмм прикольно, я обычно там и делал и то, и другое)
Программисты - ауты (тут я вообще присел...)
Опять про важность обратной связи с соискателем (донести до него принятое в итоге решение)
Используешь микроменеджмент - убей себя об стену (блин, я грешил этим...)
Все это должно делаться честно и от сердца...

Асхат Уразбаев (scrumtek) "Развитие IT-организации"
Видимо я был оглушен докладом Оли, в итоге у Асхата я переваривал услышанное... Надо будет пересмотреть.

Евгения Фирсова (@diffidence) "Покажи мне свои папки"
Честно не ожидал от этого доклада такого потока полезной информации. Очень хороший докладчик и позитивная девушка в японском стиле :)
Был приведен свой набор антипаттернов, мешающих менеджеру
"Даймё" (япон.)
работа в стиле "все уже решено, согласовано и не может быть изменено". Как бороться: привлечение сторонних экспертов, "стравливание" самих даймё, обозначение рисков, если не удалось их победить.
"Рикша" - (сел к вам в коляску и свесил ножки) "вы начинайте делать, а я пока подумаю, зачем оно надо". "доступ к телу" строго по расписанию и по правилам
Как бороться: стараемся понять как он работает. И ходим, ходим, ходим - менеджер не должен сидеть.
"Чайный домик" (созерцание) - "постоянный негатив" как то я не уловил ассоциации...(Update: см. комментарий от Жени (aka Saigo) ниже, ну и слайды обязательно смотрим)
Как боремся: проговариваем проблемы вслух, всегда благодарим команду, делаем выводы на будущее...

Рома Юферев (http://a-jail.blogspot.com/) "Шарада для менеджера"
Рома отжег, мега-доклад в формате комикса (по-моему лучший доклад, из тех что я сегодня послушал). Под конец напомнило речь пастыря-евангелиста :)
Любимые отмазки менеджеров:
- А что я могу сделать?
- А что, можно было?
- А какова политика компании по этому вопросу?
Какие еще проблемы: паника, проект "сжирает".
Решение: у вас есть свобода выбора и ВОЛЯ.
"можешь свалить на Кубу, а можешь сделать свою Кубу прямо здесь" - Ты можешь изменить реальность. "Не сиди на попе ровно" :)

Иван Селиховкин (http://pmlead.ru/) "Руководитель проекта - жизнь до и после найма"
История про улей и то, как менеджер должен доказать что он пчела, а не медведь.
Важно показывать результат команды в цифрах.
Что и когда показывать:
Риски - всегда до старта проекта
данные из треугольника PMI, риски , документы - в течении всего проекта
Рекламации, снижение стоимости команды - в конце проекта
и обязательное сравнение всего этого от проекта к проекту.

Вот собственно и все, что удалось послушать и посмотреть. Было здорово пообщаться с теми, кого до этого только читал в блогах и твиттере. В конце конференции был розыгрыш ценных призов от спонсоров и организаторов. iPad2 я конечно не выиграл, но 100% скидка на любую следующую конференцию SQALab - МОЯ, за что SQALab большое спасибо.

Update: благодаря Стасу Фомину есть возможность посмотреть видео докладов