Публикую ответ на один из вариантов вопросов о том как развиваться, который получаю от школьников, студентов, и коллег.
Публикую ответ на один из вариантов вопросов о том как развиваться, который получаю от школьников, студентов, и коллег.
Качество ПО (в дальнейшем по тексту просто «качество») – это сложная интегральная функция, зависящая от времени. Качество характеризуется удовлетворенностью потребителя и производителя. Качество можно считать положительным или оно может стремиться к бесконечности, если средний потребитель ПО удовлетворен им «сегодня», «завтра» и «послезавтра», а производитель получает постоянный рост чистой прибыли. Т.е. качество можно измерять в деньгах. Часто можно опускать рост прибыли, поскольку между прибылью и удовлетворенностью потребителя есть прямая зависимость.
Во многих книгах пишут, что нужно избегать exception-ов в конструкторах и деструкторах. Exception в конструкторе нам как бы «подсказывает», что объект не был сконструирован до конца и следовательно, нет смысла вызывать деструктор для такого объекта. Такое поведение чревато утечками ресурсов, поскольку как правило ресурсы освобождаются в деструкторе.
Общаясь с одним из своих друзей, я спросил: «что обычно спрашиваю у вас на собеседованиях, когда вы ищете инженеров-кораблестроителей?». Ответ был следующим: «попросят от руки нарисовать коробок спичек в изометрии». Мой друг — недавний выпускник, уже отработавший несколько лет на кораблестроительном заводе инженером-конструктором и ставший небольшим руководителем, был сильно удивлён такому простому вопросу («не мог понять в чём подвох»), и просто нарисовал коробок спичек… После трудоустройства, он рассказал, что участвовал в нескольких собеседованиях при приёме новых сотрудников, и на удивление не все «корабелы» могли пройти такой простой тест. Это меня озадачило, поскольку в моём понимании инженеры-кораблестроители по определению должны рисовать чертежи кораблей, рассчитывать их физику и т.п. Но я не кораблестроитель, чтобы судить, поэтому давайте рассмотрим подобные простые задачи, которые задают программистам на собеседованиях.
В студенческие годы участвовал в международной студенческой олимпиаде по программированию. Считаю, что эти соревнования двигают IT-индустрию, в особенности, популярность языков программирования. Университеты, чтобы участвовать в таких соревнования, готовят целенаправленно студентов со знаниями языков программирования предлагаемых в регламенте соревнований. Когда Я участвовал, мы использовали Pascal/Delphi. В то время на этом языке программирования российские ребята успешно побеждали в финале чемпионатов. Однако, сейчас pascal исключён из регламента соревнований.
Логирование кода как метод отладки программного обеспечения вероятно «родилось» из отладки путём вывода значений переменных на консоль. Результат логирования, т.е. то, что выводится на консоль, в файл и т.п. называется логом.
Де-факто логирование стало настолько универсальным методов отладки, что например в embedded программировании без логирования практически невозможно отладить код, а о серверных логах наверно слышали все.
«Triage is a process of determining the priority of patients treatments based on the severity of their condition» [http://en.wikipedia.org/wiki/Triage]
Какое отношение этот медицинский термин имеет к IT?
Время от времени на форумах «пролетает» вопрос: «Какие методы отладки вы использовали?». Этот пост — мой ответ.
Отладка — это комплексный процесс по выявлению и исправлению дефектов в программном обеспечении. Сами же дефекты, обычно, обнаруживается в процессе тестирования ПО.
Ниже список неявных признаков плохого кода, который в контексте данного поста стоит воспринимать как эмпирические знания автора.
Если Вы нашли один из перечисленных ниже признаков в вашем проекте — это сигнал задуматься об improvement-ах!
Все события и персонажи вымышленные, а любые совпадения случайны ;).
В тот момент, когда проект становится по настоящему большим, а бюджет на з.п. программистам ещё больше, компания начинает задумываться об экономии бюджетов и реорганизации. У кого-то из менеджеров возникает мысль об аутсорсинге (при этом почему-то все забывают о «заветах» Фредерика Брукса, успокаивая себя тем, что якобы на support (MOL) закон Брукса не распространяется). Менеджеры некого звена начинают лоббировать аутсорсинг как панацею. И наконец-то компания зааутсорсила часть работ.
Чем отличается аутсорсинг от самостоятельной разработки (или как иногда говорят инсорсинга)? Для того чтобы увидеть отличия нужно взглянуть на одни и те же вещи с разных сторон. Рассмотрим на примере некого long term проекта.