Под катом немного юмора и серьезных рассуждений о применении различных практик ведения проектов.
Как утверждается, эти стандарты позволяют писать более чистый и легко читаемый код. Они позволяют избегать некоторых видов ошибок кодирования, и облегчают поддержку программного продукта.
Однако, на мой взгляд, незаслуженно мало внимания уделяется тому, как члены команды взаимодействуют друг с другом. Слаженная работа команды, эффективная коммуникация между людьми не менее важна для успеха проекта. Недопонимание, неправильная интерпретация сказанного, трудно понимаемые комментарии в исходном коде в конечном итоге сказываются на качестве программного продукта.
Для того, чтобы заполнить этот пробел, предлагаю ввести 10 правил, которые бы позволили бы избежать наиболее досадных ситуаций, происходящих из неясного изложения своих мыслей:
- Не использовать предложения длиннее 15 слов.
- Не использовать более трех определений к одному существительному.
- Не использовать сложносочиненные предложения.
- В каждом предложении должно быть подлежащее и сказуемое.
- В одном предложении не допускается более одного деепричастного оборота.
- Должен быть подготовлен список из 5000 наиболее распространенных слов русского языка и профессиональных терминов. Слова и аббревиатуры, не входящие в этот список, могут быть употреблены только по согласованию с руководством проекта.
- Названия конкурирующих организаций могут употребляться только негативном контексте. В письменной речи упоминание конкурирующей организации должно сопровождаться пояснением в скобках: «(конкурирует с нами, контакты с этой организацией должны быть ограничены)».
- В рабочее время не допускается обсуждение политики компании. В мире много несправедливости, и в том числе несправедливость может исходить от нашей компании. Но это не означает, что компания должна оплачивать время, потраченное на обсуждение этой несправедливости.
- В случае недопустимого с точки зрения этих правил общения руководство проекта должно быть извещено в письменной форме.
- Табуированную лексику разрешается использовать только для ясности и четкости изложения своих мыслей. Табутрованная лексика не допускается:
- Если ее применение приводит к нарушению предыдущих 9 пунктов.
- Для выражения своего отношения к содержанию предыдущих 9 пунктов.
А теперь абсолютно серьезно.
Есть правила, имеющие универсальное и повсеместное применение. Это уголовный и гражданский кодексы, правила техники безопасности и пр. Соблюдение этих правил иногда позволяет избежать определенного рода неприятностей, но эти правила никоим образом не являются инструкцией, как достичь успеха.
Есть также книжки и психологические курсы о том, как быстро разбогатеть. Но мало кто воспринимает это всерьез. Не существует сколько-нибудь серьезно воспринимаемых правил или инструкций, гарантирующих успех проекта или успех в личной жизни.
Означает ли это, что к стандартам кодирования, разного рада практикам (SCRUM, Continues Integration, Code Review и пр.) не стоит относиться серьезно? Вовсе нет. Но надо понимать, что ни одна из практик в IT не является универсальной. Ни одна практика не приводит к гарантированному повышению эффективности проекта. Только накопленный опыт, интуиция и профессионализм менеджеров и ведущих разработчиков помогает принять правильное решение в каждой конкретной ситуации. Иначе бы наша профессия не была настолько трудной и интересной.
Если какой-то менеджер говорит о необходимости использования юнит тестов и аргументирует это красивыми диаграммами, убеждающими, что стоимость бага в геометрической прогрессии зависит от того, на какой стадии развития проекта этот баг найден – бегите из этого проекта или из этой компании. Я ничего не имею против юнит тестов. Однако, решение о том, использовать их или нет, и как их реализовывать, должно исходить из специфики данного проекта. Вот неполный перечень вопросов, на которые надо ответить прежде, чем принять решение:
- Насколько эффективными могли бы быть юнит тесты при разумных затратах на их реализацию?
- Есть ли другие способы тестирования приложения, и в какой степени они могли бы взять на себя те цели, которые преследуются юнит тестами?
- В какой степени юнит тесты необходимы для эффективного управления качеством продукта (quality assurance)?
- Есть ли необходимые средства в бюджете проекта?
- Как имплементация юнит тестов повлияет на сроки реализации проекта и в какой степени это критично?
- Есть ли консенсус в команде по этому вопросу? Если его нет, то что приоритетнее: сохранение мотивации отдельных членов команды или необходимость настоять на том решении, которое менеджеры считают правильным?
Если мне надо что-то разрубить, я ищу топор. Но если у меня есть топор, и я хорошо умею им пользоваться, то это вовсе не означает, что я буду бегать и искать, что бы разрубить. Точно также и с правилами/практиками в программировании. Если я хорошо владею какой-либо практикой, я не буду требовать, чтобы ее применяли повсеместно.
Комментарии (23)
Meredian
21.06.2016 20:20+1Выскажусь про пример с юнитами. Юнит-тесты — инструмент разработчика. Не в компетенции менеджера запретить писать юнит-тесты. С тем же успехом может запрещать использовать библиотеки или анонимные функции.
poxu
21.06.2016 22:32Не сталкивались с таким, да?
Meredian
21.06.2016 23:00+1Пока я был совсем юн и не имел опыта, то спрашивал "а может юниты напишем" и мне говорили "нет, времени нет, очень спешим!" Потом повезло, выпал проект, где я научился их правильно готовить, и после этого уже никого не спрашивал никогда — оказывается, с ними гораздо быстрее, чем без них.
poxu
21.06.2016 23:22Юнит тесты менеджмент как правило любит, если кто их не любит, то это как правило разработчики.Но вообще я имел в виду что вы наверное не сталкивались с запретом менеджмента на библиотеки или анонимные функции.
izvolov
22.06.2016 00:04-2Тесты не любят не разработчики, а говнокодеры, которые сами не понимают, что пишут. Нормальный программист не понимает, как вообще можно начинать писать код до того, как сформулированы требования (они же тесты, ага).
poxu
22.06.2016 11:03Требования к продукту можно положить только в приёмочные тесты, которыми как правило занимаются тестировщики.
Требования к функциональности отдельного куска кода, наподобие класса, можно выразить в виде юнит тестов, но далеко не всегда. Конкарренси вот юнит тестами особенно не потестируешь.
Ну а говнокодеры которые сами не понимают чего пошут — они всё ещё разработчики, а не менеджеры. Менеджеры тесты любят практически всегда.
ZXSi
22.06.2016 12:21Должен ли нормальный разработчик писать тесты или это обязанность тестеров?
izvolov
22.06.2016 12:28Код тестов пишет тот же, кто пишет код программной сущности (класса или функции).
Программная сущность не может считаться готовой, если к ней нет тестов (они же требования, документация и примеры использования).
Развёрнутое описание см здесь.
poxu
22.06.2016 12:55А если юнит тесты есть, а приёмочных тестов нет, может ли программная сущность считаться готовой?
izvolov
22.06.2016 12:58У программной сущности (функции и класса) есть только модульные тесты.
Приёмочное, интеграционное, функциональное и прочие тестирования — происходят на другом уровне.
poxu
22.06.2016 13:07А другие модули и классы в тестировании могут участвовать, или надо их мокать?
izvolov
22.06.2016 13:13или надо их мокать
Можно и обмокнуть. С мёдом, говорят, вкусно.
Короче, хватит паясничать. Код нужно писать так, чтобы его можно было тестировать. Иначе это говнокод.
Как конкретно этого добиться — отдельный разговор. Почитайте книги, посмотрите доклады.
Например, на конференции по плюсам недавно был доклад из этой серии: Илья Шишков, Принципы создания тестируемого кода.poxu
22.06.2016 13:57Я не паясничаю, вопрос с моками реально интересен и никто на него толком не отвечает. Я думал в вас есть по этому поводу мнение.
Meredian
22.06.2016 07:58Действительно, я не понял о чем вы. Лично в жизни встречался с запретами на отдельные библиотеки и конструкции языки, в принципе и на любой другой случай могу придумать разумные внешние ограничения. Но просто пример не про это — я говорил о волюнтаристских решениях менеджера, основанные на красивых графиках. Примеры взял такие, что бы они были понятны в среднем по индустрии.
poxu
22.06.2016 11:05Ну вот я недавно столкнулся с решением менеджмента, накладывающим жётские ограничения на использование наследования. Там и графики и рассуждения про качество кода — только в путь это всё.
aquamakc
22.06.2016 12:20Есть большой проект с использованием Microsoft SQL. Проект пилится уже не один год (сдан, продаётся, внедряется, но постоянно допиливается). И вот пару лет назад руководство придумало: а давайте все переделаем на PostgreSQL… Это же стильно и модно! С большим трудом ценой многих седин и полугода ожесточённых баталий удалось оставить БД проекта без изменений.
Shtucer
21.06.2016 23:039 пунктов, налагающие вполне себе табу. И десятый, контрольный, налагает табу на табу, хоть и с оговорками.
VaalKIA
22.06.2016 01:40Стандарты кодирования (программирование)
Тема не раскрыта, где unicode, где P-code, в конце, концов, где жизнеутверждающие истории про программирование в шестнадцатеричных кодах тумблерами с терминала…
amarao
22.06.2016 10:57Начали за здравие, кончили за упокой.
Первые пункты — офигенны, и их имеет смысл вполне серьёзно рассматривать как реальный стайлгайд при написании сообщений в комьюнити. Дальше начинается кафкианское юродствование.
Ещё замечание: «Слаженная работа команды, эффективная коммуникация между людьми не менее важна для успеха проекта.» — это для какого размера команды? Посмотрите на число коммитеров в openstack и подуймате, как они могут быть «слаженны». Однако, код всё равно пишется — во многом благодаря довольно неплохому styleguide'у.
tangro
В первом предложении 31 слово. Дальше не читал.
Labunsky
Вам явно не стоит открывать Гоголя :)