Archive

Posts Tagged ‘PHP’

Как да пишем по-добър код

Попаднах на много интересна статия, написана от Joel Spolsky, който е измислил кратък въпросник, съдържащ 12 върпоса за оценка на това, какви практики трябва да съществуват в една софтуерна компания, която иска да пише добър и продуктивен код.

Статията е дълга, но определено си заслужава четенето! Всички Team Leaders и Managers, който си мислят, че знаят всичко, нека обърнат внимание на точка номер 8, а именно: “Do programmers have quiet working conditions?”.

Според статията, ако отговорите на по-малко от 10 въпроса с положителен отговор, то компанията, в която работите има сериозни проблеми. От личен оптит съм склонен да го потвърдя.

Към текущият момент не мога да дам ясна оценка, защото от доста време нямам пряк контакт с компанията, но ще отговоря според мен какво се случваше в предишната такава, в която работех.
Не искам статията да звучи като критика или възхвала на това, което се е случвало там, но за целите на теста взимам въпросната фирма като база за сравнение и оценка.

The Joel Test

Do you use source control? – Да. Въпреки, че не всички проекти го използваха в началото, отговора е положителен.
Can you make a build in one step? – Да. Доста полезно, особено когато се налага да го правиш всеки ден.
Do you make daily builds? – Да. Потвърждава предишният ми отговор.
Do you have a bug database? – Да.
Do you fix bugs before writing new code? – Не. Това беше проблем, който се надявам с времето да е бил решен. Опитах се да въведа подобна практика, но кратките срокове за новите задачи изпреварваха “ремонтирането” на бъговете.
Do you have an up-to-date schedule? – Да, но не веднъж се случваше да се променя, в което няма лошо, защото все пак е up-to-date 🙂
Do you have a spec? – Не. Никой програмист не обича да пише документация… А тя всъщност е толкова важна!
Do programmers have quiet working conditions? – Да/Не. Сложно… По-скоро да.
Do you use the best tools money can buy? – Не. Нещо, което винаги ми е тежало, а и не само на мен.
Do you have testers? – Да.
Do new candidates write code during their interview? – Да. Не точно по време на интервютата, но в последствие преди започване на работа, което смятам за положителен отговор на въпроса.
Do you do hallway usability testing? – Не. Отново, за съжаление не сме правили това.

8 от 12… не е зле, нали? А може би е доста зле?

Бих добавил още:
Успявате ли да поставяте реални срокове за изпълнението на задачите? – Според мен, всеки един срок трябва да се консултира с програмистите и да се взима под внимание тяхното мнение. Не само защото те са хората, които трябва да го спазят, но и защото те са хората, които имат най-реална преценка за това колко време би отнело завършването на конкретна задача. Всяко отлагане на release (build) поради незавършени задачи излишно натоварва програмистите и изнервя обстановката в екипа.

Оставяте ли достатъчно време на програмистите за обучение? – Всяка уважаваща себе си компания би трябвало да намира време и ресурс за обучението на своите служители. В случея става въпрос за програмисти, но въпроса е валиден за компании от всички отрасли.
Нали не очаквате продукта, който произвеждате да е винаги на първо място и добре работещ, разчитайки на стари технологии и практики?

Как се случват нещата в компанията, в която работите? Успяхте ли да отговорите на всичките 12 точки положително?

Possible PHP Error levels

Value	Constant	Description
1	E_ERROR	Fatal run-time errors. Execution of the script is halted
2	E_WARNING	Non-fatal run-time errors. Execution of the script is not halted
4	E_PARSE	Compile-time parse errors. Parse errors should only be generated by the parser.
8	E_NOTICE	Run-time notices. The script found something that might be an error, but could also happen when running a script normally
16	E_CORE_ERROR	Fatal errors that occur during PHP's initial startup.
32	E_CORE_WARNING	Non-fatal run-time errors. This occurs during PHP's initial startup.
256	E_USER_ERROR	Fatal user-generated error. This is like an E_ERROR set by the programmer using the PHP function trigger_error()
512	E_USER_WARNING	Non-fatal user-generated warning. This is like an E_WARNING set by the programmer using the PHP function trigger_error()
1024	E_USER_NOTICE	User-generated notice. This is like an E_NOTICE set by the programmer using the PHP function trigger_error()
2048	E_STRICT	Run-time notices. Enable to have PHP suggest changes to your code which will ensure the best interoperability and forward compatibility of your code.
4096	E_RECOVERABLE_ERROR	Catchable fatal error. This is like an E_ERROR but can be caught by a user defined handle (see also set_error_handler())
8191	E_ALL	All errors and warnings, except level E_STRICT (E_STRICT will be part of E_ALL as of PHP 6.0)
Categories: PHP Tags: , ,