Есть писатели программ и есть писатели книг о программах. Я привык быть первым из этих двух, но оказалось, что это малоуважаемое занятие. И действительно, код закрытый, никто твоего творчества не увидит. Что за занятие, год за годом подтачивать напильником винтики в маньячном перпетум-мобиле? Да и вообще, никто не любит читать код. Его проще переписать, а если и не проще, то приятнее, в полном согласии с инстинктами. Больше всего в Компании уважают scope of influence. Причем знак этой influence не важен. Знак зависит от точки зрения. Отрицательный результат - тоже результат и все такое. Самое неуважаемое занятие в Компании - писать код. Даже тестеры уважаются больше, ведь они стоят на страже качества! Программист в Компании - это как рядовой советской армии, понукать и унижать которого есть, кажется, единственная её функция. Ощущение армии не покидает меня все годы работы в Компании, хотя сейчас чувствуешь себя уже "дедом".
Другое дело писать книги! Область твоего влияния распространяется на всю отрасль сразу. И что же можно такое новое написать про программирование? Все коммерческие книжки должны содержать в своем названии некий новый бренд. Например Vista, или AJAX или С#. Но новый язык - это сложно. Надо лет десять раскручивать, чтобы люди начали покупать. Да и то, только гики. Да и сложно это. То ли дело бизнесс-процесс! Это можно написать, это легко продавать, Только название придумать. Например "Scrum". Ну и что, что похоже на смесь crap-а и срама. Зато звучит. Содержание процесса тоже неважно, это как новый метод лечения всех болезней. Главное - чтобы больной сразу не помер. А там, может сам выздоровеет. Лучше всего взять побольше обычного здравого смысла и добавить чуть-чуть (главное - не переборщить!) чего-нибудь модного и экстравагантного. Для вкуса. Чтобы запомнилось.
Я далёк от мысли, что бизнес процесс не нужен. Взять к примеру Макдональдзы. Всё их know-how - это процесс. Очень заметно, как правильный процесс облегчает работу, скажем, официантов в ресторане. Похоже пример Макдональдза не даёт спокойно спать менеджерам от программирования. "Вот нам бы так" - мечтают они. Выгнать всех этих шибко умных, бородатых, встречающих в штыки любую идею, и нанять улыбчивых молодых людей. Не работа будет - картинка с рекламки.
Но всё-таки, серьёзно, нужен программисту "процесс"? Смотря что назвать этим словом. Если ритуальные танцы с бубном, то нет. Если весёлые ежедневные митинги, коллективные тренинги на тему build team, то нет. Если свод законов, суровый и непреклонный, установленный десять лет назад, то тоже нет. Если набор разумных практик и приёмов, помогающий писать хороший код - то ДА! И практики эти надо применять с умом, когда они имеют смысл, и набраться храбрости и не применять, когда смысла не имеет. И практик этих на самом деле кот наплакал.
Итак, если Вы - маленькая фирма ещё не погрязшая в бюрократии, и сотрудники ваши ещё не растеряли желания сделать продукт, а не просто ходить на работу и "делать карьеру", то вот мои советы. Те же самые годятся и для волка-одиночки.
1. Иметь source control. Обязательно.
2. Тестировать код. Все написанные строчки. Именно все.
3. Сабмитить в source control оттестированный код разумными кусками. Не каждое открытие файла в редакторе, но фичи. Каждый баг-фикс отдельно, если они независимы. И писать description, что именно засабмичено.
4. Иметь место, где записываются все баги. Не обязательно база данных, об этом ниже. Но хранить баги, как исходный код.
5. Очень хорошо, если source control хранит всё, чтобы построить проект. Т.е. добавьте туда компилятор, заголовки и библиотеки. Это позволит восстановить в точности любую версию продукта, воспроизвести и исследовать баг.
6. Сделайте 2 branches: первый будет содержать текущую рабочую версию, а второй - релизы и хотфиксы к ним.
7. Если есть спеки - положите их рядом с исходным текстом в source control. Пригодится.
8. Не надо писать неиспользуемый код. Не надо делать супер-пупер систему классов на все случаи жизни с кучей методов. Половина будет не нужна, только зря потратите время и потом будет непонятно, что работает, а что нет. Сделайте то, что надо, остальное напишете, когда понадобится. Если написали ненужное, засабмитьте куда-нибудь, но не в рабочий код.
9. Можно написать unit-тесты, но главное - напишите скрипты, которые проверяют основную функциональность всей системы. Потом достаточно будет запустить, чтобы увидеть, что не поломалось.
10. Я не сторонник стайл-гайдов с подробным перечислением количества пробелов, но некий разумный стиль необходим. Код должен быть читабельным. И не только компилятором.
11. Не увлекайтесь самыми последними технологиями. Быстро сделать продукт можно на системе, которая хорошо известна, которая имеет документацию, блоги по недокументированному и куча всяких инструментов. Новые технологии имеют кучу багов и подводных камней. То, что красиво на картинке с 5 квадратиками - не работает, когда квадратиков 1000.
12. Пишите на том, что ваши программисты знают и понимают. Не понимает народ как писать с exceptons - не используйте их.
13. Неплохо, если ваш код посмотрит ещё один человек. Не первый встречный, а тот, кто понимает и может дать дельный совет.
14. Зависимости - вот что должно определять и менеджмент и архитектуру.
15. Не надо делать всё первым пришедшим в голову способом. Подумайте, как ещё можно сделать и выберите лучший вариант из возможных.
16. Программирование - процесс итерационный. Сделайте хотя бы пару итераций перед выпуском первой версии.
17. Задача первой версии - сделать хороший стабильный прототип, обкатать принцип и сформировать API. Вторая версия - никаких новых фич, но то, что есть работает быстро и надежно. Фичи можно добавлять в третьей. И т.д.
18. Во время написания первой версии вы поняли как это надо было писать. Не бросайте и не начинайте переделывать сразу как поняли. Выпустите первую версию. Потом сделаете, то, что поняли во второй. Если перепахивать каждый день - ничего не вырастет.
19. Заведите FAQ и форум для пользователей. Возник у пользователя вопрос - впишите ответ в FAQ. Потом можно просто сслылаться на готовый ответ.
20. Вместо сложных систем баг-трекинга можно просто завести внутренний форум с несколькими правилами. Возник баг - завели тред. Первый пост - описание проблемы (способ воспроизведения или цитата из внешнего форума). Тред активный. Дальше разработчики могут добавлять свои комментарии, потом, когда проблема понята, кто-то принимает решение исправить или отложить. После этого решение записывается в треде. Когда проблема исправлена - это тоже записывается в треде и тред переводится в архив. Всегда видно, что происходит и каков статус. Старые треды тоже можно поднять и посмотреть. Ничего не стирайте!
Хватит на сегодня. Продолжение последует. Как-нибудь.
Другое дело писать книги! Область твоего влияния распространяется на всю отрасль сразу. И что же можно такое новое написать про программирование? Все коммерческие книжки должны содержать в своем названии некий новый бренд. Например Vista, или AJAX или С#. Но новый язык - это сложно. Надо лет десять раскручивать, чтобы люди начали покупать. Да и то, только гики. Да и сложно это. То ли дело бизнесс-процесс! Это можно написать, это легко продавать, Только название придумать. Например "Scrum". Ну и что, что похоже на смесь crap-а и срама. Зато звучит. Содержание процесса тоже неважно, это как новый метод лечения всех болезней. Главное - чтобы больной сразу не помер. А там, может сам выздоровеет. Лучше всего взять побольше обычного здравого смысла и добавить чуть-чуть (главное - не переборщить!) чего-нибудь модного и экстравагантного. Для вкуса. Чтобы запомнилось.
Я далёк от мысли, что бизнес процесс не нужен. Взять к примеру Макдональдзы. Всё их know-how - это процесс. Очень заметно, как правильный процесс облегчает работу, скажем, официантов в ресторане. Похоже пример Макдональдза не даёт спокойно спать менеджерам от программирования. "Вот нам бы так" - мечтают они. Выгнать всех этих шибко умных, бородатых, встречающих в штыки любую идею, и нанять улыбчивых молодых людей. Не работа будет - картинка с рекламки.
Но всё-таки, серьёзно, нужен программисту "процесс"? Смотря что назвать этим словом. Если ритуальные танцы с бубном, то нет. Если весёлые ежедневные митинги, коллективные тренинги на тему build team, то нет. Если свод законов, суровый и непреклонный, установленный десять лет назад, то тоже нет. Если набор разумных практик и приёмов, помогающий писать хороший код - то ДА! И практики эти надо применять с умом, когда они имеют смысл, и набраться храбрости и не применять, когда смысла не имеет. И практик этих на самом деле кот наплакал.
Итак, если Вы - маленькая фирма ещё не погрязшая в бюрократии, и сотрудники ваши ещё не растеряли желания сделать продукт, а не просто ходить на работу и "делать карьеру", то вот мои советы. Те же самые годятся и для волка-одиночки.
1. Иметь source control. Обязательно.
2. Тестировать код. Все написанные строчки. Именно все.
3. Сабмитить в source control оттестированный код разумными кусками. Не каждое открытие файла в редакторе, но фичи. Каждый баг-фикс отдельно, если они независимы. И писать description, что именно засабмичено.
4. Иметь место, где записываются все баги. Не обязательно база данных, об этом ниже. Но хранить баги, как исходный код.
5. Очень хорошо, если source control хранит всё, чтобы построить проект. Т.е. добавьте туда компилятор, заголовки и библиотеки. Это позволит восстановить в точности любую версию продукта, воспроизвести и исследовать баг.
6. Сделайте 2 branches: первый будет содержать текущую рабочую версию, а второй - релизы и хотфиксы к ним.
7. Если есть спеки - положите их рядом с исходным текстом в source control. Пригодится.
8. Не надо писать неиспользуемый код. Не надо делать супер-пупер систему классов на все случаи жизни с кучей методов. Половина будет не нужна, только зря потратите время и потом будет непонятно, что работает, а что нет. Сделайте то, что надо, остальное напишете, когда понадобится. Если написали ненужное, засабмитьте куда-нибудь, но не в рабочий код.
9. Можно написать unit-тесты, но главное - напишите скрипты, которые проверяют основную функциональность всей системы. Потом достаточно будет запустить, чтобы увидеть, что не поломалось.
10. Я не сторонник стайл-гайдов с подробным перечислением количества пробелов, но некий разумный стиль необходим. Код должен быть читабельным. И не только компилятором.
11. Не увлекайтесь самыми последними технологиями. Быстро сделать продукт можно на системе, которая хорошо известна, которая имеет документацию, блоги по недокументированному и куча всяких инструментов. Новые технологии имеют кучу багов и подводных камней. То, что красиво на картинке с 5 квадратиками - не работает, когда квадратиков 1000.
12. Пишите на том, что ваши программисты знают и понимают. Не понимает народ как писать с exceptons - не используйте их.
13. Неплохо, если ваш код посмотрит ещё один человек. Не первый встречный, а тот, кто понимает и может дать дельный совет.
14. Зависимости - вот что должно определять и менеджмент и архитектуру.
15. Не надо делать всё первым пришедшим в голову способом. Подумайте, как ещё можно сделать и выберите лучший вариант из возможных.
16. Программирование - процесс итерационный. Сделайте хотя бы пару итераций перед выпуском первой версии.
17. Задача первой версии - сделать хороший стабильный прототип, обкатать принцип и сформировать API. Вторая версия - никаких новых фич, но то, что есть работает быстро и надежно. Фичи можно добавлять в третьей. И т.д.
18. Во время написания первой версии вы поняли как это надо было писать. Не бросайте и не начинайте переделывать сразу как поняли. Выпустите первую версию. Потом сделаете, то, что поняли во второй. Если перепахивать каждый день - ничего не вырастет.
19. Заведите FAQ и форум для пользователей. Возник у пользователя вопрос - впишите ответ в FAQ. Потом можно просто сслылаться на готовый ответ.
20. Вместо сложных систем баг-трекинга можно просто завести внутренний форум с несколькими правилами. Возник баг - завели тред. Первый пост - описание проблемы (способ воспроизведения или цитата из внешнего форума). Тред активный. Дальше разработчики могут добавлять свои комментарии, потом, когда проблема понята, кто-то принимает решение исправить или отложить. После этого решение записывается в треде. Когда проблема исправлена - это тоже записывается в треде и тред переводится в архив. Всегда видно, что происходит и каков статус. Старые треды тоже можно поднять и посмотреть. Ничего не стирайте!
Хватит на сегодня. Продолжение последует. Как-нибудь.
No comments:
Post a Comment