Лучшие 13 цитат в категории «цитаты разработки программного обеспечения»

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

Кодирование, как поэзия, должно быть кратким и лаконичным.

Подделка межсайтовых запросов исключение - это лицензия для вызова представления DJango REST API.

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

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

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

В итоге все сводится к 0 и 1

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

Это джекпот, когда вы узнаете, что JavaScript можно отлаживать.

Лучше всего быть генеральным директором; достаточно быть ранним сотрудником, может быть, пятым, шестым или, может быть, десятым. С другой стороны, можно стать инженером, разрабатывающим драгоценные алгоритмы в монастырях Google и тому подобное. В противном случае человек становится простым работником. Кодировщик сайтов в Фейсбуке никто не особо. Менеджер в Microsoft - никто. Человек (думающая женщина), работающий в отношениях с клиентами, - это особый тип людей, которых, как всегда, изгнали из-за того, что они разговаривали напрямую с нетехническим человеком. Все это и другие - способы, с помощью которых стремящиеся могут отойти на второй план - как это видит культура стартапов - в то время как их лучшие гонщики опережают их. Оставшиеся могут увидеть себя обычными, даже неудачниками.

Качество - это продукт конфликта между программистами и тестировщиками.

Если оно не записано, его не существует.

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