Во время разработки любого проекта самое пристальное внимание стоит обращать на качество кода и аспекты документирования. Для меня это аксиома, для многих других нет.
Заказчику как правило все равно, как там оно работает внутри, лишь бы все работало. Такой подход к разработке складывается и у разработчиков проекта. Может показаться, что так это и правильно, главное ведь, чтобы проект работал? В этой статье я хочу рассказать, как можно сэкономить деньги при разработке программного продукта.
Часто временные рамки не позволяют “сделать красиво” в коде проекта, часто сделать это мешает квалификация разработчиков. Но очень важно, чтобы проект был красив не только снаружи, но и изнутри, в архитектуре и коде. Заказчикам часто все равно, а зря - они несут лишние потери денег, и вот почему:
Код не документирован, либо документирован плохо, непонятно.
Для программистов проекта и новых людей, включившихся в разработку это означает больше потраченного времени на понимание всех нюансов работы проекта и отдельных компонентов. Новые программисты будут отвлекать других работников, чтобы расспросить о каких-то деталях. В итоге, теряется время, его теряется больше, чем на написание документации в процессе разработки проекта, так как каждому новому члену команды каждый раз приходится объяснять работу проекта. Для заказчика это - потеря денег.
Поэтому, при разработке чего-угодно, даже если над этим трудится один человек, необходимо писать документацию - вы же не знаете, может в дальнейшем ваша команда расширится. Документацию необходимо проверять, перечитывать - она должна быть понятной. От сложной, запутанной документации толку нет, это то же самое, как если бы документации не было вообще. Курировать создание документации должен тим-лидер проекта.
Кривой код
Кривой код это большая беда как для заказчика, так и для всех, кто работает над проектом. Заказчик теряет гораздо больше денег, потому что разработчикам требуется больше времени, чтобы внедрить новые функции. Причем, чем дольше продолжается разработка, тем больше времени будет требоваться на добавление новой функциональности.
Для разработчиков же подобный труд превращается в рутину и нервотрепку, а этим вещам не место в программировании. За тем, какой код пишут разработчики должен следить тим-лидер, он должен часть своего рабочего времени уделять просмотру созданного ими кода и не лениться вносить комментарии и заставлять переписывать код, если он не соответствует принципам правильной разработки. Это очень важно, следить за качеством кода, в дальнейшем будет тратиться гораздо меньше времени на создание нового кода, а заказчик сэкономит деньги.
Проблемы с архитектурой
Вы должны знать, что и где у вас лежит. Классы, названия файлов - все должно соответствовать соглашению об именовании той среды, под которой вы ведете разработку. Я при работе над своими проектами уделяю очень много времени проектированию архитектуры, ведь это то, на чем будет строиться вся дальнейшая разработка. За годы работы, конечно, я пришел к некой стандартной для себя архитектуре, но которая все же улучшается от проекта к проекту.
Проектированию классов тоже стоит уделять особенно пристальное внимание. Если вы используете класс, это еще не говорит о том, что бы пишете ООП код (особенно это касается php-программистов). Нужно помнить, что класс - это “черный ящик”. Вам не должно быть важно, что и как происходит у него внутри, вам нужен только его интерфейс - доступные снаружи методы. Всю необходимую информацию, нужную классу для работы, нужно устанавливать только при помощи методов-сеттеров, класс не должен брать данный неизвестно откуда (например, из глобальных переменных).
Вообще, стоит почитать отдельную литературу по проектированию ООП кода. И одними паттернами тут дело не ограничивается. Я считаю что чуть ли не самое важное в ООП-подходе, это понять парадигму “черного ящика” - вот тогда придет просветление.
Кода архитектура вашего проекта отточена, вам всегда легко привнести в него новую функциональность, это будет происходить быстро, вы не будете долго раздумывать над тем, где разместить класс или файл, вы сэкономите кучу времени, а заказчик кучу денег и будет доволен, как быстро появляется новая функциональность.
Что делать дальше?
Нужно вести список дел, когда вы что-то разрабатываете. Большинство людей давно использует какие-либо системы ведения совместной разработки, где ведут список тикетов. Но часто тикеты ведутся неправильно. Один тикет должен содержать в себе ровно одну простую задачу. Не надо создавать таких тикетов, как например “Разработать систему добавления новостей”. Это порочная практика, вашему заказчику трудно отслеживать ход выполнения задачи в этом случае, и он начинает беспокоиться. Разбейте один тикет на много отдельных - повторюсь, в каждом должна быть простая и понятная задача.
Таким образом, вы будете всегда знать, что вам делать дальше, после выполнения очередной задачи. Это снизит простои (экономия средств заказчика), а вам будет просто вернуться к работе после бурных выходных. К тому же, за небольшую и простую задачу морально гораздо легче взяться. И заказчик будет радоваться, увидев, как часто вы закрываете тикеты.
Задачи тим-лидера
Я свято верю в то, что тим-лидер команды по разработке программного продукта должен быть и грамотным программистом и менеджером. Причем “программистская” составляющая намного важнее менеджерской - он ведь работает по большей части с программистами (хотя служит “мостом” между программистами и заказчиком). Я уверен в том, что тим-лидер не должен писать код вместе с программистами - он может проектировать архитектуру проекта совместно с ними, но писать код - задача программистов, тим-лидер же должен следить за чистотой кода, документацией и обеспечивать коммуникацию между всеми участниками проекта.
Вот и все пока. Наверное, что-то упустил, но если вспомню, то обязательно добавлю. Пока писал этот пост, появилась мысль об еще одном посте под кодовым названием “Как разработать проект с нуля”, в котором расскажу, как начать разработку проекта, на что вообще обращать внимание при разработке, что делать сначала и что потом.
Also interesting
Tags: архитектура проекта, деньги, заказчик, проектирование, разработка
Хочется возразить на утверждение, что тим-лид писать не должен. Если перестать писать, можно и квалификацию потерять (что не работает, то атрофируется), и “чувство кода” утратить. Согласен с тем, что у тим-лида много чисто менеджерской работы, но если он совсем перестанет писать, то это будет уже не тим-лид, а ПМ или архитектор (или технический директор - зависит от размеров компании/команды).
Ну тим-лид не должен писать такие штуки, типа форм или рассылки e-mail, я имел в виду именно это. Т.е. он не должен распыляться на рутинные задачи.
Тим-лид должен писать не то что бы код - а скорее, разрабатывать архитектуру системы или подсистемы. И тут уж ему никто не мешает накидать интерфейсов, а программисты пусть потом их реализуют. Конечно, тим-лид может взяться и за написание отдельного кода, если у него есть свободное время.
Эта моя статья нацелена скорее на небольшие команды разработчиков, где нет отдельных архитекторов проекта, а есть один лидер, которые управляет всеми программистами и взаимодействует с заказчиком.
Олег, я немного сумбурно описал, конечно (но что то не получается выстроить мысль стройно) - но думаю общий посыл будет понятен.
Ну да, писать код мелких рутинных задач тим-лиду несруки. С этим я согласен.