Завински: Здесь требуется согласовать интерфейс между модулями. Для того чтобы такой модульный подход работал, интерфейс между модулями должен быть простым и понятным. Тогда есть надежда, что согласование интерфейса пройдет без лишних воплей и будет проще выполнять обязательства по модулям. Думаю, лучший способ добиться нормального взаимодействия между модулями - сделать это взаимодействие максимально простым. В этом случае будет меньше возможностей для ошибок.
А сам процесс разделения на модули целиком зависит от проекта. Для некоторых типов веб-приложений первая ваша команда будет работать над пользовательским интерфейсом, вторая - над базой данных, третья - над кодом, выполняемым на сервере, четвертая - над кодом, который выполняется на клиентской машине. То же самое для настольного приложения. Форматы файлов, графический интерфейс пользователя, базовая структура команд.
Сейбел: Как вы распознаете таланты?
Завински: Даже не знаю. Я никогда не был тем, кто принимает людей на работу. А если и участвовал в собеседованиях, то мне всегда казалось, что у меня нет никаких идей по этому поводу. После собеседования я мог сказать, смогу или нет работать с этим человеком, но сказать, хороший это работник или нет, всего лишь поговорив с ним, я не мог. Мне всегда казалось, что это трудно сделать.
Сейбел: А если работник плохой? Есть ли надежный способ определить это?
Завински: Когда как. Например, я всегда старался избегать ярых сторонников шаблонов C++. Возможно, зря. Может быть, в том контексте, где они использовались, это было хорошим решением. Что касается тех, с кем я работал, умение отстаивать свою позицию очень ценилось, потому что все мы были большими любителями поспорить. В той обстановке это сильно помогало. Разумеется, на способность программировать это никак не влияет. Все это из области межличностных отношений.
Сейбел: А в другой команде это умение может оказаться очень вредным.
Завински: Само собой.
Сейбел: Складывается впечатление, что в Netscape вы, ребята, разделили все так, что разные люди владели разными частями системы. Одни считают, что это очень важно. Другие полагают, что для команды предпочтительнее коллективно владеть кодом. Что вы об этом думаете?
Завински: Со мной бывало и так, и так. Оба подхода имеют свои достоинства. Не думаю, что идея коллективного владения кодом так уж практична, поскольку кода бывает слишком много. Людям нужна специализация, иногда необходимы эксперты в конкретных вопросах. Обычно так и получается. Всегда оказывается, что есть код, с которым ты знаком лучше других, так уж вышло, что ты работал над этим модулем больше, чем кто-либо еще. Или оказывается, что какие-то части системы дороги тебе больше всего. Конечно же, хорошо, когда кто-то еще знаком с твоим кодом, если только ты не собираешься поддерживать свою часть системы вечно. Так или иначе, приходится кому-то доверить свой код. Хорошо, когда знание распространяется. Но также хорошо, когда есть кого винить. Если за что-то отвечают сразу все, значит, ответственного нет.
