Comments 54
— А как вы догадались?
— Куча определений и рассуждения ни о чем.

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