Как написать эффективный код, несмотря на тяжелые сроки

Я работаю в среде, где у нас много проектов со строгими сроками сдачи. Мы даже общаемся напрямую с клиентами, поэтому необходимо быстро и качественно выполнить работу.

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

Есть ли какие-нибудь советы, с помощью которых я мог бы сделать свой код эффективным, но доставить вовремя?

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

Если они не заботятся об этом, я не думаю, что вам нужно делать что-то иное, кроме как постоянно улучшаться и делать все возможное, чтобы по возможности использовать лучшие практики.

Ладно, это может показаться немного сумасшедшим, но я клянусь, это работает. Это не только для программирования, это рецепт для увеличения креативности, концентрации и памяти:

• Ешь хорошо
• Размышление
• Выспаться (7-9 часов в зависимости от человека)
• Дремать всякий раз, когда ваш мозг нечеткий
• Иди спать с нерешенной проблемой. Не заканчивайте свой день всем завершенным. Оставьте одну трудную задачу в ожидании - ваше подсознание удивительно эффективно.
• Носите удобную одежду
• Упражнение
• Потратьте время, чтобы выполнить механические умственные упражнения - судоку (не запрограммировано), кроссворды, математические упражнения, пространственные головоломки и т. Д.
• Проведите объективные эксперименты над собой, чтобы увидеть, какое из ваших поведений влияет на производительность (для этого вам понадобится надежный способ проверить производительность).
• Следите за своим духовным здоровьем
• Хлопковые трусы
• Следите за своим сексуальным здоровьем
• Найдите время для своей семьи и друзей
• Стать опытным в чем-то вне вашей профессии (музыка, кулинария, спорт и т. Д.) И общаться с другими людьми, делающими то же самое
• Для некоторых людей домашнее животное является обязательным

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

Источники:

1. Ваш Чудесный Мозг: Максимизируйте Вашу Интеллектуальную силу, Повысьте Свою Память, Поднимите Настроение, Повысьте Свой IQ и Креативность, Предотвратите и Обратное Умственное Старение
2. Количественная Самость
3. Сет Робертс - в Scientific American

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

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

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

Ищите другую работу.

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

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

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

С точки зрения ваших клиентов, эффективность кода может быть не столь критичной и довольно дорогой. В эти дни время, затрачиваемое на создание кода, должно сэкономить часы процессорного времени, чтобы оправдать час вашего времени. Для большинства программ эффективность не так критична. Даже для тех, где он есть, большая часть кода не должна быть настолько эффективной. Учитывая выбор, я бы предпочел простое в обслуживании решение, а не более эффективный, более сложный в обслуживании код.

Если вы потратите время на планирование своего кода перед началом работы, у вас будет время оценить решения и рассмотреть альтернативные подходы. Это должно сэкономить ваше время в кодировании и тестировании. Я обнаружил, что часто более простой код более эффективен.

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

Примите, что достаточно хорошо, это достаточно хорошо. Когда вы придумаете более эффективные подходы, сделайте заметку для себя. Если у вас есть время, сравните несколько ваших более эффективных проектов с теми, которые вы реализовали. Попробуйте их как в малом (только введенный код), так и в большом (программа, которая их использует). Это даст вам представление о том, когда подходит более эффективный подход.

Многие считают преждевременную оптимизацию плохим подходом. Это может быть дорогостоящим для реализации. К сожалению, многие преждевременные оптимизации на самом деле не эффективны, как код, который они оптимизировали. Чтобы правильно оптимизировать код, вам нужно применить код до и после изменения, чтобы увидеть, действительно ли вы улучшили эффективность.

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

Роберт осветил самые важные аспекты.

Я работал в таких средах, где код не живет (не может) более шести месяцев. Есть несколько правил большого пальца, о которых я могу думать:

1. Использовать библиотеки с открытым исходным кодом, сторонние решения и т. Д. Обучение требует меньшего количества обслуживания и отладки. Однако, если вы застряли с ошибкой библиотеки, вы обречены.
2. Строго убедитесь, что ваш дизайн расширяемый. Обязательное требование: большая часть работы идет в виде улучшений, а не создания новых функций.
3. Постройте строгие планы испытаний. Получить QA или автоматизировать тесты, чтобы обеспечить регрессионное тестирование.
4. Используйте умные инструменты - IDE, утилиты генерации кода и т. Д.
5. Держите вещи как можно более настраиваемыми. (Обратная сторона увеличивает усилия по тестированию)
6. Повысьте скорость печати :-)

На этапе проектирования поговорите с коллегами .

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

Практика. Практикуйтесь в написании хорошего кода, пока он не станет второй натурой. Тогда попрактикуйтесь в кодировании быстрее. Тогда попрактикуйтесь в кодировании. И когда вы закончите ... попрактикуйтесь еще.

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

Нет, это не твоя проблема. Это добродетель. Это делает простейшую вещь, которая могла бы работать. Но это работает только в сочетании с рефакторингом. Это непрерывный процесс: выполнение следующей простейшей вещи, которая может работать снова и снова, так что ваша система всегда является выражением вашего текущего понимания пространства решений.

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

Наконец, как я уже говорил *, вам нужно научиться говорить «нет» .

* Как кодировать в очень сжатые сроки?

Если они зафиксировали объем и время, все, что вы можете сделать, чтобы сделать крайний срок, это падение качества.

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

Я действительно не думаю, что самосовершенствование поможет вам в этой ситуации. Если что, потом, извините, обычно это напористость.

Попытайтесь получить ногу в дверь, когда работа оценена. Как ваш начальник может оценить, как долго вы занимаетесь чем-нибудь?

Дайте выбор своему боссу и / или клиенту. Слишком часто сами разработчики выбирают снижение качества, не сообщая ничего. Поздние проекты / работы очень распространены и обычно «управляемы». Действуйте вовремя, предупредите людей, если вы видите, что наступает пропущенный срок.

Они не могут урезать сферу или сдвинуть крайний срок, если вы им ничего не скажете.

Если вы собираетесь идти на компромисс по качеству в любой форме, постарайтесь, чтобы это было их решением. Дайте им вещи весить друг против друга.

Некоторые вещи, которые только ВЫ можете решить. Если вы только что получили его на работу. Но это очень неосуществимо. Возможно, вы не уверены, работает ли это во всех случаях. Не говори никому, что вы сделали. Переделай это. Очень часто это решение может принять только ты. Либо потому, что проблема очень трудоемкая, либо у вас нетехнический менеджер.

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

Прежде всего, помните: нет позже.

Я разработчик .Net, работающий над веб-приложениями.

Вещи, которые я начал делать, -

Если это код C #, я сначала пытаюсь написать этот код в LinqPad (если это возможно).

Если это код Javascript, я сначала пишу этот код и проверяю его в jsfiddle / jsbin (если это возможно).

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