Мой знакомый разработчик

Источник: habrahabr.ru

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

Этот разработчик принимает документирование очень близко к сердцу.

Как он пишет код

все классы с описанием
Каждый класс, как public так и protected или private обязательно обладает описанием. В описание – несколько слов о назначении класса, имя автора, иногда ссылка на смежные классы, если необходимо – пометка «For internal use only».

все public методы с описанием
Каждый public метод или конструктор обладает описанием того, что этот метод делает, что он возвращает, какие параметры он принимает, какие на эти параметры накалываются ограничения и, иногда, что будет если параметр имеет тривиальное значение (вроде null или -1).

проверка параметров всех public методов
Каждый public метод или конструктор начинается с проверки входящих параметров. Проверяются условия объявленые в описании метода. Если хотя бы одно условие не выполнено, кидается exception.

сначала комментарии
Очень часто блок кода (или одна строчка) имеет комментарий, где человеческим языком объясняется, что сейчас будет происходить. Эти комментарии появляются до самого кода: сначала определяется сигнатура метода, потом пишется его описание, а потом – в теле метода – комментарии с примерным планом исполнения (что-то вроде: «Проверить параметры», «Подключиться к базе данных (здесь мы ещё не подключены)», «Исполнить такой-то запрос»).

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

Как он коммитит в VCS

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

где возможно комментарий ссылается на номер баги
Если коммит исправляет какую-либо багу, то указывается номер это баги и её краткое описание (например: «Fixed bug 999 (put Cthulhu back to sleep)»).

Как он ведёт wiki

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

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

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

каждое изменение страницы имеет комментарий
Комментарий объясняет зачем было сделано изменение.

Как он работает с bug-tracker'ом

комментарий баги при получении – ETA, сложность
Если бага не тривиальна, то при получении пишется комментарий в котором объясняется почему эта бага сложная и примерно сколько времени надо чтобы её пофиксить. В любом случае добавляется пометка, что бага «принята».

диалог с QA-инженером только через bug-tracker
Любые вопросы, комментарии, предложения – только через bug-tracker. Если что-то обсуждали устно (на встрече или за обедом), то тезисы обсуждения заносятся в bug-tracker. Диалог вроде: «А тут у нас, кажется, иногда отваливается левое крыло!», – «Так я это вчера пофиксил», заканчивается багой которая тут же закрывается.

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

при закрытии баги добавляется комментарий с объяснением для QA-инженера
Комментарий к пофикшеной баге содержит два-три слова про фикс и, иногда, подсказку для QA-инженера как этот фикс проще проверить и что стоит потестировать снова.

Как он отвечает на e-mail

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

e-mail адресован только тем, кому следует
Каждое отосланное письмо, будь то вопрос, комментарий, благодарность, предложение, адресован лишь тем людям кому его важно прочесть. К примеру, e-mail'у про изменение структуры какого-то класса в CC не добавляются CEO компании и девушка-секретарь.

в каждом e-mail'е – слова «спасибо» и «всего хорошего»
Каждый e-mail начинается со слов благодарности (за вопрос, комментарий, предложение) и заканчивается вежливыми словами прощания вроде «best regards», «have a nice day».

Однажды я спросил у этого чудака зачем он всё это делает. Он ответил, что у него ужасно плохая память на мелочи. Когда ему надо что-то вспомнить он заглядывает в код, CVS, buzill'у. Он ответил, что так проще QA-инженерам, потому что они могут смотреть на ход работы и писать полные планы тестирования. Он ответил, что так удобнее менеджерам, потому что они могут судить о сроках и о сложности подсистем. Он ответил, что другим разработчикам будет проще разобраться с его кодом. Он ответил, что другим разработчикам будет проще переиспользовать его код. Он ответил, что так учил Стив Макконнелл.

Я подумал: «ну не маньяк?». А как вы думаете, он – графоман или просто хороший разработчик?

Качества перспективного работника

источник: habrahabr.ru

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

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

Итак, в порядке от более важного к менее:

1. Чаще выдавайте результаты

Цель любого потраченного времени — результат. Пока нет результата, невозможно определить эффективно ли вами тратится время или нет. Если результат запаздывает, вы скорее всего расходуете время неэффективно. Или делаете то, что вас не просили либо то, что не так важно сейчас. А может просто изображаете бурную деятельность или протираете штаны. Короче, вызываете беспокойство.
Примеры результата: новый функционал, макет, прототип, звонок, отчет (о проделанной умственной работе, например), документ, письмо. Главное чтобы он был законченный. Не обязательно совершенный, потому что время почти всегда приоритетнее чрезмерного качества.
Побочный эффект ориентации на результат — вы становитесь отличным командным игроком. Потому что финиш (или промежуточный результат) любой задачи обычно является стартом для других. Для большего интерактива делите любой проект по принципу 80/20, чтобы завершить критическую часть в кратчайшие сроки, чтобы другие могли начинать работать хотя бы с чем-то.
Также важно завершать задачи одну за другой, а не заниматься несколькими делами одновременно. Суммарное время почти одинаково, но в последнем случае вы чаще задерживаете других.

2. Пеняйте только на себя

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

3. Не повторяйте ошибок

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

4. Предотвращайте, не противодействуйте

(в английском более ёмко — be proactive, not reactive)
Вместо того чтобы заниматься устранениями последствиями аварий, не допускайте их. Приоритезируйте действия, которые на ваш взгляд предотвратят будущие проблемы и укажите начальству на необходимость выделить на них время. Это заведомо выигрышная стратегия: вы либо устраните проблему, либо перенесете ответственность за нее на уровень выше.

5. Записывайте принятые решения

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

6. Составляйте список проблем

Каждый раз когда вам необоснованно кажется, что вы делаете что-то не так, но не по своей вине, что постоянно подводят: несовершенные процессы, ошибки в программе, другие сотрудники, отделы и т.п. Записывайте всё в отдельное место. Записанная и незабытая проблема — половина решения. Если это проблема мешает только вам, то усвойте что за вас ее никто не решит (думайте о ней и вы рано или поздно найдете решение), а если она еще чья-то, то выскажитесь — может быть решение ее поручат другому.
(Если вы еще очень молоды, вы найдете кучу вещей которые никто вам не даст поменять. Старпёрские, архаичные и консервативные методы биться лбом об стену и т.п. Это очень хорошо, ведь записывая и помня о них вы а) рано или поздно найдете решение и всё поменяете, а до того момента б) будете реалистом и стратегом. Главное — не смириться, а то сами в старпёра и превратитесь :-)
Длинный список (даже мелочей) — ваш аргумент при убеждении в несовершенстве чего-либо. А не записывая, вы будете сетовать по каждому мизерному поводу, что будет характеризовать вас не с лучшей стороны.
Важно не забывать о проблемах, напоминать о них заинтересованным и ответственным. В случае провала, неозвученные ранее проблемы воспримутся как проявление безответственности.

7. Избегайте рутины

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

Ну вот, на мой взгляд, и всё что нужно. Все остальное же, тоже очень важное (обучаемость, коммуникабельность, целеустремлённость, инициативность, чувство юмора) у вас уже есть. Ну, как минимум в резюме ;)

Вскользь затронутые темы:

* Джоэл Спольски о вреде многозадачности
* Закон Парето или принцип 80/20
* Закон Паркинсона