Когда разработка отстой, сложность никогда не за горами
Сложность убивает. Это высасывает жизнь из разработчиков, затрудняет планирование, создание и тестирование продуктов, создает проблемы безопасности и вызывает разочарование у конечных пользователей и администраторов». — Рэй Оззи
Когда разработка отстой, это потому, что разработчики проиграли битву не со сложностью. Сложность подобна джинну. Как только он выйдет из бутылки, вы не сможете вставить присоску обратно. Она будет продолжать выскакивать, чтобы ломать вещи, замедлять вас и сбивать с толку.
Разработчики создают сложность, она душит разработку и лишает радости создания программного обеспечения. Когда вы видите программные проекты, страдающие от ошибок, проблем и проблем, которые не исчезают. Это потому, что разработчики позволяют сложности побеждать их, код побеждает.
Разработчики управляют сложностью программного обеспечения, или сложность управляет ими.
Разработчики могут быть склонны ввязываться в хитроумные технические беспорядки или сворачивать в области, в которых они не являются экспертами.
По мере роста сложности и технического долга в программном проекте разработка замедляется, и разработчики борются с существующим решением. Технически это становится все сложнее, и разработчики специализируются на сложных областях решения, которые не могут понять другие разработчики.
Проще говоря, разработка становится более сложной, более сложной для понимания кода и более сложной для изменения кода. Это идеальная среда для ошибок, ошибок и путаницы.
Путь к успеху не в поиске гениальности, а в простоте разработки и избегании ошибок. Если вы остановите большие ошибки, вы дадите себе время найти правильное решение.
Избегайте сложностей
«С хорошей идеей у вас может быть больше проблем, чем с плохой, потому что вы забываете, что у хорошей идеи есть пределы». — Бенджамин Грэм
Требуется дисциплина, чтобы избежать сложности, потому что создание простых решений требует больше усилий.
Сложность часто возникает из-за принятия быстрых решений, использования ярлыков и создания технического долга. Технический долг — это еще одно название сложности, потому что технический долг делает код более сложным, трудным для понимания и более трудным для работы.
Технический долг = сложность
Если код слишком сложен для понимания большинства разработчиков, он слишком сложен, и это вызовет проблемы. Один разработчик это понимает и становится единой точкой отказа.
Разработчики должны следить за ответом Эйнштейна студенту, который поставил под сомнение утверждение Эйнштейна о том, что законы физики должны быть простыми.
Ученик «А что, если они не простые?»
Эйнштейн ответил: «Тогда они меня бы не интересовали».
Если вы хотите простой жизни разработчика, избегайте сложностей и делайте все как можно проще.
- Когда вы делаете процесс сложным и трудным — разработчики игнорируют это
- Когда делаешь развертывания вручную — их делают реже
- Когда код сложный — разработчики создают ошибки
Сложность — это будущий налог, который вы платите со временем в будущем. Тот, кто считает, что в будущем у них будет больше времени, обманывает себя.
У вас будет больше кода для поддержки, больше проблем, больше ошибок и меньше времени в будущем.
Действуй быстро, покайся на досуге
Распространенная причина сложности — это торопиться с действиями, не давая себе достаточно времени, чтобы обдумать проблему или второстепенные последствия вашего решения.
Завтрашние проблемы при разработке вызваны сегодняшними решениями и кодом. Если вы не понимаете проблему; в конечном итоге вы решаете не ту проблему или делаете предположения.
Разработчики создают предположения, потому что они не понимают требований и предполагают (угадывают, как это должно работать). Позже они обнаруживают, что предположения неверны, и программное обеспечение необходимо изменить. ВСЕГДА УТОЧНЯЙТЕ ПРЕДПОЛОЖЕНИЯ ПЕРЕД СОЗДАНИЕМ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.
Почему разработка программного обеспечения замедляется, когда вы пытаетесь ее ускорить. Классический пример — добавление большего количества людей для ускорения разработки. Часто замедляет развитие.
Новым разработчикам нужен месяц для адаптации. Они замедляют работу существующих разработчиков и добавляют коммуникационные издержки. Если вы не можете иметь отдельные области для разработки, тогда больше разработчиков будут спотыкаться друг о друга.
Более продолжительный рабочий день кажется простым способом сделать больше работы, но в долгосрочной перспективе это снижает качество жизни и может привести к выгоранию разработчиков.
Предположения — это место, где живут ошибки
Разработка программного обеспечения — игра для проигравших. Чем больше проблем вы исправляете в среде разработки, тем меньший ущерб они могут нанести команде разработчиков.
Качество — это кратчайший путь в разработке программного обеспечения. Когда используются краткосрочные решения, они требуют больше времени в будущем. Разработка программного обеспечения — это долгосрочная деятельность, которая постоянно усложняется людьми, принимающими краткосрочные решения.
Терпение
Разработчики и заказчики всегда стремятся приступить к работе и создавать программное обеспечение, но создание неправильного программного обеспечения всегда будет ошибкой.
Уоррен Баффет прочитал книгу бейсболиста Теда Уильямса «Наука удара». Он объясняет подход Теда.
«Если бы он дождался подачи, которая была действительно в его любимом месте, он бы отбил 0,400», — объясняет Баффет. «Если бы ему пришлось замахнуться на что-то в нижнем углу, он, вероятно, ударил бы 0,235». Баффет
Разработчикам нужно терпение, качать (создавать софт) стоит только тогда, когда требования правильные. Если вы создаете программное обеспечение, когда не уверены, вам придется переписать это программное обеспечение и, возможно, любой код, зависящий от него.
«Хитрость в инвестировании заключается в том, чтобы просто сидеть и смотреть, как проходит презентация за презентацией, и ждать той, которая находится прямо в вашем любимом месте. И если люди кричат: «Качайся, бездельник!», игнорируй их». Баффет
В программных проектах у вас будут клиенты, менеджеры и другие разработчики, говорящие:
«Создавайте программы, бездельники, пишите код сейчас же»
Вам нужно сохранять хладнокровие, понимать требования, понимать цель бизнеса, понимать проблему и прояснять все предположения. Теперь вам нужно убедиться, что вы создаете простое решение и сосредоточиться на качестве.
Другой ракурс — сложность выбора убивает разработку ПО
