Самые сложные задачи в разработке имеют мало общего с написанием программного обеспечения. Кодирование — это упражнение в логическом мышлении; это просто по сравнению с другими видами деятельности, которые разработчики выполняют ежедневно. Если вы считаете себя приличным программистом-любителем, убедитесь, что вы можете преодолеть эти препятствия, прежде чем прыгнуть в профессиональную сферу …
1. Объясняя, что вы делаете
Объяснить процесс разработки программного обеспечения сложно. Некодеры могут знать много, но по определению они не могут кодировать. Для них мы тратим свои жизни сгорбившись за клавиатуру в темной комнате, пили кофе.
Вы столкнетесь с мнением друзей, семьи и коллег, что кодирование — это «неправильная работа» .
2. Визуализация программных решений
Учитывая набор кратких — и часто плохо продуманных — требований, вам необходимо разработать хранилища данных, архитектуру кода, алгоритмы, протоколы связи и любые другие технические аспекты, которые охватывают решение бизнес-задачи. Затем вам нужно объяснить это в терминах непрофессионала и выполнить в течение определенного периода времени.
Немногие разработчики могут сделать это хорошо.
3. Расчет времени доставки
Бич жизни каждого разработчика. Невозможно определить время, необходимое для выполнения задачи, когда эта задача никогда не выполнялась ранее. Возможно, был написан похожий код, но он не в той же системе с теми же проблемами или ограничениями.
Опыт помогает, но большинство программистов недооценивают. Это отчасти потому, что они рассматривают только сторону кодирования и забывают о других действиях в этом списке.
4. Работа над чужим кодом
Существует бесконечное количество способов создания программного решения. Работать над чужим кодом — значит тратить много часов, разбираясь в тысячах строк кода, чтобы понять, о чем они думают. Конечно, это усложняется, когда первоначальный разработчик не верит в комментарии или документацию, а затем отказывается от своего незавершенного проекта.
5. Сфера ползучести и причудливая функциональность
Несмотря на то, что гибкая разработка учитывает расширение области действия, она не делает ее менее расстраивающей, особенно когда вас просят о тупой функциональности по прихоти. Вы знаете, что это не удастся. Ваша команда знает, что это не удастся. Но клиент знает лучше, и, когда неизбежно происходит сбой, это ваша вина, потому что вы не верили в их видение.
6. Достижение баланса между недостаточной и чрезмерной оптимизацией
Сложное программное обеспечение никогда не бывает идеальным; всегда есть лучший подход. Можно оптимизировать до бесконечности, и поэтому программные проекты никогда не доставляются раньше, чем срок исполнения.
С другой стороны, есть менталитет «это подойдет — я улучшу это позже» . Код будет работать сегодня, но вы знаете, что завтра это вызовет страдания и неудачу. Конечно, вы никогда не исправите это; это будет оставлено следующему бедному разработчику .
7. Тестирование вашего кода
Вы можете написать модульные тесты и передать программное обеспечение командам тестировщиков, но ошибки все еще материализуются …
- Программное обеспечение является сложным и может содержать тысячи строк кода. Там может быть миллиарды возможных взаимодействий и пути через систему; невозможно проверить их все.
- Аналогично, программное обеспечение взаимодействует с различным программным обеспечением в разных системах в разных условиях. Вы не можете проверить каждую возможность.
- Написание хороших юнит-тестов — утомительная и тяжелая работа. В идеале тесты должны быть написаны до начала разработки, но попробуйте объяснить своему клиенту, почему четыре недели усилий привели к тому, что не удалось использовать программное обеспечение.
- Модульные тесты не выявят всех недостатков. В идеальном мире отдельная команда будет писать тесты и активно конкурировать, чтобы обнаружить проблемы. К сожалению, для большинства проектов это слишком дорого и занимает много времени, поэтому команда разработчиков пишет тесты. Они подсознательно избегают любых странных крайних случаев.
- У программистов логичный подход ко всему. Пользователи редко делают; они найдут проблемы, которые вы никогда не ожидали.
8. Документирование вашего кода
Документирование вашего кода трудоемко и отнимает много времени. Мало кто из разработчиков хорош в этом, и еще меньше найдет время, чтобы прочитать его.
9. Решение проблем ИТ
Вы работаете с технологиями каждый день. Вы можете быть разработчиком HTML или PHP, но вам, вероятно, приходилось преодолевать такие проблемы, как сбои жесткого диска, конфликты драйверов и сбои программного обеспечения. Это не ваша основная роль, но, если вы не решите проблему, вы не сможете продолжить выполнение задач разработки.
К сожалению, для всех, кто не занимается ИТ, вы знаете все. Когда у них возникнут проблемы, они свяжутся с вами, а не потратят какое-то время, пытаясь решить их самостоятельно. Неважно, в чем проблема: вы используете компьютеры, поэтому вы должны знать, как импортировать данные о заработной плате в Sage, настроить Oracle или выяснить, почему исходящая электронная почта не работает на их Blackberry.
Конечно, эти перерывы не повлияют на график доставки или не будут платными, не так ли? …
10. Общение с людьми
Вышеуказанные задачи можно обобщить как «работа с людьми» . Немногие неспециалисты посоветуют пилоту, как летать на самолете, или предложат электрику методы переоборудования дома, но они счастливы делать смелые предложения по разработке программного обеспечения.
Я боюсь, что нет никакого способа обойти это; вам просто нужно признать, что половина мира обладает интеллектом ниже среднего!