Кодировать процесс проектирования? [закрытый]

Экономичный код означает, что вы пишете код не только потому, что вы программист. Вы пишете достаточно кода, чтобы выполнить работу. Любой дополнительный код - это просто потеря времени и денег. Если вы обнаружите, что добавляете код, чтобы «использовать позже». Стоп. Позже приходит редко, а приложения живут долго. Код, который вы добавили позже, только запутает позже. Подумайте об этом так. Каждый лист бумаги на вашем столе должен быть обработан. Каждая строчка кода должна быть обработана.

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

Как я создаю код бережливого производства

• Документируйте (для себя), что вам нужно делать, и свое понимание того, что нужно делать. Будьте абсолютно ясны в своем понимании. Лучше получить ответ «да» или «нет» сейчас, чем ошибка, или, что еще хуже, проблема с дизайном, позже это будет стоить вам недель, что всегда приводит к «взломанному» коду.

• Создать черновик краткого руководства пользователя. Даже если вы единственный, кто это прочитает. Сделайте это карандашом и бумагой. Не тратьте время на текстовый процессор. Вы потратите больше времени на «форматирование», чем на написание контента. Если вы не можете написать это словами, как вы можете его закодировать? Это не должно быть красиво. Уродливое - это нормально.

• Создавайте любые документы с помощью карандаша и бумаги, насколько это возможно. (Эй, разве я уже не говорил об этом.) Это намного быстрее, понятно, пользователи могут писать на нем, вы можете скопировать его, повесить на стену и так далее. Что еще более важно, вы можете стереть его и сразу же начать работу с пользователем. Я уже упоминал, что это намного быстрее.

• Выполняйте личную проверку кода. Один хороший метод - сравнить каждый файл перед проверкой в ​​системе контроля версий. Я гарантирую, что вы найдете ошибки, вещи, которые вы забыли сделать, и так далее. Это хорошее время, чтобы очистить код и создать любую пользовательскую или техническую документацию и провести тестирование в последнюю минуту.

Например, я потратил день на создание книги Excel, чтобы задокументировать модель, которую мне нужно было создать. Я сделал это для себя. Модель уже была разработана специалистами (на бумаге). Я нашел, я бы сказал, что Excel нашел, циркулярную ссылку. Я сообщил об этом, но мне сказали, что модель тщательно прорабатывалась в течение последнего месяца, и проблема заключалась в моем понимании. Два месяца спустя исправление этой «циркулярной ссылки» стоит нам две недели. Мы еле уложились в срок. То, что можно было решить за восемь человеко-часов, стоит нам более шестидесяти человеко-часов и много стресса.Тем не менее, поскольку мой код был «скудным», исправление заключалось в нескольких строках кода для небольшой табличной функции.

Большинство программистов сначала напишут код. Большинство разработчиков сначала с документами. В общем, каждая минута раннего документирования сэкономит вам десять минут позже. (Прочтите «Код завершен».) Тем не менее, не забывайте «становиться реальностью». Ваша задача - не писать код, а создавать решения. Подумайте об этом так: работа писателя состоит не в том, чтобы писать, а в создании документа, который кто-то будет читать. Он не добавляет главу только потому, что она или вам может понадобиться позже. Ему постоянно приходится принимать решение о том, что включить или исключить, чтобы достучаться до читателя. Лучше потратить несколько минут на принятие решения о коде, чем потратить день на кодирование, только чтобы понять, что код не нужен.

Как правило, я не пишу код разработки, управляемой тестированием (TTD). Я обнаружил, что вы в конечном итоге пишете много кода без причины, вместо того, чтобы предлагать решение. Прежде, чем я «разозлюсь», я всегда сначала пишу TTD на бумаге. Если я не могу что-то придумать, я создам проект «отбросить» и напишу какой-нибудь код. Если я обнаруживаю, что мне нужно копать глубже, я создаю проект «wip» (Work-In-Progress), а если это не удается, я, наконец, создаю настоящий тестовый проект. С учетом сказанного, как упоминает Джастин Этье, если я пишу библиотеки или основные функции для приложения, я всегда создаю тестовый проект.

Лакомый кусок

Для приложения я однажды создал и встроил элемент управления RSS Pane, который загружал финансовую информацию компании из Google. Мой руководитель попросил эту функцию, чтобы "поразить" руководителей перед демонстрацией. Это было так. Всем это очень понравилось.Работая с компанией, пользователи будут получать мгновенные оповещения о новостях специально для этой компании. На создание и внедрение у меня ушло четыре часа, что я и сделал прямо перед демонстрацией. Тем не менее, поскольку пользователи не просили об этой функции,они постоянно жаловались, что я трачу время на реализацию ненужных функций, особенно функций, которые они не запрашивали, когда я не мог предоставить те функции, которые они запрашивали. (Это было не мое решение.) Примерно через два месяца этот элемент управления начал выдавать исключения. На поиск и устранение неполадок у меня ушло два дня. Эта функция имела большой успех, но представьте себе проблемы, если бы это было не так.