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

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

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

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

28 голосов | спросил gladysbixly 7 MarpmMon, 07 Mar 2011 23:15:59 +03002011-03-07T23:15:59+03:0011 2011, 23:15:59

10 ответов


23

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

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

ответил Robert Harvey 7 MarpmMon, 07 Mar 2011 23:24:28 +03002011-03-07T23:24:28+03:0011 2011, 23:24:28
17

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

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

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

Источники:

  1. Ваш мозг чуда: максимизируйте свою силу, увеличьте память, поднимите настроение, улучшите свой IQ и творческий потенциал, предотвратите и поверните Умственное старение
  2. Количественное самочувствие
  3. Сет Робертс - в Scientific American
ответил Scant Roger 8 MaramTue, 08 Mar 2011 08:11:40 +03002011-03-08T08:11:40+03:0008 2011, 08:11:40
9

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

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

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

ответил Corbin March 8 MaramTue, 08 Mar 2011 00:10:37 +03002011-03-08T00:10:37+03:0012 2011, 00:10:37
8

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

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

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

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

ответил Mike Rosenblum 8 MaramTue, 08 Mar 2011 04:44:51 +03002011-03-08T04:44:51+03:0004 2011, 04:44:51
3

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

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

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

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

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

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

ответил BillThor 8 MaramTue, 08 Mar 2011 08:00:16 +03002011-03-08T08:00:16+03:0008 2011, 08:00:16
1
Роберт затронул самые важные аспекты.

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

  1. Используйте библиотеки с открытым исходным кодом, сторонние решения и т. д.,. Участвующее обучение оплачивается за счет меньшего обслуживания и отладки. Однако, если вы застряли в багги-библиотеке, вы обречены.
  2. Строго убедитесь, что ваш дизайн является расширяемым. Обязательное требование: большая часть работы приходит как усовершенствование, а не создание новых функций.
  3. Стройте строгие планы испытаний. Получите QA или автоматизируйте тесты для обеспечения регрессионного тестирования.
  4. Используйте интеллектуальные инструменты - IDE, утилиты генерации кода и т. д..
  5. Держите вещи как можно более настраиваемыми. (Флип-сторона - это увеличение усилий по тестированию)
  6. Улучшите скорость ввода: -)
ответил CMR 7 MarpmMon, 07 Mar 2011 23:42:50 +03002011-03-07T23:42:50+03:0011 2011, 23:42:50
1

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

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

ответил 7 AMpThu, 07 Apr 2011 02:55:25 +040055Thursday 2011, 02:55:25
1

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

ответил Michael Brown 7 AMpThu, 07 Apr 2011 04:28:46 +040028Thursday 2011, 04:28:46
0
  

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

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

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

Наконец: как я уже говорил до *, вам нужно узнать, как сказать .

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

ответил Rein Henrichs 7 AMpThu, 07 Apr 2011 04:23:07 +040023Thursday 2011, 04:23:07
0

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

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

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

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

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

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

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

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

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

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

ответил Joppe 8 SatEurope/Moscow2012-12-08T06:44:26+04:00Europe/Moscow12bEurope/MoscowSat, 08 Dec 2012 06:44:26 +0400 2012, 06:44:26

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132