Category: архитектура

me

Один в поле не воин

Всем известна притча о путнике, который пришел в город и спрашивал, чем занимаются люди. Все рассказывали про частности; кто-то - тесал камни, кто-то - замешивал раствор и только один рабочий сказал, что он строит Кёльнский собор.

О чем эта притча? О том, что малый труд есть часть большого целого. Эта мысль настолько проста для всеобщего понимания, что практически все забывают про обратную сторону медали, а именно: результаты любого труда всегда персонализированы. Ты строишь собор, и по трудам твоим тебя запомнят как гениального каменотеса, строителя или художника.

Мы все плывем в одной лодке и цель одна. Но каждый делает свое дело. Эту меру ответственности не отнять, на других не сбросить и между чужими людьми не поделить.

Дикси спроектировал интерфейс. Саша и Иван нарисовали дизайн. Я придумал архитектуру серверной части. Вместе с Эдиком и Оскаром мы написали большую часть серверного кода. В этом нам неоценимо помог Костя. Саша и Антон сделали весь клиент-сайд. Дарья и Даня оттестировали. Дима, Андрей и Артем засетапили сервера. Максим поднял систему монитоинга. Ирина запустила проект. Новая почта не состоялась бы без всех вообще и каждого в отдельности. Кто здесь главнее и ценнее, я не знаю. Да и не особо хочу знать.

P.S. Кто на проекте найдет dopefish (да-да, ту самую) - тот молодец.
me

Лучшая документация - исходники проекта, ага

http://gaperton.livejournal.com/32772.html

Пиииииздеееец, какой же это пиздец. А через несколько лет такой разработки получается проект а-ля Rambler Mail, где в январе 2009 совершенно свободно можно было найти perl-скрипт в 120 килобайт размером, написанный в стиле "профузная диарея". С копипастой одного и того же кода и с решением одной и той же проблемы пятью разными способами (ну, это же Perl, TIMTOWTDI, еба!).

Отсутствие техдокументации у проекта тождественно отсутствию проекта. Если вам говорят, что исходники - лучшая документация, вам врут. Если вы считаете что диаграмма классов может все рассказать об архитектуре, вы врете сами себе.

Об архитектуре проекта может рассказать только проектная документация. Если документации нет - любая допущенная ошибка является частью архитектуры. Если никто не знает, что нужно и нужно ли вообще, какой код используется, а какой - нет, то вся надежда только на код из репозитория. А исходники говорят: "да это только вам кажется, что тут ошибка, на самом деле все так и было задумано". И вот вы исправляете то, что кажется ошибкой и работает возмутительно неправильно, а после этого с другого конца проекта отваливается очередная мегакритически важная система. Вот буквально неделю назад так все и произошло.

Отсюда простые правила:
1. Архитектура описывается в обязательном порядке на человеко-читаемом языке отдельно от исходников. Критерий качественности - чтобы свеженанятый разработчик понял что и где лежит и не подходил к "старичкам" с вопросами "а как оно работает?".

2. API вызовов документируется перед написанием вызова. Недокументированный вызов в продакшен не попадает.

3. Набор тестов пишется одновременно с написанием кода. Можно и до, главное - не после.

4. Тесты должны быть построены так, чтобы результатом их запуска были осмысленные легко проверяемые и (главное!) используемые в продакшене данные. Тестировать то, чего нет в продакшене, не имеет смысла.

5. Обязанность поддерживать проектную документацию и набор тестов в актуальном состоянии лежит на разработчиках и архитекторах.