Разное

Как известно, "ВКонтакте" существует уже 6 лет. Как можно предположить, за это время программная часть давно уже отработана надлежащим образом.

Что там могут делать 30 программистов?

Просто непонятно, чем можно загрузить 30 человек, если в системе практически ничего не меняется? Сервера поддерживаются администраторами, а эти то что делают?

Миллион и один способ вывести в браузер "Hello Word".

Работают, новые фишки вводят, что-то оптимизируют, не проще у них спросить, коль известно сколько их там)

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

Как видите за 6 лет vk серьезно изменился. Добавлено много фишек, разработано api, которое постоянно дорабатывается, добавлен чат, вобщем-то там очень много.
Недавно еще разработчики разработали KPHP, альтернативу хип-хоп php от фейсбука. Вообщем-то можно бесконечно продолжать, но эти 30 разработчиков не зря кушают свой хлеб, работы там хватит

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

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

Как мне приватно сказал владелец одной из социальных сетей (не Вконтакте, другой), он вообще с ужасом ожидает, что система рухнет в один прекрасный день, ибо даже ничтожные изменения в какой-нибудь форме вызывают кучу проблем и работу всего коллектива в авральном режиме!

Программные системы немного похожи на лингвистические языки, чтобы они не умирали, их постоянно переписывают и изменяют, даже, если в этом нет надобности. Программные системы не живут без разработчиков. Код без разработчиков стоит 0, его можно раздавать бесплатно. Код может запутываться, главным образом из-за вот таких авралов. Поэтому берут часть системы и выделяют в отдельный, независимый, изолированный проект, на отдельном сервере, на отдельной базе данных, с отдельной командой. Между ними строят шлюзы и глухие перегородки, в виде API-интерфейсов. Все коммуникации - строго через него. Регистрироваться - будьте добры на этот сервер, картинку положить - на этот, сообщение оставляйте на следующем сервере, банеры можно взять в четвертого и т.д.

Старые системы используют как прототипы для разработки новых. Юанные переносят при помощи конверторов, недавно, кстати, такой писал для преобразования одной большой базы данных из формата старого проекта в новый. Конвертор (на чистом SQL) отработал 10 минут - портал на десятке серверов и его обвязка быстро и практически без проблем перешли со старого запутанного кода в новый пока прозрачный проект. Конвертор создавался и сопровождался в течение полугода, пока велась разработка новой версии. Это позволило отстрелить старый код, в который все боялись лазить (по той же самой причине - требовались безумные усилия по совпровождению). Все можно решить, но нужны разработчики и политическая воля (10 минут простоя, вместо 2-х суток стоит 6 месяцев работы SQL-разработчика).

Если так, то нужны горы документации на действующий код!

Более того, описание может стать даже важнее самой разработки нового кода, так что программист должен тратить значительную долю своего рабочего времени на составление описания того, что он уже сделал, даже в ущерб дальнейшем упродвижению!

Или составление документации не практикуется?

Практикуется, но документация имеет свойство устаревать и многие программисты не умеют и не любят её писать (однажды на сотни мегабайт кодов, я получил 2 листа документации формата А4, пришлось изучать и писать её самому). Иногда выручает автоматически собираемая документация, вроде phpDoc, особенно, если программисты все же придерживаются стандарта комментирования, но и комментарии могут устаревать. Код сам является текстом, который можно читать. Это требует времени, но не бесконечного (особенно, если есть хоть какая-то документация или комментарии изначально присутствуют, пусть даже это лишь 2 листа формата А4 :).

Правильно ли я понял, что толковые комментарии в РНР коде - это признак хорошего тона?

Хоть какие-то комментарии - это уже помощь тем, кто придет после нас.
Не обязательно даже в phpDoc.
Даже просто в конце строки:

здесь какой-то JS код        // а здесь описание, к какому визуальному элементу это относится

это уже экономия кучи времени.
Сегодня мне, чтобы написать каждый такой комментарий приходилось несколько раз переключиться между IDE и браузером и в IDE промотать пару раз вниз-вверх 15 экранов. Потому что <style/> <script/> и <body/> находятся в одном файле. Что, кстати, тоже признак дурного тона.

Документацию писать сложно и дорого....
Просто для того чтобы переключить мозг с языка кода на человеческий и сформулировать нужно приложить усилия.
Плюс к этому, нет смысла писать документацию, пока какая-то фишка не закончена. А когда закончена - уже есть очередь из очередных срочняков - это раз, и два - некоторые тонкости текущей версии либо упускаются из виду, либо, в силу погруженности человека в решение данной проблемы, считаются очевидными, и опускаются в документации.
Поэтому самый лучший способ документирования - это комментарии в коде.
Как очень верно заметил cheops:
> Код сам является текстом, который можно читать
а если при чтении встречаются еще и пояснения - это просто отлично. Кроме того, комментирование не занимает столько времени, сколько написание документации. Кроме того - документация, это все же, либо описание интерфейса, либо глобальное описание движка и т.п. Если же попытаться документировать код, то его (код) практически весь придется перенести в документацию в виде примеров использования каких-то терминов или реализаций. Комментирование же во-первых не займет столько времени, во-вторых будет всегда более актуальным, т.к. будет правиться одновременно с кодом.

P.S. Комментарии в стиле phpDoc тоже нужно уметь писать.... Одно дело перечислить какие аргументы передаются в функцию, и другое дело грамотно разъяснить что для чего предназначено и какой будет эффект при использовании разных типов данных.

Вообще я удивлен что всего 30. Крайне удивлен.