Comments 53
— Вы, наверное, преподавателем работаете?
— А как вы догадались?
— Куча определений и рассуждения ни о чем.
— А как вы догадались?
— Куча определений и рассуждения ни о чем.
Я старался показать свою точку зрения на то, что программист может быть эффективнее, если ощущает себя «уютно». Статья получилась длинной, и это я еще из первого черновика удалил некоторые части. На самом деле не люблю преподавателей как раз за рассуждения ни о чем. Для меня эта тема была актуальной в последние дни, поэтому и написал статью такой развернутой.
Странно. Лично я, опираясь на свой опыт работы в команде (хорошей команде), нашел очень много «правды» в этой статье
Поэтому я обожаю такую фичу Xcode:
Сразу понятно кто что написал и почему
Сразу понятно кто что написал и почему
Называется git blame, есть, вроде, в любом приличном редакторе и, само собой, в консоли.
Тут уже отметили, что это есть в любой приличной IDE.
Считаю моветоном писать в аннотации к классу имя автора (дефолтный авто-шаблон класса, например), потому что практически любой класс в итоге является результатом совместных правок (в команде из трех человек и более) и нужно уже смотреть историю, чтобы выяснить по каждой конкретной строке. По большому счету даже не так важно, кто автор кода, если, например, в нем есть ошибка. Вопрос, как это исправить и не допустить в будущем. Уведомить автора тоже будет не лишним (например, в личной беседе или через ревью).
Считаю моветоном писать в аннотации к классу имя автора (дефолтный авто-шаблон класса, например), потому что практически любой класс в итоге является результатом совместных правок (в команде из трех человек и более) и нужно уже смотреть историю, чтобы выяснить по каждой конкретной строке. По большому счету даже не так важно, кто автор кода, если, например, в нем есть ошибка. Вопрос, как это исправить и не допустить в будущем. Уведомить автора тоже будет не лишним (например, в личной беседе или через ревью).
В нашем большом проекте использовался принцип «обезличенный программист»
* Есть архитектор, он знает всю архитектуру, любой человек в любое время может спросить у него как что работает
* Есть правила оформления кода
* Есть правила программирования (спец паттерны и подходы)
* Программист обязан программировать определенным образом и использовать определенные системы
Весь проект был разбит на большие области, и программист прикреплялся к области, но технически он мог работать в любой из них. Иногда программисты работали в двух областях, иногда перемещались между ними. Любой программист мог открыть чужой код из области которую он не понимает и увидеть знакомый код и в принципе даже его поддерживать.
* Есть архитектор, он знает всю архитектуру, любой человек в любое время может спросить у него как что работает
* Есть правила оформления кода
* Есть правила программирования (спец паттерны и подходы)
* Программист обязан программировать определенным образом и использовать определенные системы
Весь проект был разбит на большие области, и программист прикреплялся к области, но технически он мог работать в любой из них. Иногда программисты работали в двух областях, иногда перемещались между ними. Любой программист мог открыть чужой код из области которую он не понимает и увидеть знакомый код и в принципе даже его поддерживать.
Может возникнуть две крайности:
либо программист старается не беспокоить архитектора и по всем вопросам, не вошедшим в «правила», пишет свои велосипеды (сбоку);
либо он спрашивает каждую мелочь (здесь следует использовать while или foreach?).
либо программист старается не беспокоить архитектора и по всем вопросам, не вошедшим в «правила», пишет свои велосипеды (сбоку);
либо он спрашивает каждую мелочь (здесь следует использовать while или foreach?).
Крайности могут быть при любом подходе и это всегда и везде плохо.
Надо просто их недопускать
Надо просто их недопускать
А архитектора разве должен волновать вопрос «while или foreach»?
Так об этом в статье и речь. Программист может чувствовать себя неуютно, если видит конструкцию, которую сам предпочитает записывать по-другому. Поэтому кто-то может для ясности спросить у лидера: а как пишем циклы?
Мне кажется, программист, который донимаем архитектора стандартизацией «используем всегда циклы с постусловием или предусловием, из двух одинаковы выбираем foreach или for» — это программист, который решил поиздеваться и намеренно в крайности удариться, что бы всех достать… Имхо. На такие мелочи давно перестал обращать внимание, как и на всякие мелочи вроде
if (true условие) else {} и if (false условие) else {}. Всегда работал в небольших командах, по 2-5 программистов.Вот и молодцы. Люди такие вещи давно придумали и давно ими пользуются в других сферах.
Есть же отечественные и мировые стандарты на разработку проекта или на изготовление булочек.
Так инженер смотрящий чужой чертеж будет понимать технические решения незнакомых людей, а булочник придя в другую пекарню
не станет печь хлеб используя «этот белый порошок» и запекать его в «горячей коробке 123»
Я понимаю IT рынок развивается быстрее реального сектора, и Госстандарт наверняка не успевает выпускать адекватные нормы (это предположение. а так не знаю, не в курсе), но это не значит, что эту сферу деятельности не стоит стандартизировать., хотя бы на уровне СТО
Есть же отечественные и мировые стандарты на разработку проекта или на изготовление булочек.
Так инженер смотрящий чужой чертеж будет понимать технические решения незнакомых людей, а булочник придя в другую пекарню
не станет печь хлеб используя «этот белый порошок» и запекать его в «горячей коробке 123»
Я понимаю IT рынок развивается быстрее реального сектора, и Госстандарт наверняка не успевает выпускать адекватные нормы (это предположение. а так не знаю, не в курсе), но это не значит, что эту сферу деятельности не стоит стандартизировать., хотя бы на уровне СТО
Так инженер смотрящий чужой чертеж будет понимать технические решения незнакомых людейОй ли? Много ли случаев когда разработку чего-либо передавали в другое КБ и там сходу всё люди понимали и делали «как надо»? Я скорее слышал об обратных случаях: когда процесс передачи занимал годы, когда люди постепенно разбирались в технических решениях и только потом сначала осторожненько, а потом всё смелее и смелее начинали вносить изменения в конструкцию.
булочник придя в другую пекарню не станет печь хлеб используя «этот белый порошок» и запекать его в «горячей коробке 123»С булочником ситуация иная: он «встроен» в уже готовый отлаженный, выверенный и стандартизованный техпроцесс порождающий на выходе стандартные, выверенные и стандартизованные вещи (булки, в данном случае), потому максимум, чего он может сделать — внести в него небольшие усовершенствования.
Я понимаю IT рынок развивается быстрее реального сектора, и Госстандарт наверняка не успевает выпускать адекватные нормы (это предположение. а так не знаю, не в курсе), но это не значит, что эту сферу деятельности не стоит стандартизировать., хотя бы на уровне СТООтличия IT рынка от других в том, что в нём, в общем, нет булочников: не бывает профессии «специалист по работе с программой X» или «специалист по написанию foreach». Как только умение становится достаточно «типовым», чтобы для него начинало иметь смысл писать СТО — оно перекочёвывает в wizard, программу автоформатирования или ещё куда и людям с ним больше сталкиваться уже не нужно. Грубо говоря в IP как только процесс порождения чего-либо становится стандартизован, выверен и начинает порождать более-менее одинаковые результаты — он перестаёт быть епархией человека. Грубо говоря в IP есть конструкторы машин для хлебопечения, есть установщики машин для хлебопечения, но не булочников. Ну хорошо, люди, которые таскают сервера в датацентрах могут быть приравнены к булочникам. И вы не поверите — но у них строгий регламент и всё очень точно рассчитано и расписано. Программист — он ни разу не булочник (а если у вас он оказался булочником, то вы что-то делаете не так и тратите дорогой ручной труд на то, что должна, по большому счёту, делать машина).
Я считаю, что программирование — все еще искусство и творчество, а не рутинная, инженерная работа. Поэтому кто-то выбирает
Можно сделать разные стандарты и требования, таким образом уменьшится кол-во искусства в коде, и увеличится кол-во рутинной работы. Но в тоже время и у программистов будет меньше свободы творческого полета. К чему я клоню: может быть Ван Гог не стал бы Ван Гогом, если бы ему говорили какими мазками и какими красками пользоваться? А может быть египетские пирамиды не простояли бы столько времени, если бы у их архитекторов не было четких правил о том, как их строить.
Нужно понимать обе стороны медали. В каком-то проекте лучше написать побольше правил и требований, а в каком-то проекте лучше дать больше свободы программистам и поддерживать какую-то экосистему и баланс между ними без силовых методов. Нужно понимать и находить идеальный баланс между этими 2 вещами. И правильный баланс отличается от проекта к проекту.
foreach, а кто-то while, исходя из своего внутреннего состояния.Можно сделать разные стандарты и требования, таким образом уменьшится кол-во искусства в коде, и увеличится кол-во рутинной работы. Но в тоже время и у программистов будет меньше свободы творческого полета. К чему я клоню: может быть Ван Гог не стал бы Ван Гогом, если бы ему говорили какими мазками и какими красками пользоваться? А может быть египетские пирамиды не простояли бы столько времени, если бы у их архитекторов не было четких правил о том, как их строить.
Нужно понимать обе стороны медали. В каком-то проекте лучше написать побольше правил и требований, а в каком-то проекте лучше дать больше свободы программистам и поддерживать какую-то экосистему и баланс между ними без силовых методов. Нужно понимать и находить идеальный баланс между этими 2 вещами. И правильный баланс отличается от проекта к проекту.
По-моему, стандартизировать нечто стоит, если на проекте работает более одного программиста и стандартизировать конкретно правила взаимодействия между модулями и «чужими» (условно) классами, это обязательно. А вот стандартизация того, что будет внутри — уже локально решать.
Вы абсолютно правы, во всём нужен разумный баланс. перегибы это всегда не к добру.
Единственное вы удивитесь, инженерия такое же творчество, как написание кода — рутина, это вопрос восприятия и конкретных задач, у меня была знакомая парикмахер, так вот для нее оболванить чью-либо голову тоже было творчество, наверное по этому к ней была всегда очередь :)
Единственное вы удивитесь, инженерия такое же творчество, как написание кода — рутина, это вопрос восприятия и конкретных задач, у меня была знакомая парикмахер, так вот для нее оболванить чью-либо голову тоже было творчество, наверное по этому к ней была всегда очередь :)
Ой ли? Много ли случаев когда разработку чего-либо передавали в другое КБ и там сходу всё люди понимали и делали «как надо»?
Это отечественное разгильдяйство. Мой знакомый часто говорил раньше фразу: «Я инженер — делаю, как хочу».
Поэтому например можно взять 4 чертежа с планировками и на всех трех будут разные двери, где-то они будут взяты с плана эвакуации. где-то их вставят, как готовый объект из Visio и конвертируют в dwg. где-то их начертят по соответствующему ГОСТ, а где-то выпилят из Архикада.
А ведь если двери не по ГОСТ, то уже и окна не по ГОСТ, сиди вот и гадай окно это или клапан сброса давления или вентиляционная решётка. Это только один маленький пример, говорящий о том, что система стандартов не сильно виновата в том, что исполнители даже не хотят задуматься о других, а преследуют целью только скорейшую сдачу проекта.
Касательно аналогий IT и булочников.
Вы правы есть специалисты, которые таскают сервера в дата центрах, есть Web мастера или Аникейщики низкой квалификации, которые встраиваются в процесс и вполне могут действовать по инструкции.
Так что вы удивитесь бывает специалист по работе с программой X, полистайте вакансии, вполне найдете человека с ограниченной деятельностью и в мире IT, например Administrator — joomla, или контент менеджер в компанию со своей cms, чем вам не пекарь-технолог второго разряда? Но названные люди формально тоже IT-шники.
Если лично вы программист вы — молодец, приравняйте себя к шеф повару. Хорошего, шефа мало, что ограничивает. ну кроме все тех же санитарных стандартов от которых заквасит безопасность людей и «хотелок» заказчика.
Я всё к тому. что IT кажется считают себя сверх-людьми, но фишка в том, что космонавты, летчики, бухгалтера, психологи, детские педагоги, работники автосервиса, как бы тоже считают себя уникальными. Так, что общие гуманитарные институты, такие например как система коммуникации и какой-то стандартизации деятельности полезны всем.
От себя отмечу, я проектировщик, если хотите тоже не «булочник на конвейере», я волен принимать те или иные технические решения. как мне придет в голову, но это не освобождает меня от необходимости (как минимум моральной), оформлять документации по ГОСТ 21.1101, придерживаться сводов правил и федеральных законов, и в случаях когда все складывается более менее нормально, это дает возможность проверяющей стороне не рвать на себе волосы пару лет вникая в чертежи, а потратить существенно меньшее количество времени (рвать волосы конечно все равно придется, но это уже будет зависеть от оборудования и технических условий).
П.с В конце концов у нас есть правила русского языка, тоже стандарт и холиваров вокруг «ться/тся». разводят существенно больше чем оно этого заслуживает, так почему бы не соблюдать так же рьяно другие стандарты?
Зачем стараться что-то рефакторить и улучшать, если завтра придёт Петя/Вася и в идеально вылизанный модуль накопипастит портянки говнокода? Правильно, незачем. Проще навтыкать костылей и пусть эти Пети/Васи с ними потом попробуют разобраться. Главное, что я сейчас свой таск закрыл быстрее.
Ну и сам себе дурак. Будут баги, будут доделки.Да, но это будет уже другая задача.
Вероятность, что самому же придется ковырятся в своем говне высока.С чего вдруг?
Описываемое вами поведение характерно для аутсорсных команд, но не типично для инсортных.Неправда ваша тётенька, я наблюдал это и на аутсорсных и на инсорсных командах. Все люди одним миром мазаны.
Играет роль не аутсорс/инсорс, а тупо размер команды: пока она мала вероятность того, что тебе «придётся ковыряться в своем говне» действительно высока, но чем больше в команде людей, тем она ниже и тем проще прослыть «крутым» быстро «затыкая» проблемы добавлением кучек говнокода. Разумеется чем больше команда тем больше вероятность привлечения аутсорсников — потому у вас в голове, по всей видимости, эти понятия и перемешались.
У вас какая-то анархия. Если приходит Петя-социопат и начинает говнокодить наперекор командным практикам, то дальше с ним уже общается непосредственный начальник.
Понятие «говнокодить» субъективное. Кто-то хорошо и быстро лепит костыли. А другой разработчик предпочитает возводить монады средствами шаблонов C++. По идее, начальство должно уволить второго, он медленнее пишет несложные задачи. Особенно если первый скажет: «ОК, некрасиво.Зато работает и написано в 3 раза быстрее. Вам подзависшие проекты надо вовремя сдать или красоту наводить?». Значит, второй будет в своих модулях (которые он оптимизировал очень усердно) терпеть всякие некритичные ляпы, типа передачу строк по значению, а не ссылке. Сам он их не поправит, потому что скажут ему: зачем ты усложняешь, ведь место не критичное, и пользоваль эти 8ms не заметит. Так что совместное владение требует одинаковости сотрудников, или они будут страдать.
Иногда с точки зрения бизнеса выгоднее накостылить и забыть.
Особенно, когда креативные заказчики фонтанируют идеями (например, по дизайну, ценообразованию или мотивации) с запутанными формулировками, с неясной логикой и для которых через месяц оказывается, что идея была неработоспособная или требует изменений в корне. Если код с большой вероятностью не доживёт до следующей версии, какой смысл его писать хорошо и медленно.
Особенно, когда креативные заказчики фонтанируют идеями (например, по дизайну, ценообразованию или мотивации) с запутанными формулировками, с неясной логикой и для которых через месяц оказывается, что идея была неработоспособная или требует изменений в корне. Если код с большой вероятностью не доживёт до следующей версии, какой смысл его писать хорошо и медленно.
Вариант «разработчик не может общаться с заказчиком — только менеджером/руководителем проекта, а тот не точно собрал бизнес требования» вами не рассматривается? Разработчик непосредственно с заказчиком общается не то что бы часто, мягко говоря, но это мой конечно опыт…
«Программирование — это единственная область, где с костылями быстрее, чем без них» Максим Дорофеев
То есть раз уж не получается добиться того, чтобы вся команда всё время работала эффективно, то вы предлагаете снизить эффективность работы всей команды во всех случаях?
На разных людей необходимость копаться в чужом коде действует по разному, но она во всех случаях снижает уровень критичности (если это не твой код, то так ли важно поддерживать его в чистоте?) и зачастую снижает производительность (либо скорость написания кода резко падает, либо, наоборот, кода пишется много, но очень «грязного», после чего куча времени уходит на отладку).
P.S.Только не нужно рассказывать про то, что можно завести правила, в которых всё чётко описать. Написание кода тем и отличается от жарки картофеля в Макдональдсе, что там каждый раз новая задача и всех ньюансов не опишешь. Сколько бы бумаг не было написано, если вы правите «чужой» код судьба которого вам безразлична, то вы найдёте 100500 способов облегчить себе жизнь здесь и сейчас за счёт усложнения жизни ваших последователей.
На разных людей необходимость копаться в чужом коде действует по разному, но она во всех случаях снижает уровень критичности (если это не твой код, то так ли важно поддерживать его в чистоте?) и зачастую снижает производительность (либо скорость написания кода резко падает, либо, наоборот, кода пишется много, но очень «грязного», после чего куча времени уходит на отладку).
P.S.Только не нужно рассказывать про то, что можно завести правила, в которых всё чётко описать. Написание кода тем и отличается от жарки картофеля в Макдональдсе, что там каждый раз новая задача и всех ньюансов не опишешь. Сколько бы бумаг не было написано, если вы правите «чужой» код судьба которого вам безразлична, то вы найдёте 100500 способов облегчить себе жизнь здесь и сейчас за счёт усложнения жизни ваших последователей.
Это хороший подход, но он масштабируется на 5-10 человек, не больше. Просто потому что ваш пресловутый тимлид за всеми уследить не может, а на первых порах подход «я свою проблему решил, а как они будут с этим жить меня не волнует» позволяет человеку показывать объективно лучшие результаты, так что соблазн именно так и поступить слишком велик. Ибо вероятность того, что тебе снова придётся копаться в своём собственном говне становится слишком мала. После этого либо появляются OWNERS, либо код начинает неудержимо скатываться в безумную кашу, к которой все испытывают отвращение и судьба которой, по большому счёту, никого не волнует.
Да, безусловно поддерживать высокий эмоциональный настрой программистов становится сложнее и сложнее с увеличением кол-ва членов команды. Но ведь хорошо сплоченный коллектив, состоящий из 5-10 обученных и взаимоуважающих программистов, может написать достаточное кол-во кода. Если 5-10 людей не хватает для развития и поддержания этого проекта, то может быть лучше разбить этот проект на 2 подпроектика (создать «норку»), чтобы поддерживать кол-во людей в команде в этом вразумительном районе (5-10 чел). И пускай члены одного подпроекта могут видеть исходный код другого подпроекта, но править тот код не нужно их заставлять.
Я абзац выше написал из чистого воображения, на самом деле я никогда не работал в команде состоящей из больше чем 3 человека. Но мне очень хотелось бы иметь именно такой подход к программистам при увеличении числа работников :)
Я абзац выше написал из чистого воображения, на самом деле я никогда не работал в команде состоящей из больше чем 3 человека. Но мне очень хотелось бы иметь именно такой подход к программистам при увеличении числа работников :)
Это говорит о низкой морали в коллективе. Биение кода на части только уменьшает мораль, это не выход. Лучше помучиться первое время, но вбить в голову программистам, что код общий, а не персональный. Сегодня нагадил ты, завтра сам ковыряешься в говне.
Г-да, какое отношение имеет мораль к коду? И вообще — а какой морали может быть речь в условиях суровой капиталистической действительности?
Ну… Очень интересно! Прям проф. Кузнецов. Поднял бы рейтинг, если бы мог :)
В команде, конечно, наиболее предпочтительно автоматное программирование, тогда и никакие заглушки не понадобятся.
В команде, конечно, наиболее предпочтительно автоматное программирование, тогда и никакие заглушки не понадобятся.
Написание кода тем и отличается от жарки картофеля в Макдональдсе, что там каждый раз новая задача и всех ньюансов не опишешь.
Читаем проф. Б.П. Кузнецова — «Психология автоматного программирования». Правда, это мало кому тут поможет… Кто сейчас что умное читает?
Читаем проф. Б.П. Кузнецова — «Психология автоматного программирования». Правда, это мало кому тут поможет… Кто сейчас что умное читает?
Я в проф-коммуникации разделяю условно компромисс и консенсус. В моем понимании компромисс — когда обе стороны идут на уступки, в итоге обе недовольны, но решение есть. Консенсус — когда обе стороны приходят к решению, которое обе стороны устраивает. Грань тонкая, консенсус возможен далеко не всегда.
Предложенный в статье способ разделения на «норки» мне знаком и стал результатом непреодолимых споров и изначальной договоренности равенства участников. IMHO, это плохой путь, лучше — вертикальная иерархия, т.е. спорные моменты разрешает тимлид, оценивая плюсы и риски решений (в том числе несогласие одной из сторон), тимлид берет ответственность за решение.
Что касается консенсуса, тут интереснее. Бывает, он возможен в малых командах, когда есть взаимное профессиональное уважение коллег и как правило их высокий уровень. Опять же IMHO, только такие команды способны ценой малого числа участников создать качественные продукты. Т.е. ключевое — это авторитет опытных сотрудников при условии их «адекватности» :)
Предложенный в статье способ разделения на «норки» мне знаком и стал результатом непреодолимых споров и изначальной договоренности равенства участников. IMHO, это плохой путь, лучше — вертикальная иерархия, т.е. спорные моменты разрешает тимлид, оценивая плюсы и риски решений (в том числе несогласие одной из сторон), тимлид берет ответственность за решение.
Что касается консенсуса, тут интереснее. Бывает, он возможен в малых командах, когда есть взаимное профессиональное уважение коллег и как правило их высокий уровень. Опять же IMHO, только такие команды способны ценой малого числа участников создать качественные продукты. Т.е. ключевое — это авторитет опытных сотрудников при условии их «адекватности» :)
Также, конечно, важным является наличие единого стандарта оформления кода — по сути, не важно какого, табы или пробелы и пр., суть в том что он должен быть единым для рабочей группы, а может и для департамента в целом. Если нужно — зафиксированным в виде статьи в локальной wiki, чтобы на него делать отсылку.
Общая кодовая база, даже пусть и с изъянами, зато хорошо и подробно знакомая всем участникам и используемая в десятке проектов — это лучше, чем 10 проектов, сделанных по-разному. Причем если это общеизвестные 3rd-party библиотеки вроде guava или apache commons — вообще здорово. Это упрощает вхождение программиста в новый проект, когда он видит знакомый код, совместное владение кодом повышается. Эти вопросы опять же на ответственности тимлида.
Ревью кода — безусловное добро. Даже старшие коллеги делились кодом на ревью и между собой и с коллегами ниже рангом, которые были «в теме».
При этом инициативы вроде использования альтернативного фреймворка (например, spring di в конкретном проекте вместо guice, как везде) могли быть поддержаны при условии взятия ответственности довести начатое до конца и предоставить необходимые консультации и пр.
Общая кодовая база, даже пусть и с изъянами, зато хорошо и подробно знакомая всем участникам и используемая в десятке проектов — это лучше, чем 10 проектов, сделанных по-разному. Причем если это общеизвестные 3rd-party библиотеки вроде guava или apache commons — вообще здорово. Это упрощает вхождение программиста в новый проект, когда он видит знакомый код, совместное владение кодом повышается. Эти вопросы опять же на ответственности тимлида.
Ревью кода — безусловное добро. Даже старшие коллеги делились кодом на ревью и между собой и с коллегами ниже рангом, которые были «в теме».
При этом инициативы вроде использования альтернативного фреймворка (например, spring di в конкретном проекте вместо guice, как везде) могли быть поддержаны при условии взятия ответственности довести начатое до конца и предоставить необходимые консультации и пр.
А мне из собственной практики нравится подход, когда проект разбит на разные тематические блоки и, при постановке задач, тимлид производит постоянную ротацию исполнителей, давая тебе задачи из разных областей проекта.
Sign up to leave a comment.
Психология программирования в команде