Отправляет email-рассылки с помощью сервиса Sendsay

Мастер программист

Подписаться Бесплатная новостная рассылка Подписчиков 18 RSS
  Октябрь 2008   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


За последние 60 дней ни разу не выходила


Открыта: 11-10-2008

Автор
Master Mind

Статистика

18 подписчиков
0 за неделю
←   Все выпуски   →

Мастер программист Работа программиста как она есть.


Статья 1. Введение

 

Работа программиста, как она есть.

Базовые способы облегчить труд.

 

Работа, как мы – программисты ее понимаем, отличается творчеством и созданием новых сущностей. Но клиенты привносят свой отпечаток в нашу жизнь.

Так, практически каждый из нас сталкивался с постоянной неопределенностью, которая исходила от клиента.

То тут надо переделать, то там надо добавить. А в результате – работа удлиняется, клиент жалуется на скорость работы и деньги распыляются на больший срок.

Хотя, как говорит Брукс в книге «Мистический человеко-месяц»: “Работа программиста сродни созданию поделок, что делали «для папы» - радость открытия, создание нового и управление таким гибким материалом, что можно воплотить любые фантазии”, но жизнь вносит свои коррективы.

Многие из нас пытались упорядочивать взаимоотношения с клиентами, но даже письменный договор, не гарантия того, что клиент не будет менять требования на ходу.

Итак, мы видим: радости в нашей работе больше, чем проблем, но всем хочется достичь больших результатов.

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

 

Давайте рассмотрим узкие места нашей работы. Многие программисты – оптимисты по натуре, поэтому им свойственно не замечать или игнорировать эти узкие места. Но они все равно продолжают мешать. И, к нашему сожалению складываются. Как говорил Мерфи: «Дела, пущенные на самотек, имеют тенденцию ухудшаться»

Исходя из этого, можно сделать вывод, что надо их рассмотреть и решить.

Одним из самых неприятных моментов – постоянная изменчивость спецификаций. Сейчас заказчик хочет это, потом – другое. И так постоянно. Хотя это и малоприятно, но такова природа человек. Мы редко знаем, что мы хотим.

 

Проведем эксперимент: закройте глаза и представьте, что вы больше всего хотите от жизни.

Как ощущения? Смогли четко и живо представить свою цель? И заметьте: вы – программисты, и изо дня в день оттачиваете четкость мышления и определенность образов.

А что же говорить о наших клиентах?

Их постоянно атакует море информации и пачка проблем.

 

Так, бизнесмену нужно решить: где достать деньги? Как найти работников, которые любят работать? Как увеличить продажи? Как уменьшить расходы? Как ответить на ход конкурента? И многое другое.

И как результат этого потока меняется его желание – сегодня его бизнес нуждается в контроле расходов, а завтра в учете клиентов. И предсказать это бывает очень трудно.

 

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

Знакомая ситуация?

 

Теперь давайте рассмотрим средства их решения.

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

Это сложность присущая ПО как основное качество. Бывает, и сам автор программы через месяц не помнит, зачем он сделал это решение и почему здесь «концы висят. А тут еще клиент напрягает: поменяйте тут и ту, да и еще тут. И срочно. Когда спрашиваешь, когда надо сделать, то слышишь ответ: «Вчера…» И начинается аврал…

 

Откуда же вырастает такая сложность, что иной раз и подходить страшно?

А источник ее как раз лежит в том, что добавления идут спонтанно. Бессистемное добавление функций приводит к нагромождению решений. И когда подходишь к этой горе, то каждое решение логично, но общее впечатление – груда камней, которая готова сорваться лавиной при неосторожном изменении или добавлении.

 

Как же избавиться от постоянного нарастания сложности ПО?

 

Давайте рассмотри ее с нескольких точек зрения.

Если система такая мощная и функциональная, - то это кому-то нужно. И зачастую сами функции реализованы замечательно, но когда их начинают увязывать воедино – тут проблема и выскакивает. Вы, как профессиональный программист,  сосредоточены на добавлении функций и, тратить неделю на создание общих интерфейсов и методик взаимодействия, вам не позволяет собственная активность, да и клиенты поджимаются.

Как видим, из-за недостатка внимания зарождается источник проблем и вскоре вся программа покрыта «бурьяном» лишних сущностей, сложных связей и прочих «прелестей» сложности

 

Но, чтобы избавиться от этого, надо сделать несколько шагов:

  1. Пытаться принимать простые решения при привязке функций друг к другу.

Конечно, - вы спросите: «А что делать мне, когда нужно связать три системы, чтобы они синхронно работали?»

Для этого вспомним основное правило ООП: инкапсуляция должна быть полной. Внутреннее поведение и интерфейсы должны оставаться внутренними. Конечно, бывает сложно добиться «идеальной простоты» внешних интерфейсов. Но как мы увидим – это вполне достижимо.

Самая большая трудность в простых решениях – надо осознавать и понимать систему в целом и по частям. Но даже наши заказчики не видят всех нужных функций. Что уж говорить о нас программистах.

У нас есть лишь малый выбор: оставить все как есть, но потом бороться с проблемами, растягивая сроки и нервы клиентов; или потихоньку делать вещи красивыми и простымми

Как говорил Эйнштейн: «Стремитесь к простоте, но не упрощайте»

Чтобы этого достичь, можно применить методику – рефакторинг. Ее сущность заключается в том, что после любого изменения надо «расчищать рабочее место» за собой. Такие вещи, как дублирующий код, большие классы, длинные методы, код «спагетти», и другие раздражающие факторы мешают получать полное удовольствие от программирования.

Эту методику мы рассмотрим позже.

 

  1. Писать мысли на бумаге

Вроде бы все знают это, но мало кто осознает ценность этой методики. Но как часто вы сталкивались с «перегрузкой мозга», когда голова тяжелая, а мысли текут как вязкая жидкость?

А ведь так просто – сгружать лишнюю информацию на бумагу и направлять свой острый ум на проблемы, которые стоят перед глазами.

Немного тренировки и каждый может вспомнить этот навык, привитый в студенческие годы.

 

  1. Хотя бы частично моделировать решения

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

 

            Мы рассмотрели некоторые из основных методик борьбы со сложностью и базовые проблемы.

Позже детально остановимся на каждой из них. Желаю вам приятных моментов программирования.

 

С уважением, Афонин Владимир
В избранное