Компания, где я работаю, разрабатывает крупные проекты. В некоторых направлениях компания занимает если не лидирующие позиции, то является крупным игроком на рынке. Программного кода очень много. Во время работы в среде разработки может быть открыто пожалуй несколько сотен проектов. Около сотни проектов являются запускаемыми приложениями.
Все очень круто, все очень сложно. Чтобы справляться со всем этим хозяйством компания нанимает лучших программистов. Поиск умов производится не только среди специалистов с опытом, но также среди студентов. Нужны только лучшие сотрудники, только вперед.
На фоне этого после трех месяцев работы у меня возникли некоторые мысли о разработке крупных проектов. Эти мысли - не полный анализ проблемы, а некий мессидж возможным читателям этой статьи.
Недавно в Hacker News была статья, которая получила большое количество плюсов о сложности больших проектов. Автор предлагал разбивать сложные системы на подсистемы и уменьшать количество кода, в который должен вникать программист. В компании JetBrains используется такой подход, что программист может отвечать за какие-то части проекта и становиться в них гуру, хотя обычно в других компаниях на большом проекте вся команда отвечает за весь проект.
Вот давайте взглянем на Linux. Одна задача – одна программа. Чтобы что-то сделать в Linux и понять, как это работает в 99.999% случаев не нужно заглядывать в код. Современные же принципы разработки в России почему-то предлагают не писать комментарии. Говорят, нужно писать код так, чтобы он легко читался, тогда не будут нужны комментарии.
Все классно, только вот зачем все публичные API типа Twitter и Facebook содержат документацию. Ведь из названия методов и так должно быть все понятно? Наверное, объяснение, зачем нужны комментарии заслуживает отдельной статьи, хотя я никогда не думал, что вообще когда-нибудь возникнет такая потребность объяснять, зачем нужны комментарии. Мне даже рассказывали случай на стажировке, где гуру указал новичку, что у него плохой код, потому что там есть комментарии.
Ну ладно, к комментариям можно вернуться в отдельной статье. Итак, я предлагаю большие проекты разбивать на подпроекты, и распределять ответственность. Что еще можно сделать?
Раз компания большая и в ней много проектов, то в разных проектах часто возникают однотипные задачи. Вот даже твиттер, где только один проект – собственно сам твиттер выделил CSS-framework в отдельный проект. Необходимо увеличивать долю проектов, которые используются повсеместно в компании. Необходимо создавать проекты, которые решают какие-то общие задачи, связанные с версткой, какой-то часто используемой бизнес-логикой.
Еще одна проблема, на которую я хотел бы обратить внимание – это юнит-тесты. Юнит-тесты пишутся на каждый участок кода. Это увеличивает время разработки, но также повышает надежность. При этом, качество кода юнит-тестов хуже, чем у остального кода. Из-за стремления тестировать все-все-все тесты часто дублируют друг друга, а иногда дублируют сам код. Это приводит к тому, что программу очень сложно модифицировать.
Тесты – это тоже часть программы и для тестов также необходимо продумывать архитектуру и делать так, чтобы не было повторного кода и код был красив. Вместо увеличения количества проверок в тестах необходимо больше думать об их разнообразии, создании необычных условий, в которых программа могла бы сломаться.
Часто компании, которые продают программные продукты, сетуют на то, что клиенты не хотят повышать производительность и внедрять автоматизацию, которая принесла бы ощутимую прибыль. Есть прибыль – и ладно. Да, это не так просто – все время себя заставлять делать лучше, но если не стремиться к лучшему, то становится скучно.
Все очень круто, все очень сложно. Чтобы справляться со всем этим хозяйством компания нанимает лучших программистов. Поиск умов производится не только среди специалистов с опытом, но также среди студентов. Нужны только лучшие сотрудники, только вперед.
На фоне этого после трех месяцев работы у меня возникли некоторые мысли о разработке крупных проектов. Эти мысли - не полный анализ проблемы, а некий мессидж возможным читателям этой статьи.
Недавно в Hacker News была статья, которая получила большое количество плюсов о сложности больших проектов. Автор предлагал разбивать сложные системы на подсистемы и уменьшать количество кода, в который должен вникать программист. В компании JetBrains используется такой подход, что программист может отвечать за какие-то части проекта и становиться в них гуру, хотя обычно в других компаниях на большом проекте вся команда отвечает за весь проект.
Вот давайте взглянем на Linux. Одна задача – одна программа. Чтобы что-то сделать в Linux и понять, как это работает в 99.999% случаев не нужно заглядывать в код. Современные же принципы разработки в России почему-то предлагают не писать комментарии. Говорят, нужно писать код так, чтобы он легко читался, тогда не будут нужны комментарии.
Все классно, только вот зачем все публичные API типа Twitter и Facebook содержат документацию. Ведь из названия методов и так должно быть все понятно? Наверное, объяснение, зачем нужны комментарии заслуживает отдельной статьи, хотя я никогда не думал, что вообще когда-нибудь возникнет такая потребность объяснять, зачем нужны комментарии. Мне даже рассказывали случай на стажировке, где гуру указал новичку, что у него плохой код, потому что там есть комментарии.
Ну ладно, к комментариям можно вернуться в отдельной статье. Итак, я предлагаю большие проекты разбивать на подпроекты, и распределять ответственность. Что еще можно сделать?
Раз компания большая и в ней много проектов, то в разных проектах часто возникают однотипные задачи. Вот даже твиттер, где только один проект – собственно сам твиттер выделил CSS-framework в отдельный проект. Необходимо увеличивать долю проектов, которые используются повсеместно в компании. Необходимо создавать проекты, которые решают какие-то общие задачи, связанные с версткой, какой-то часто используемой бизнес-логикой.
Еще одна проблема, на которую я хотел бы обратить внимание – это юнит-тесты. Юнит-тесты пишутся на каждый участок кода. Это увеличивает время разработки, но также повышает надежность. При этом, качество кода юнит-тестов хуже, чем у остального кода. Из-за стремления тестировать все-все-все тесты часто дублируют друг друга, а иногда дублируют сам код. Это приводит к тому, что программу очень сложно модифицировать.
Тесты – это тоже часть программы и для тестов также необходимо продумывать архитектуру и делать так, чтобы не было повторного кода и код был красив. Вместо увеличения количества проверок в тестах необходимо больше думать об их разнообразии, создании необычных условий, в которых программа могла бы сломаться.
Часто компании, которые продают программные продукты, сетуют на то, что клиенты не хотят повышать производительность и внедрять автоматизацию, которая принесла бы ощутимую прибыль. Есть прибыль – и ладно. Да, это не так просто – все время себя заставлять делать лучше, но если не стремиться к лучшему, то становится скучно.
Комментарии
Отправить комментарий