Комментарии 58
Работайте запоем
Классно, но вредно. Врачи советуют время от времени отвлекаться от монитора.
Постоянно переписывайте программы
Рефакторинг - это хорошо. Но только вместе с автоматическим тестированием.
Рефакторинг часто хорош и сам по себе. Далеко не все вещи допускают написание тестов более простых, чем они сами. =) Поэтому если попалась именно такая штука и она сложная, то всё, что можно сделать — рефакторить много-много раз, пока не будет кристалльного кода.
Ну и следить за общим поведением, чтобы это. Раз уж тестировать нельзя.
Ну и следить за общим поведением, чтобы это. Раз уж тестировать нельзя.
А совет "не допускайте редактирование одного и того же кода несколькими людьми" - он вообще дурацкий. Наоборот: если исходить из многовекового опыта работы математиков то чего-то стоит только код, который просмотрен (и понят) минимум двумя людьми. К тому же на практике проще всего въехать в свои гениальные идеи если рассказать про них кому-то: если вы не можете даже объяснить чем вы занимаетесь, то точно ли вы "удерживаете" в голове проект или просто обманываете себя ?
САМЫЕ корявые, САМЫЕ ужасные вещи я неизменно вижу в тех случаях когда каким-то участком кода занимается один человек, а не тогда, когда его радактирует куча народу.
На практике наилучший компромис - это OWNER (владелец кода): человек который всё понимает в проекте и без согласия которого в нём не меняется ничего, но который сам кода не пишет (или почти не пишет) - он лишь оценивает то что присылают другие (разумеется он сам может писать код в ДРУГОМ проекте где он не является владельцем).
САМЫЕ корявые, САМЫЕ ужасные вещи я неизменно вижу в тех случаях когда каким-то участком кода занимается один человек, а не тогда, когда его радактирует куча народу.
На практике наилучший компромис - это OWNER (владелец кода): человек который всё понимает в проекте и без согласия которого в нём не меняется ничего, но который сам кода не пишет (или почти не пишет) - он лишь оценивает то что присылают другие (разумеется он сам может писать код в ДРУГОМ проекте где он не является владельцем).
+1
НЛО прилетело и опубликовало эту надпись здесь
> Если вы будете держать монополию на понимание ваших исходников – вас точно никто никогда не уволит. И наплевать на того «джуниора», которому предстоит разгребать ваши исходники.
Ох, влез я сейчас в шкуру такого "джуниора". Элементарное человеколюбие и совесть не заставят меня теперь писать код, подобный такому, какой сейчас приходится разгребать мне.
А проект пока стоит на месте... :(
Ох, влез я сейчас в шкуру такого "джуниора". Элементарное человеколюбие и совесть не заставят меня теперь писать код, подобный такому, какой сейчас приходится разгребать мне.
А проект пока стоит на месте... :(
А захотят уволить - всё равно уволят. Поэтому программировать нужно так, чтобы не уволили, а не чтобы "держать монополию".
> 1. Как можно меньше отвлекайтесь.
Тут речь идет о решении одной задачи до конца, без переключения внимания на другие задачи. В процессе решения можно отвлечься, на еду, например =) Часто бывает так, что из-за пункта 7 (один редактор кода) программеру помимо движения вперед приходится поддерживать уже существующий код. Тупые [проджект]менеджеры часто садятся на шею и не дают программисту решать текущую конкретную задачу постоянно меняя приоритеты. Так делать нельзя.
> 4. Переписывание прог
При хорошем стиле рефакторинг --- это неотъемлимая часть жизни проги. Система тестов держит функционал в рамках и не позволяет вещей вроде "упс, сломалась". Рефакторинг не всегда направлен на изменение архитектуры приложения, скорее, это "горизонтальное" развитие: батлнеки, новые подходы, оптимизация, багфиксы, читаемость кода и т.п. Так что рефакторинг - это и метко и часто.
> 5. Читаемость кода
Опять же про хороший стиль - в проекте должно быть соглашение о форматировании кода, его надо принимать и пользоваться. Тут проблемы перевода. В оригинале: Write rereadable code. Это означает: пишите код, который можно прочитать [любому].
> 6. Небольшие группы
Это не о "позволить себе", а об "организовать работу". Об этом писал еще Брукс в "Мифическом человеко-месяце". Небольшие команды эффективнее больших команд, пример тому - youtube. Это связано лишь со сложностью организации работы внутри больших коллективов.
> 7. Несколько редакторов кода
Согласитесь, глупо давать двум программерам одно и то же задание. В оригинале: Don't have multiple people editing the same piece of code. Не допускайте работу нескольких человек над одним кусом кода. Вне зависимости от сложности задачи исполнитель должен быть один (или два для eXtreme Programming). Если у него возникнут сложности он всегда сможет проконсультироваться с любым количеством коллег. Но исполнитель - один!
Рекомендую в оригинале почитать.
Тут речь идет о решении одной задачи до конца, без переключения внимания на другие задачи. В процессе решения можно отвлечься, на еду, например =) Часто бывает так, что из-за пункта 7 (один редактор кода) программеру помимо движения вперед приходится поддерживать уже существующий код. Тупые [проджект]менеджеры часто садятся на шею и не дают программисту решать текущую конкретную задачу постоянно меняя приоритеты. Так делать нельзя.
> 4. Переписывание прог
При хорошем стиле рефакторинг --- это неотъемлимая часть жизни проги. Система тестов держит функционал в рамках и не позволяет вещей вроде "упс, сломалась". Рефакторинг не всегда направлен на изменение архитектуры приложения, скорее, это "горизонтальное" развитие: батлнеки, новые подходы, оптимизация, багфиксы, читаемость кода и т.п. Так что рефакторинг - это и метко и часто.
> 5. Читаемость кода
Опять же про хороший стиль - в проекте должно быть соглашение о форматировании кода, его надо принимать и пользоваться. Тут проблемы перевода. В оригинале: Write rereadable code. Это означает: пишите код, который можно прочитать [любому].
> 6. Небольшие группы
Это не о "позволить себе", а об "организовать работу". Об этом писал еще Брукс в "Мифическом человеко-месяце". Небольшие команды эффективнее больших команд, пример тому - youtube. Это связано лишь со сложностью организации работы внутри больших коллективов.
> 7. Несколько редакторов кода
Согласитесь, глупо давать двум программерам одно и то же задание. В оригинале: Don't have multiple people editing the same piece of code. Не допускайте работу нескольких человек над одним кусом кода. Вне зависимости от сложности задачи исполнитель должен быть один (или два для eXtreme Programming). Если у него возникнут сложности он всегда сможет проконсультироваться с любым количеством коллег. Но исполнитель - один!
Рекомендую в оригинале почитать.
«заного». Поправьте, пожалуйста. Правильно писать "заново". Глаз режет. А за статью спасибо!
Насчет запоя, правильно подмечено. Я не могу работать над серьезным проектом, если у меня на него выделено меньше двух часов. Даже не возникает настроения. Однако, когда время ничем не ограничено, проект интересный и никто не дергает, могу работать не задумываясь даже о еде по 6 часов подряд и более.
Тоже самое выслушивал часами на лекциях 3го курса в колледже.
Впринципе пункты правильные, но некоторые расписаны как мыльные оперы.
Главное чтобы проект был интересен программисту, а если не интересен - то тут уже ничего не поможет.
Впринципе пункты правильные, но некоторые расписаны как мыльные оперы.
Главное чтобы проект был интересен программисту, а если не интересен - то тут уже ничего не поможет.
Хорошая статья, но некоторые пункты немного из области фантастики.
В тему упомяну книгу "Peopleware". Тема отвлечения и его влияния на работу там рассматривается очень хорошо. Особенно звонки телефона :)
Насчет работы запоем и настроенности на задачу. Мне вспоминается методика "парное программирование". Один из плюсов этой методики в том, что подъемы и спады у людей происходят - к счастью - несинхронно. Поэтому тот, кто "на волне" принимает более активное участие в разработке. А тот, кто в данный момент тормозит, идет "ведомым". Потом они могут меняться. Это напоминает наложение двух синусоид. Суммирующая кривая равна максимуму этих кривых.
Насчет работы запоем и настроенности на задачу. Мне вспоминается методика "парное программирование". Один из плюсов этой методики в том, что подъемы и спады у людей происходят - к счастью - несинхронно. Поэтому тот, кто "на волне" принимает более активное участие в разработке. А тот, кто в данный момент тормозит, идет "ведомым". Потом они могут меняться. Это напоминает наложение двух синусоид. Суммирующая кривая равна максимуму этих кривых.
Ну у парного программирования много и других плюсов. Видел ситуации, когда один увлечённо пишет, а второй тихо "тупит", изредка кивая головой и подсчитывая количество плиток в потолке.
Это если второму задача "нафик нужна". Такого программиста гнать надо взашей. А если он просто тормозит, то будет как минимум пялиться в экран и задавать вопросы "А почему ты тут так сделал?", "А почему ты эту таблицу с этой соединяешь?" итп. Потом прозреет и будет вести за собой уставшего первого.
Есть еще вариант, когда "ведущий" на голову сильнее "ведомого", и ему тупо влом все объяснять, ибо "прет" его.
Полистайте Кента Бека :)
Утверждается что через неделю новичок начнет врубаться и задавать вопросы. Потом и за клавиатуру доведется подержаться. Все чаще и чаще.
В конце концов, ведущий постесняется при ведомом зависать на сайтах знакомств дольше часа.
Утверждается что через неделю новичок начнет врубаться и задавать вопросы. Потом и за клавиатуру доведется подержаться. Все чаще и чаще.
В конце концов, ведущий постесняется при ведомом зависать на сайтах знакомств дольше часа.
Ну так врубаться он начнёт через неделю, а "прет" то сейчас. Из разряда: 'Была такая фишка уже в XXX, я щас оттуда методик выдеру. Да не смотри ты в него, я ж помню как он работает. И описание есть. В общем свыкнись с тем, что все нормально, неохото с этим сейчас возиться'. Это все мелочи, в общем с вами согласен.
>2. Работайте запоем.
Совет хороший, но какой-то фантастичный. Не знаю, как остальные, но я не могу сказать "горшочек вари", и уйти в "запой". Да и 12 часов мне кажутся перебором. Обычно супер-архитектурные решения, рождённые после 12 часов непрерывной работы, мягко говоря удивляют уже на следующий день.
>3. Пишите на лаконичных языках.
Более правильно звучало бы "Пишите лаконичнее, там где это оправданно". Все таки это не только языком достигается. Классы с количеством методов в 80-90, и методы длиною в 2 листа А4, мелким шрифтом, повергают в шок тех, кто пытается в них разобраться.
>7. Не допускайте редактирование одного и того же кода несколькими людьми.
Совсем зря. Выше уже было абсолютно верно сказано насчет 2-х человек.
>8. Начинайте с малого.
Всеми 2-мя руками "за". Моки, заглышки, и прочая "рыба" на ранней стадии позволит найти "неудобные" места в архитектуре, и сформировать правильное API. Я думаю все сталкивались с проблемами разработки, когда для "высокого" кода тут же пишется "нижестоящий", и когда после этого на каждый новый прецедент использования "нижестоящего" кода, его приходится переписывать чуть ли не заново.
А вообще идея держать ВЕСЬ проект в голове кажется несколько утопичной. Хотелось бы посмотреть на программиста, который помнит 200-300 классов, разбитых на 8-10 слоев, часть которых это "несовсем_чистые_хаки", для поддержания bc, и т.д. Не для этого нам понятие "абстракций" дадено.
Совет хороший, но какой-то фантастичный. Не знаю, как остальные, но я не могу сказать "горшочек вари", и уйти в "запой". Да и 12 часов мне кажутся перебором. Обычно супер-архитектурные решения, рождённые после 12 часов непрерывной работы, мягко говоря удивляют уже на следующий день.
>3. Пишите на лаконичных языках.
Более правильно звучало бы "Пишите лаконичнее, там где это оправданно". Все таки это не только языком достигается. Классы с количеством методов в 80-90, и методы длиною в 2 листа А4, мелким шрифтом, повергают в шок тех, кто пытается в них разобраться.
>7. Не допускайте редактирование одного и того же кода несколькими людьми.
Совсем зря. Выше уже было абсолютно верно сказано насчет 2-х человек.
>8. Начинайте с малого.
Всеми 2-мя руками "за". Моки, заглышки, и прочая "рыба" на ранней стадии позволит найти "неудобные" места в архитектуре, и сформировать правильное API. Я думаю все сталкивались с проблемами разработки, когда для "высокого" кода тут же пишется "нижестоящий", и когда после этого на каждый новый прецедент использования "нижестоящего" кода, его приходится переписывать чуть ли не заново.
А вообще идея держать ВЕСЬ проект в голове кажется несколько утопичной. Хотелось бы посмотреть на программиста, который помнит 200-300 классов, разбитых на 8-10 слоев, часть которых это "несовсем_чистые_хаки", для поддержания bc, и т.д. Не для этого нам понятие "абстракций" дадено.
Читал еще в английском варианте и тогда же подумал, что область применимости советов весьма ограничена. Для стартапов подающих на финансирование в фонд Пола Грэхама YCombinator - подходит (в силу ограниченности масштабов таких проектов). Для таких случаев и сравнение с математиками или физиками-теоретитиками приемлимо.
Для более масштабных проектов (простейший пример - создание PC или консольных игр) сравнивать надо не с теоретиком-одиночкой, а, например, с группой физиков-экспериментаторов работающих на ускорителе. Такие группы могут достигать 50-100 человек, и их проекты являются существенно "нелинейными", в том смысле, что в них есть слишком много деталей и ответвлений, учет которых критичен для проекта, но которые (детали) далеко не подчиняются отчетливой и ясное логике, присутствующей даже в самом сложном уравнении или теореме.
Поэтому и отношение к статье двойственное. Многие выражения и сравнения красивые и правильные, но витает дух рекламирования подхода YCombinator. Сам по себе этот фонд замечательный, просто ИМХО в статье стоило сделать disclaimer, что область применимости советов ограничена стартапами. В общем же случае, изложенное не обязательно верно и применимо (хотя и может быть верно и применимо, в зависимости от конкретного проекта). Когда же у Грэхама звучат фразы, типа "мыслительный процесс не очень то можно распределить между людьми", это выглядит так, будто он считает данных подход универсальным для абсолютно всех случаев. А это уже ИМХО неверно.
Для более масштабных проектов (простейший пример - создание PC или консольных игр) сравнивать надо не с теоретиком-одиночкой, а, например, с группой физиков-экспериментаторов работающих на ускорителе. Такие группы могут достигать 50-100 человек, и их проекты являются существенно "нелинейными", в том смысле, что в них есть слишком много деталей и ответвлений, учет которых критичен для проекта, но которые (детали) далеко не подчиняются отчетливой и ясное логике, присутствующей даже в самом сложном уравнении или теореме.
Поэтому и отношение к статье двойственное. Многие выражения и сравнения красивые и правильные, но витает дух рекламирования подхода YCombinator. Сам по себе этот фонд замечательный, просто ИМХО в статье стоило сделать disclaimer, что область применимости советов ограничена стартапами. В общем же случае, изложенное не обязательно верно и применимо (хотя и может быть верно и применимо, в зависимости от конкретного проекта). Когда же у Грэхама звучат фразы, типа "мыслительный процесс не очень то можно распределить между людьми", это выглядит так, будто он считает данных подход универсальным для абсолютно всех случаев. А это уже ИМХО неверно.
Да, судя по комментариям, disclaimer ему сделать явно бы не помешало. Но он, вообще-то, его сделал, просто он "размазан" по тексту. К примеру:
А авторы вышестоящих комментариев, к сожалению, этого не понимают. И поэтому пытаются спорить. Для организаций описанные в статье "способы решения этой проблемы" категорически не подходят (и автор статьи как раз это отлично понимает). Не походят не потому, что проблемы с въезжанием в код у них нет - она есть - а потому, что эта проблема для организации совсем не так важна, как многие другие проблемы - например, проблема взаимозаменяемости людей, проблема сдачи проекта в срок, проблема обеспечения необходимого уровня продаж, проблема минимизации расходов на поддержку проекта, etc. И следование описанным в статье рекомендациям просто не выгодно, ведь задача большинства организаций - "заработать денег", а не "написать максимально качественный код любой ценой".
А вот для описанного в статье программиста, задача стоит "сделать его идеально". И, довольно часто, в определение "идеальности", у программиста не входят такие вещи, как сдача проекта в срок, или облегчение дальнейшей поддержки проекта. Чаще эта "идеальность" относится к внутренней реализации, к элегантности и эффективности кода. А для написания такого кода, и требуется "удерживать его целиком в голове"! Вот для этой ситуации всё описанное в статье абсолютно верно.
Определитесь, в чём Ваша цель, и Вам станет понятно, подходят Вам эти рекомендации, или нет. :)
Но в данном случае это личный проект, и он хочет сделать его идеально.Иными словами, задачи организаций, и задачи описанных в статье программистов, очень сильно расходятся!
Не совсем верно утверждение, что организации отрицают возможность быть зависимыми от одного гениального сотрудника. Просто в нашем сегоняшнем понимании, организации по определению должны не допускать этого.
А авторы вышестоящих комментариев, к сожалению, этого не понимают. И поэтому пытаются спорить. Для организаций описанные в статье "способы решения этой проблемы" категорически не подходят (и автор статьи как раз это отлично понимает). Не походят не потому, что проблемы с въезжанием в код у них нет - она есть - а потому, что эта проблема для организации совсем не так важна, как многие другие проблемы - например, проблема взаимозаменяемости людей, проблема сдачи проекта в срок, проблема обеспечения необходимого уровня продаж, проблема минимизации расходов на поддержку проекта, etc. И следование описанным в статье рекомендациям просто не выгодно, ведь задача большинства организаций - "заработать денег", а не "написать максимально качественный код любой ценой".
А вот для описанного в статье программиста, задача стоит "сделать его идеально". И, довольно часто, в определение "идеальности", у программиста не входят такие вещи, как сдача проекта в срок, или облегчение дальнейшей поддержки проекта. Чаще эта "идеальность" относится к внутренней реализации, к элегантности и эффективности кода. А для написания такого кода, и требуется "удерживать его целиком в голове"! Вот для этой ситуации всё описанное в статье абсолютно верно.
Определитесь, в чём Ваша цель, и Вам станет понятно, подходят Вам эти рекомендации, или нет. :)
Философия Грэхама собственно и состоит в том, что большие компании как форма организации работы устарели (в "мягком варианте" - устаревают). Этот подход он активно питчит уже давно (см. например "Наем устарел", www.perevedem.ru/article/hiring_is_obsolete_full.htm, сорри пока у меня html теги похоже не разрешается ставить).
С этим же лозунгом он создал и YCombinator: бросайте свои компании (или не идите на наемную работу после колледжа/университета) и начинайте в гараже свое любимое дело, а мы дадим $20,000+ на seed capital за небольшую долю. В таких стартапах программист часто и есть основатель и положения статьи могут иметь смысл, поскольку увлеченность и целеустремленность одного человека (основателя или "технического со-основателя") будут играть очень важную, часто главную, роль.
Сам подход вполне нормальный, но, очевидно, не универсальный. Просто старая дилемма entrepreneurship vs. corporate career. Правильного ответа не существует, каждый выбирает для себя сам. Для разных личностей (и на разных этапах их жизни) оптимальный выбор может быть разным.
С этим же лозунгом он создал и YCombinator: бросайте свои компании (или не идите на наемную работу после колледжа/университета) и начинайте в гараже свое любимое дело, а мы дадим $20,000+ на seed capital за небольшую долю. В таких стартапах программист часто и есть основатель и положения статьи могут иметь смысл, поскольку увлеченность и целеустремленность одного человека (основателя или "технического со-основателя") будут играть очень важную, часто главную, роль.
Сам подход вполне нормальный, но, очевидно, не универсальный. Просто старая дилемма entrepreneurship vs. corporate career. Правильного ответа не существует, каждый выбирает для себя сам. Для разных личностей (и на разных этапах их жизни) оптимальный выбор может быть разным.
Хорошо написаный код не требует к себе большого внимания после сдачи заказчику и не отнимает много сил на поддержку. Статья о том, как писать хороший стабильный код и не для генерального директора, а для проджект менеджера и его программеров.
Когда заказчик, после сдачи проекта, просит добавить фичу X, то сложность поддержки зависит от того, насколько эта фича вписывается в архитектуру и насколько читабельно написан код. Совет:
Я думаю, что этот совет можно применять так, чтобы это не усложняло поддержку кода. Во-первых, можно привыкнуть писать/читать более простой, хоть и не такой краткий код. Тогда удобно будет читать именно его. :) Во-вторых, краткость здесь нужна ради удержания всего проекта в голове, а не ради того, чтобы сложную функцию "запинать" в 3 строки. Поэтому если при нормальной записи кода проект в голове перестаёт умещаться, нужно не код более кратко записывать, а проект дробить на изолированные кусочки, которые не нужно одновременно удерживать в голове.
5. Пишите код, который удобно читать вам. ... Когда же вы пишете код для того, чтобы его можно было легко восстановить в памяти, вы скорее предпочтете краткость.полезен пока изначальный код пишется в "потоке". Когда программист, который написал этот код, полезет его модифицировать через 3 месяца, ему самому будет не просто вникнуть в эти краткие конструкции. Фактически, для того, чтобы нормально менять этот код, ему опять нужно будет войти в "поток", загрузить в голову весь проект целиком. Это, в принципе, правильно, но требует довольно много времени.
Я думаю, что этот совет можно применять так, чтобы это не усложняло поддержку кода. Во-первых, можно привыкнуть писать/читать более простой, хоть и не такой краткий код. Тогда удобно будет читать именно его. :) Во-вторых, краткость здесь нужна ради удержания всего проекта в голове, а не ради того, чтобы сложную функцию "запинать" в 3 строки. Поэтому если при нормальной записи кода проект в голове перестаёт умещаться, нужно не код более кратко записывать, а проект дробить на изолированные кусочки, которые не нужно одновременно удерживать в голове.
Почему-то даже из довольно грамотных людей многие пишут слово «воинов» неправильно. Ну что в нём такого сложного?
многие правила как минимум спорны, многие слишком идеалистичны, остальные - азбучные истины.
имхо стоит прочитать начинающим. И мне почему то кажется, что автор - ярый поклонник С++, ну или начинал с него.
имхо стоит прочитать начинающим. И мне почему то кажется, что автор - ярый поклонник С++, ну или начинал с него.
Это все конечно красиво, но справедливо только в случае программиста-одиночки, работающего над личным проектом в свободное время (плюс это самое время не контролирующего).
Как только на фирме будет более 5 программистов, вот что произойдет:
1. Как можно меньше отвлекайтесь.
Чистейшая правда, это будет влиять благоприятно на производительность труда. Вот только как правило у одного программиста за плечами еще как минимум 10 проектов, которые, как это не прискорбно приходится сопровождать.
2. Работайте запоем.
Как программисту - мне это нравится. Но как руководитель проекта я с этим категорически не согласен. Я просто обязан знать, чем занимается вверенный мне человек, и не давать ему большую свободу действий, чтобы уложиться в сроки. А то он реализует мегафичу, которой не было в эстимейте, и потратит на нее половину предназначенного времени, а то что нужно было сделать - не сделает.
4. Постоянно переписывайте программы.
Опять же - время, время, время. Если свободное время есть - пусть переписывает. Хотя лучше пусть изучает новые технологии. Баги всплывут во время тестинга.
5. Пишите код, который удобно читать вам.
Когда от вас уйдет очередной программист, код которого вы через месяц никто не сможет разобрать (хотя он и будет рабочим), вы вместе со мной посмеетесь над этим советом.
6. Работайте маленькими группами.
А если дэдлайн через 2 дня, а на проект выделено 100 часов? Волей-неволей придется привлекать настолько много программистов, насколько возможно.
7. Не допускайте редактирование одного и того же кода несколькими людьми.
Вы думаете клиент будет ждать программиста, который заболел или ушел в отпуск, с месяц? Покажите мне этого клиента.
8. Начинайте с малого.
Каким боком программист связан с прототипом?? Прототипом занимается кто угодно (ПМ, менеджер по работе с клиентами, дизайнер и т.д.), но только не программист.
Как только на фирме будет более 5 программистов, вот что произойдет:
1. Как можно меньше отвлекайтесь.
Чистейшая правда, это будет влиять благоприятно на производительность труда. Вот только как правило у одного программиста за плечами еще как минимум 10 проектов, которые, как это не прискорбно приходится сопровождать.
2. Работайте запоем.
Как программисту - мне это нравится. Но как руководитель проекта я с этим категорически не согласен. Я просто обязан знать, чем занимается вверенный мне человек, и не давать ему большую свободу действий, чтобы уложиться в сроки. А то он реализует мегафичу, которой не было в эстимейте, и потратит на нее половину предназначенного времени, а то что нужно было сделать - не сделает.
4. Постоянно переписывайте программы.
Опять же - время, время, время. Если свободное время есть - пусть переписывает. Хотя лучше пусть изучает новые технологии. Баги всплывут во время тестинга.
5. Пишите код, который удобно читать вам.
Когда от вас уйдет очередной программист, код которого вы через месяц никто не сможет разобрать (хотя он и будет рабочим), вы вместе со мной посмеетесь над этим советом.
6. Работайте маленькими группами.
А если дэдлайн через 2 дня, а на проект выделено 100 часов? Волей-неволей придется привлекать настолько много программистов, насколько возможно.
7. Не допускайте редактирование одного и того же кода несколькими людьми.
Вы думаете клиент будет ждать программиста, который заболел или ушел в отпуск, с месяц? Покажите мне этого клиента.
8. Начинайте с малого.
Каким боком программист связан с прототипом?? Прототипом занимается кто угодно (ПМ, менеджер по работе с клиентами, дизайнер и т.д.), но только не программист.
>Опять же - время, время, время. Если свободное время есть - пусть переписывает. Хотя лучше пусть изучает
>новые технологии. Баги всплывут во время тестинга.
У рефакторинга много плюсов в долгосрочной и среднесрочной перспективе. Есть и краткосрочные, но они "гасятся" снижением темпов. Да и выделение тестирования в отдельную фазу не обязательно (Мартин Фаулер о Continuous Integration) .
>Каким боком программист связан с прототипом?? Прототипом занимается кто угодно (ПМ, менеджер по работе
>с клиентами, дизайнер и т.д.), но только не программист.
Прототип это не обязательно рисунок (схемы, описание).
>новые технологии. Баги всплывут во время тестинга.
У рефакторинга много плюсов в долгосрочной и среднесрочной перспективе. Есть и краткосрочные, но они "гасятся" снижением темпов. Да и выделение тестирования в отдельную фазу не обязательно (Мартин Фаулер о Continuous Integration) .
>Каким боком программист связан с прототипом?? Прототипом занимается кто угодно (ПМ, менеджер по работе
>с клиентами, дизайнер и т.д.), но только не программист.
Прототип это не обязательно рисунок (схемы, описание).
>2. Работайте запоем.
>Как программисту - мне это нравится. Но как руководитель проекта я с этим категорически не согласен. Я просто обязан >знать, чем занимается вверенный мне человек, и не давать ему большую свободу действий, чтобы уложиться в сроки. А то он >реализует мегафичу, которой не было в эстимейте, и потратит на нее половину предназначенного времени, а то что нужно >было сделать - не сделает.
По моему речь идет не о реализации мегафич, а о так называемом "потоке" (peopleware). Человек входит в состаяние крайней концетрации над задачей, когда 90% его мыслей связаны с решением задачи. И могу по своему опыту и программиста и прожект менеджера сказать, что большинство задач именно так и решается. Очень важно, чтобы у программиста была возможность так работать. Если человека отвлечь в это время, например грозным вопросом, "Чем ты занимаешься?" вид у него будет растерянный т.к. ему прийдется срочно переключаться. Если сделать такое несколько раз в день у человека появится раздражение (чисто физиологическое) и возможно даже обида (люди не любят когда в них постоянно совневаются, когда они дествительно отдаются работе). Отсюда вывод не стоит боятся и дергать людей во время работы. ПМ не надсмотрщик. Работа программиста, как и любая другая, должна оцениватся по оканчании (в нашем случае задачи). И только по окончании можно сказать хорошо или плохо выполнена задача (или не выполнена). Если программист постоянно лажает, не понимает приоритетов, то не нужно его пытатся контролировать еще сильнее, нужно просто расстаться с ним.
>6. Работайте маленькими группами.
>А если дэдлайн через 2 дня, а на проект выделено 100 часов? Волей-неволей придется привлекать настолько много >программистов, насколько возможно.
Это истерика, кидать на проект как можно больше людей. Если проект на 100 часов не делится на логически обособленные подзадачи, то его должен делать 1 человек. Или например он делится, явно видно, что заниматься им могут 2 программиста и 1 дизайнер. А дедлайн через 2 дня (ну 3, два это уж слишком), то становится ясно, что они сделать не успеют. А если проект не возможно выполнить за заданное время, используя разумное количество ресурсов, то не стоит и браться за безнадежное дело. Вы же не берётесь в одиночку покорить Эверест или космический корабль построить - разницы по моему между таким проектом или этими задачами никакой, и то и то безнадежно в своем начинании, так как наши возможности к сожалению ограничены.
>Как программисту - мне это нравится. Но как руководитель проекта я с этим категорически не согласен. Я просто обязан >знать, чем занимается вверенный мне человек, и не давать ему большую свободу действий, чтобы уложиться в сроки. А то он >реализует мегафичу, которой не было в эстимейте, и потратит на нее половину предназначенного времени, а то что нужно >было сделать - не сделает.
По моему речь идет не о реализации мегафич, а о так называемом "потоке" (peopleware). Человек входит в состаяние крайней концетрации над задачей, когда 90% его мыслей связаны с решением задачи. И могу по своему опыту и программиста и прожект менеджера сказать, что большинство задач именно так и решается. Очень важно, чтобы у программиста была возможность так работать. Если человека отвлечь в это время, например грозным вопросом, "Чем ты занимаешься?" вид у него будет растерянный т.к. ему прийдется срочно переключаться. Если сделать такое несколько раз в день у человека появится раздражение (чисто физиологическое) и возможно даже обида (люди не любят когда в них постоянно совневаются, когда они дествительно отдаются работе). Отсюда вывод не стоит боятся и дергать людей во время работы. ПМ не надсмотрщик. Работа программиста, как и любая другая, должна оцениватся по оканчании (в нашем случае задачи). И только по окончании можно сказать хорошо или плохо выполнена задача (или не выполнена). Если программист постоянно лажает, не понимает приоритетов, то не нужно его пытатся контролировать еще сильнее, нужно просто расстаться с ним.
>6. Работайте маленькими группами.
>А если дэдлайн через 2 дня, а на проект выделено 100 часов? Волей-неволей придется привлекать настолько много >программистов, насколько возможно.
Это истерика, кидать на проект как можно больше людей. Если проект на 100 часов не делится на логически обособленные подзадачи, то его должен делать 1 человек. Или например он делится, явно видно, что заниматься им могут 2 программиста и 1 дизайнер. А дедлайн через 2 дня (ну 3, два это уж слишком), то становится ясно, что они сделать не успеют. А если проект не возможно выполнить за заданное время, используя разумное количество ресурсов, то не стоит и браться за безнадежное дело. Вы же не берётесь в одиночку покорить Эверест или космический корабль построить - разницы по моему между таким проектом или этими задачами никакой, и то и то безнадежно в своем начинании, так как наши возможности к сожалению ограничены.
В целом - согласен с обоими замечаниями. Добавлю, что:
2. Все люди разные. У меня в группе несколько человек и к каждому из них свой подход: одному я могу дать задание и забыть об этом на 8 часов, т.к. я уверен что он не будет задавать глупых вопросов и сделает все возможное сам; второго мне надо каждый час контролировать, причем при этом эффективность его труда возрастет по сравнению со случаем, когда я не трогал бы его и пустил все на самотек. Я не хочу расставаться со вторым, как Вы предложили, т.к. я знаю что он способен давать результат, в то же время мне надо им именно "руководить".
А тот вариант, который Вы предложили, будет работать только если у Вас супер-команда или куча времени на ее подбор.
6. Я, конечно же, преувеличил со 100 часами работы на 2 дня. Но общий смысл остается неизменным: работать маленькими группами хорошо, но не всегда получается это реализовать в реальных условиях.
Если бы вместо 6-го совета написали бы что-нибудь про то, как работать, если дедлайн был "вчера", то это было бы более полезно для программистов. А так выходит, что автор лишь показывает "идеальные" условия для работы, которые редко когда увидишь на практике.
2. Все люди разные. У меня в группе несколько человек и к каждому из них свой подход: одному я могу дать задание и забыть об этом на 8 часов, т.к. я уверен что он не будет задавать глупых вопросов и сделает все возможное сам; второго мне надо каждый час контролировать, причем при этом эффективность его труда возрастет по сравнению со случаем, когда я не трогал бы его и пустил все на самотек. Я не хочу расставаться со вторым, как Вы предложили, т.к. я знаю что он способен давать результат, в то же время мне надо им именно "руководить".
А тот вариант, который Вы предложили, будет работать только если у Вас супер-команда или куча времени на ее подбор.
6. Я, конечно же, преувеличил со 100 часами работы на 2 дня. Но общий смысл остается неизменным: работать маленькими группами хорошо, но не всегда получается это реализовать в реальных условиях.
Если бы вместо 6-го совета написали бы что-нибудь про то, как работать, если дедлайн был "вчера", то это было бы более полезно для программистов. А так выходит, что автор лишь показывает "идеальные" условия для работы, которые редко когда увидишь на практике.
В принципе согласен, описаны довольно идеальные условия. Так это и есть задача руководства, создать для программиста такие условия работы, при которых и он доволен (читай мотивирован и имеет все условия к реализации своих возможностей), и проект делается нужный (соответсвующий требованиям заказчика) и всрок. Вот по моему основная сложность руководства любым проектом.
Во вторых нужно конечно стремится к привлечению профессионалов в команду. Или хотя бы к обучению профессионалов. Но поверте на слово, если человек не хочет профессионально работать и гордится своей работой, хотя созданны все условия (и это действительно так) его не заставишь.
Понимаю, что в реальности ПМ работает с теме людьми, которые ему выделило начальство фирмы. А наши софтверные конторы в основном занимаются аутсорсом и конкурируют с сотнями индусов-скриптеров на рынке, отсюда и набор подешевле та побольше. (короче студетнты 3-е курсники в лучшем случае с профильных факультетов, сам так начинал :-) ).
Во вторых нужно конечно стремится к привлечению профессионалов в команду. Или хотя бы к обучению профессионалов. Но поверте на слово, если человек не хочет профессионально работать и гордится своей работой, хотя созданны все условия (и это действительно так) его не заставишь.
Понимаю, что в реальности ПМ работает с теме людьми, которые ему выделило начальство фирмы. А наши софтверные конторы в основном занимаются аутсорсом и конкурируют с сотнями индусов-скриптеров на рынке, отсюда и набор подешевле та побольше. (короче студетнты 3-е курсники в лучшем случае с профильных факультетов, сам так начинал :-) ).
Описанная Вами ситуация говорит об отсутствии нормального процесса внутри компании.
1. Программист сопровождает 10 проектов.
Выделите саппортеров, из тех же программистов. Пусть каждый программист работает в саппорте в течение 1-2 недель с ротацией, но не вешайте саппортные работы программисту в "фоновом режиме".
2. А то он реализует мегафичу, которой не было в эстимейте.
Это вопрос планирования. Если вы высыпаете программисту пачку тасков с одинаковым приоритетом и дедлайном через 3 месяца, разумеется он может увлечься и отклониться от цели. Малые итерации с небольшим набором задач исправят положение.
3. Упс.
4. Если свободное время есть - пусть переписывает.
Рефакторинг необходимо закладывать в бюджет проекта. Отсутствие рефакторинга - смерть для саппорта, багфиксинга и модификации системы в будущем.
5. Положение может исправить TDD. Идеальный вариант после реализации фичи через TDD за код садится другой разработчик и пытается придумать варианты как сломать реализацию не выходя за рамки поставленной задачи. См также пункт 4.
6. А если дэдлайн через 2 дня, а на проект выделено 100 часов?
Привлечение доп. программистов задержит выход системы еще больше (с) Брукс. От себя: не нужно браться за те задачи, которые вы не в силах потянуть маленькой командой в оговоренный срок.
7. упс.
8. Каким боком программист связан с прототипом??
Самым прямым боком. Имеется ввиду не "прототип в Visio", а рабочий прототип части проекта, который можно потыкать и оценить насколько созданное решение в прототипе подходит для поставленной задачи.
P.S. Вы случайно не в Viaden Media работаете? ;-)
1. Программист сопровождает 10 проектов.
Выделите саппортеров, из тех же программистов. Пусть каждый программист работает в саппорте в течение 1-2 недель с ротацией, но не вешайте саппортные работы программисту в "фоновом режиме".
2. А то он реализует мегафичу, которой не было в эстимейте.
Это вопрос планирования. Если вы высыпаете программисту пачку тасков с одинаковым приоритетом и дедлайном через 3 месяца, разумеется он может увлечься и отклониться от цели. Малые итерации с небольшим набором задач исправят положение.
3. Упс.
4. Если свободное время есть - пусть переписывает.
Рефакторинг необходимо закладывать в бюджет проекта. Отсутствие рефакторинга - смерть для саппорта, багфиксинга и модификации системы в будущем.
5. Положение может исправить TDD. Идеальный вариант после реализации фичи через TDD за код садится другой разработчик и пытается придумать варианты как сломать реализацию не выходя за рамки поставленной задачи. См также пункт 4.
6. А если дэдлайн через 2 дня, а на проект выделено 100 часов?
Привлечение доп. программистов задержит выход системы еще больше (с) Брукс. От себя: не нужно браться за те задачи, которые вы не в силах потянуть маленькой командой в оговоренный срок.
7. упс.
8. Каким боком программист связан с прототипом??
Самым прямым боком. Имеется ввиду не "прототип в Visio", а рабочий прототип части проекта, который можно потыкать и оценить насколько созданное решение в прототипе подходит для поставленной задачи.
P.S. Вы случайно не в Viaden Media работаете? ;-)
Вцелом статья понравилась, но я бы не стал воспринимать ее как абсолютную истину. Многие советы нужно анализировать на основании собственного опыта и подстраивать под себя. Наиболее спорным, на мой взгляд, является призыв работать запоем. Т.к. не смотря на то, что это действительно может повысить продуктивность, рисковать здоровьем ради этого не желательно.
Эммм.... Чуть-чуть оффтопа. Фамилия автора читается как "Грэм", а не "Грэхам".
Верно, верно ;)) Когда комментировал - писал на автомате копируя из спеллинга в статье, надо бы вспомнить было как сам читал и произносил это раньше ;))
Спасибо. Если честно, то не знал. Но тут достаточно спорный момент: либо сохранять оригинальное произношение, либо наиболее точно передавать имя на родном языке. Сорт хлеба, например, по-русски будет все-таки «Грехем», хотя по-английски слово читается, как вы правильно заметили, как «грэм».
Совет работать в одиночку довольно странен, проекты сейчас не маленькие. Мне кажется, что большинство советов из серии "как заработать на проекте", а не "как написать хороший код".
Грем ушёл вразрез экстремальному программированию.
Его право, в принципе.
Мне не нравится то, что написано в статье.
Как-то Спольски сказал, что у программиста есть некий «период продуктивности», у меня это 3-4 часа за рабочий день, за это время я способен сделать намного больше, чем за 8 часов непрерывного втыкания в монитор.
Кроме того товарищ olpa в своё время высказал здравую мысль о том, что программист не должен 100% времени сидеть у компутера.
В компутере сто тыщь мильёнов всяких прикольных отвлекающих штук (ну, например хабра или жж).
90% идей относительно реализации моих рабочих проектов приходят мне в голову по пути на работу/с работы. Я их просто записываю. Ну и вообще, на улице прекрасная погода, почему бы не погулять в парке и не подумать о проектах?
Его право, в принципе.
Мне не нравится то, что написано в статье.
Как-то Спольски сказал, что у программиста есть некий «период продуктивности», у меня это 3-4 часа за рабочий день, за это время я способен сделать намного больше, чем за 8 часов непрерывного втыкания в монитор.
Кроме того товарищ olpa в своё время высказал здравую мысль о том, что программист не должен 100% времени сидеть у компутера.
В компутере сто тыщь мильёнов всяких прикольных отвлекающих штук (ну, например хабра или жж).
90% идей относительно реализации моих рабочих проектов приходят мне в голову по пути на работу/с работы. Я их просто записываю. Ну и вообще, на улице прекрасная погода, почему бы не погулять в парке и не подумать о проектах?
Для личного проекта вполне подходит, я именно так и работаю.
Но для проекта, в котором работает больше одного человека- все вышеприведенное скорее зло, особенно касаемо пункта 7, я в этом плане сторонник pair программинга, потому что как только, кто нибудь из членов команда заболел/ушел в отпуск/проспал начинаются неприятности, потому как понять где лежит та или иная функциональность с чем она связана и т.п. невозможно даже при наличии документации.
Касаемо рефакторинга- главное, чтобы он не привратился в "патологический улучшай", я зачастую прикручивая какую-нибудь феньку "для себя", решаю "немножко с оптимизировать ядро", на что уходит куча моральных и физических сил.
Но для проекта, в котором работает больше одного человека- все вышеприведенное скорее зло, особенно касаемо пункта 7, я в этом плане сторонник pair программинга, потому что как только, кто нибудь из членов команда заболел/ушел в отпуск/проспал начинаются неприятности, потому как понять где лежит та или иная функциональность с чем она связана и т.п. невозможно даже при наличии документации.
Касаемо рефакторинга- главное, чтобы он не привратился в "патологический улучшай", я зачастую прикручивая какую-нибудь феньку "для себя", решаю "немножко с оптимизировать ядро", на что уходит куча моральных и физических сил.
НЛО прилетело и опубликовало эту надпись здесь
Все вышесказанное абсолютная истина для программирования типа "остаться в веках" и абсолютное зло для _производства_ продукта. Подробнее высказался в своем блоге (http://sgerr.blogspot.com/2007/09/vs.html).
P. S. Tom, спасибо за перевод.
P. S. Tom, спасибо за перевод.
По поводу "запоем" - самому приходилось засиживаться до глубокой ночи на работе. Личный рекорд - 38 часов, после 20-го часа работы мозг "отключился" и я часа 4 пытался написать небольшой участок кода. После мозг опять "включился" открылось даже не второе, но очередное дыхание и продуктивность опять вернулась в норму.
Про то что весь проект держится в голове - может быть и не совсем так. Лично я держу основные части и проблемные задачи, но уже когда работаю над ними. то лучше не отвлекаться.
По поводу включения в работу, которое бывает не наступает и в конец рабочего дня - вобще истина. Сегодня, я боюсь, у меня может так и произойти, уж слишком сильно отвлекаюсь :)
Про то что весь проект держится в голове - может быть и не совсем так. Лично я держу основные части и проблемные задачи, но уже когда работаю над ними. то лучше не отвлекаться.
По поводу включения в работу, которое бывает не наступает и в конец рабочего дня - вобще истина. Сегодня, я боюсь, у меня может так и произойти, уж слишком сильно отвлекаюсь :)
весьма жизненная статья, буквально камень с души (Юб) упал, когда прочитал, что:
> программист так или иначе справляется со множеством задач. Однако во многих случаях для этого ему приходится чуть ли не организовывать восстание против собственной компании. .... Этот кажущийся совершенно случайным набор привычек в их поведении имеет единственную причину: необходимость держать в своей голове весь проект целиком.
но вот тема работы не в офисе, а дома - совсем не раскрыта :о)
Странно, что в современной (aug 2007) статье не упоминаются pattern-ы, хотя бы GoF, которые гораздо больше соответствуют тому, что можно назвать образом программы, "сидящем в голове". Сказать, что "в голове сидит КОД" по-моему - это скорее частная ситуация, например оптимизации компактного блока, даже если вы "3. Пишите на лаконичных языках".
> программист может выйти из офиса, перекусить бутербродом сидя на лавочке, ни на минуту не отвлекаясь в это время от программы, над которой работает.
а вот к этому хочется добавить - СОЗНАТЕЛЬНО отвлекайтесь, чтобы дать возможность новой идее тоже засесть в голову :))
> программист так или иначе справляется со множеством задач. Однако во многих случаях для этого ему приходится чуть ли не организовывать восстание против собственной компании. .... Этот кажущийся совершенно случайным набор привычек в их поведении имеет единственную причину: необходимость держать в своей голове весь проект целиком.
но вот тема работы не в офисе, а дома - совсем не раскрыта :о)
Странно, что в современной (aug 2007) статье не упоминаются pattern-ы, хотя бы GoF, которые гораздо больше соответствуют тому, что можно назвать образом программы, "сидящем в голове". Сказать, что "в голове сидит КОД" по-моему - это скорее частная ситуация, например оптимизации компактного блока, даже если вы "3. Пишите на лаконичных языках".
> программист может выйти из офиса, перекусить бутербродом сидя на лавочке, ни на минуту не отвлекаясь в это время от программы, над которой работает.
а вот к этому хочется добавить - СОЗНАТЕЛЬНО отвлекайтесь, чтобы дать возможность новой идее тоже засесть в голову :))
яркий пример — компания Google со своим правилом 20/80. Итог — успешно развивающая компания, где есть место творчеству сотрудников и как видим, творчество не прошло мимо, а и родило основную массу продуктов компании.
За перевод спасибо, хороший мотиватор и шпаргалка.
За перевод спасибо, хороший мотиватор и шпаргалка.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Перевод статьи Пола Грэхема о «причудах» программистов