пособие по выживанию

КРИС КАСПЕРСКИ

Спецвыпуск: Хакер, номер #071, стр. 071-012-5

А вот и другая сторона медали (очень часто упускаемая маркетоидами из виду). Привычка — это вторая натура и от нее никуда не уйти. Кодирование в «неестественном» стиле значительно снижает производительность труда и одновременно с этим затрудняет поиск ошибок «глазами». К тому же, если программист использует фрагменты ранее написанных листингов, их придется реконструировать в соответствии с правилами кодирования, а это не только впустую потраченное время, но еще и вероятность внесения ошибок в уже отлаженный код. А что если один и тот же исходный файл используется в нескольких независимых проектах, каждый из которых велит придерживаться своих правил кодирования?! Как развивать и сопровождать такой файл? Это же сдохнуть можно, если вручную синхронизовать несколько проектов без подходящих средств оптимизации!

Правило номер три: если тебя не устраивает стандарт кодирования, принятый в команде, пиши в своем стиле, пытаясь убедить остальных в том, что от этого никому хуже не станет. Как показывает мыщъх'ный опыт, в большинстве случаев это срабатывает. Стиль программирования — это вообще-то, так, ерунда. Бюрократическая волокита. Гораздо важнее сразу определиться с используемыми языками и компиляторами. Допустим, 9 из 10 членов команды пишут на Си, а один — на DELPHI. Состыковать откомпилированные модули не проблема, но вот для эффективной работы каждый участник проекта должен понимать любого другого. Мы не можем просто сказать — возьми DELPHI и напиши крутой интерфейс для нашей программы, поскольку сразу же возникает вопрос: а, что, собственно, писать? Какими функциями обладает программа на данный момент, и какими она (возможно) будет обладать? К тому же, интерфейс полностью отделен от вычислительной части лишь в книжках по программированию, а в реальной жизни все компоненты программы связаны друг с другом, и если DELPHI-программист абсолютно не разбирается в Си, остальные члены команды будут вынуждены постоянно отвлекаться от своей работы, объясняя ему что и как. И наоборот. Си-программисты обязаны знать DELPHI хотя бы на минимальном уровне, чтобы самостоятельно собрать проект без посторонней помощи.

Крайне нежелательно использовать в проекте языки, которые кроме тебя никто не знает (например, Haskell или Ruby), поскольку это ставит в зависимость остальных членов проекта. В результате ты становишься незаменимым носителем знания. В команде, состоящей из нескольких человек, с этим еще можно как-то смириться, но вот крупные коллективы тебя просто попрут. И правильно сделают! А вдруг ты решишь уйти или забросить проект, занявшись другими неотложными делами? Кто разберется в твоих исходных текстах, если потребуется исправить баг или добавить новую фичу? Какой смысл ставить под удар труд десятков людей только потому, что на таком-то языке задача решаться чуть-чуть более эффективно, чем на общепринятых?