Стандарты кодирования и другие практики в IT

[tangro]

В первом предложении 31 слово. Дальше не читал.

[Labunsky]

Вам явно не стоит открывать Гоголя :)

[Meredian]

Выскажусь про пример с юнитами. Юнит-тесты — инструмент разработчика. Не в компетенции менеджера запретить писать юнит-тесты. С тем же успехом может запрещать использовать библиотеки или анонимные функции.

[poxvuibr]

Не сталкивались с таким, да?

[Meredian]

Пока я был совсем юн и не имел опыта, то спрашивал "а может юниты напишем" и мне говорили "нет, времени нет, очень спешим!" Потом повезло, выпал проект, где я научился их правильно готовить, и после этого уже никого не спрашивал никогда — оказывается, с ними гораздо быстрее, чем без них.

[poxvuibr]

Юнит тесты менеджмент как правило любит, если кто их не любит, то это как правило разработчики.Но вообще я имел в виду что вы наверное не сталкивались с запретом менеджмента на библиотеки или анонимные функции.

[izvolov]

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

[poxvuibr]

Требования к продукту можно положить только в приёмочные тесты, которыми как правило занимаются тестировщики.
Требования к функциональности отдельного куска кода, наподобие класса, можно выразить в виде юнит тестов, но далеко не всегда. Конкарренси вот юнит тестами особенно не потестируешь.

Ну а говнокодеры которые сами не понимают чего пошут — они всё ещё разработчики, а не менеджеры. Менеджеры тесты любят практически всегда.

[izvolov]

Внезапно, бывают требования к отдельным функциям и классам.
Если нельзя выразить требования к функции или классу, то это говнокод, о чём я и говорю.

[poxvuibr]

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

[ZXSi]

Должен ли нормальный разработчик писать тесты или это обязанность тестеров?

[izvolov]

Код тестов пишет тот же, кто пишет код программной сущности (класса или функции).

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

Развёрнутое описание см здесь.

[poxvuibr]

А если юнит тесты есть, а приёмочных тестов нет, может ли программная сущность считаться готовой?

[izvolov]

У программной сущности (функции и класса) есть только модульные тесты.

Приёмочное, интеграционное, функциональное и прочие тестирования — происходят на другом уровне.

[poxvuibr]

А другие модули и классы в тестировании могут участвовать, или надо их мокать?

[izvolov]

или надо их мокать

Можно и обмокнуть. С мёдом, говорят, вкусно.

---

Короче, хватит паясничать. Код нужно писать так, чтобы его можно было тестировать. Иначе это говнокод.

Как конкретно этого добиться — отдельный разговор. Почитайте книги, посмотрите доклады.
Например, на конференции по плюсам недавно был доклад из этой серии: Илья Шишков, Принципы создания тестируемого кода.

[poxvuibr]

Я не паясничаю, вопрос с моками реально интересен и никто на него толком не отвечает. Я думал в вас есть по этому поводу мнение.

[Meredian]

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

[poxvuibr]

Ну вот я недавно столкнулся с решением менеджмента, накладывающим жётские ограничения на использование наследования. Там и графики и рассуждения про качество кода — только в путь это всё.

[aquamakc]

Есть большой проект с использованием Microsoft SQL. Проект пилится уже не один год (сдан, продаётся, внедряется, но постоянно допиливается). И вот пару лет назад руководство придумало: а давайте все переделаем на PostgreSQL… Это же стильно и модно! С большим трудом ценой многих седин и полугода ожесточённых баталий удалось оставить БД проекта без изменений.

[Shtucer]

9 пунктов, налагающие вполне себе табу. И десятый, контрольный, налагает табу на табу, хоть и с оговорками.

[VaalKIA]

Стандарты кодирования (программирование)

Тема не раскрыта, где unicode, где P-code, в конце, концов, где жизнеутверждающие истории про программирование в шестнадцатеричных кодах тумблерами с терминала…

[amarao]

Начали за здравие, кончили за упокой.

Первые пункты — офигенны, и их имеет смысл вполне серьёзно рассматривать как реальный стайлгайд при написании сообщений в комьюнити. Дальше начинается кафкианское юродствование.

Ещё замечание: «Слаженная работа команды, эффективная коммуникация между людьми не менее важна для успеха проекта.» — это для какого размера команды? Посмотрите на число коммитеров в openstack и подуймате, как они могут быть «слаженны». Однако, код всё равно пишется — во многом благодаря довольно неплохому styleguide'у.